{"id":31852,"date":"2019-10-31T21:43:30","date_gmt":"2019-10-31T18:43:30","guid":{"rendered":"https:\/\/prohoster.info\/blog\/strah-i-nenavist-devsecops\/"},"modified":"2019-10-31T21:43:30","modified_gmt":"2019-10-31T18:43:30","slug":"strah-i-nenavist-devsecops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/strah-i-nenavist-devsecops","title":{"rendered":"Fear and Loathing in DevSecOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

We had 2 code analyzers, 4 dynamic testing tools, our own crafts, and 250 scripts. It's not that everything was needed in the current process, but since I started implementing DevSecOps, it\u2019s necessary to see it through to the end.<\/p>\n

\"Fear
\n
\nSource<\/a><\/noindex>. Character authors: Justin Roiland and Dan Harmon.<\/i><\/p>\n

What is SecDevOps? And DevSecOps? What are the differences? Application Security \u2014 what is it about? Why doesn\u2019t the classical approach work anymore? The answers to all these questions are known. Yuri Shabalin<\/b> from\u00a0Swordfish Security. <\/b>Yuri will answer everything in detail and analyze the challenges of transitioning from the classical Application Security model to the DevSecOps process: how to properly integrate secure development into the DevOps process without breaking anything, how to go through the main stages of security testing, which tools can be used, how they differ, and how to configure them correctly to avoid pitfalls.
\n<\/a><\/noindex>
\n

\r\n \"Play\r\n
<\/div>\r\n <\/div><\/center>
\nAbout the speaker:<\/b> Yuri Shabalin \u2014 <\/b>Chief Security Architect at Swordfish Security<\/b>. He is responsible for implementing SSDL, for the overall integration of application analysis tools into a unified development and testing ecosystem. 7 years of experience in information security. He has worked at Alfa-Bank, Sberbank, and Positive Technologies, which develops software and provides services. A speaker at international conferences such as ZerONights, PHDays, RISSPA, OWASP.<\/p>\n

Application Security: what is it about?<\/h2>\n

\nApplication Security<\/b>\u00a0\u2014 this is a branch of security that focuses on application security. It does not relate to infrastructure or network security, but specifically to what we write and what developers work on \u2014 it concerns the flaws and vulnerabilities of the application itself.<\/p>\n

Direction SDL or SDLC<\/a><\/noindex>\u00a0\u2014 Security Development Lifecycle<\/b>\u00a0\u2014 developed by Microsoft. The diagram shows the canonical SDLC model, whose main task is to involve security at every stage of development, from requirements to release and production deployment. Microsoft realized that there were too many bugs in production, they were becoming more frequent, and something needed to be done about it, leading to the proposal of this approach, which became canonical.<\/p>\n

\"Fear
\n
\nApplication Security and SSDL are focused not on detecting vulnerabilities, as is commonly believed, but on preventing their emergence. Over time, the canonical approach by Microsoft has been improved and developed, resulting in a deeper and more detailed approach.<\/p>\n

\"Fear
\n
\nThe canonical SDLC is detailed in various methodologies - OpenSAMM, BSIMM, OWASP. The methodologies differ, but overall, they are similar.<\/p>\n

Building Security In Maturity Model<\/h3>\n

\nI am most fond of BSIMM<\/b>\u00a0\u2014 Building Security In Maturity Model<\/a><\/noindex>. The foundation of the methodology is the division of the Application Security process into 4 domains: Governance, Intelligence, SSDL Touchpoints, and Deployment. Each domain includes 12 practices presented as 112 activities.<\/p>\n

\"Fear
\n
\nEach of the 112 activities has 3 maturity levels<\/b>: initial, intermediate, and advanced. All 12 practices can be studied by sections, selecting important aspects for you, understanding how to implement them, and gradually adding elements such as static and dynamic code analysis or code review. You draft a plan and work calmly within the framework of implementing the selected activities.<\/p>\n

Why DevSecOps<\/h2>\n

<\/p>\n

DevOps is a comprehensive process where security must be considered.<\/p><\/blockquote>\n

\nInitially DevOps<\/b><\/a><\/noindex> was expected to conduct security checks. In practice, the number of security teams was significantly lower than it is today, and they acted not as participants in the process but as a control and oversight body that imposes requirements and checks product quality at the end of the release. This is a classic approach where security teams were separated from development and did not participate in the process.<\/p>\n

\"Fear
\n
\nThe main problem is precisely that information security is set apart from development. Typically, it is some sort of security perimeter with 2-3 large and expensive tools. Every six months the source code or application arrives for review, and annual pentests<\/a><\/noindex>. All of this leads to delays in production timelines, and a huge number of vulnerabilities from automated tools are dumped on the developer. It is impossible to sort and fix this because the results from the previous six months have not yet been dealt with, and now there is a new batch.<\/p>\n

In the course of our company's work, we see that security in all sectors and industries understands that it's time to step up and align with development in the same wheel - in\u00a0Agile<\/b><\/a><\/noindex>. The DevSecOps paradigm fits perfectly into agile development methodology, ensuring involvement, support, and participation in every release and iteration.<\/p>\n

\"Fear
\n<\/p>\n

Transition to DevSecOps<\/h2>\n

\nThe most important word in the Security Development Lifecycle is \"process\"<\/b>You need to understand this before thinking about purchasing tools.<\/p>\n

Simply incorporating tools into the DevOps process is not enough\u2014it's important to have interaction and understanding among the participants of the process.<\/p><\/blockquote>\n

<\/p>\n

People are more important than tools.<\/h3>\n

\nOften, the planning of a secure development process starts with the selection and purchase of a tool and ends with attempts to integrate the tool into the existing process, which often remain just attempts. This leads to unfortunate outcomes, as every tool has its own features and limitations.<\/p>\n

A common scenario is when the security department selects a good, expensive tool with extensive capabilities and approaches developers to integrate it into the process. But it doesn't work\u2014it turns out the process is structured in a way that the limitations of the purchased tool do not fit into the current paradigm.<\/p>\n

First, describe the outcome you want and how the process will look. This will help clarify the roles of the tool and security in the process.<\/p><\/blockquote>\n

<\/p>\n

Start with what is already being used.<\/h3>\n

\nBefore purchasing expensive tools, take a look at what you already have. Every company has security requirements imposed on development, there are checks, pentests\u2014why not transform all this into a clear and convenient format for everyone?<\/p>\n

Usually, requirements are a paper tome that sits on a shelf. There was a case when we visited a company to review processes and asked to show the security requirements for the software. The specialist responsible for this searched for a long time:<\/p>\n

\u2014 Right now, somewhere in the notes, there was a path to where this document is located.<\/i><\/p>\n

In the end, we received the document after a week.<\/p>\n

For requirements, checks, and other matters, create a page, for example, on\u00a0Confluence<\/b>\u00a0\u2014 this is convenient for everyone.<\/p>\n

It's easier to reformat what already exists and use it as a starting point.<\/p><\/blockquote>\n

<\/p>\n

Use Security Champions. <\/h3>\n

\nUsually, in a medium-sized company with 100-200 developers, there is one security person who performs multiple functions and physically cannot check everything. Even if they try their hardest\u2014they cannot review all the code generated by development alone. For such cases, the concept of Security Champions<\/b><\/a><\/noindex>.<\/p>\n

Security Champions are individuals within the development team who are invested in the security of your product.<\/p><\/blockquote>\n

\"Fear
\n
\nA Security Champion is both an entry point into the development team and a security evangelist.<\/p>\n

Typically, when a security expert joins the development team and points out a bug in the code, they receive a surprised response:<\/p>\n

\u2014 And who are you? I\u2019m seeing you for the first time. Everything is fine for me \u2014 my senior colleague approved it during the code review, and we're moving on!<\/i><\/p>\n

This is a common scenario because developers trust senior colleagues or team members they work with closely and frequently in code review much more. If instead of a security expert, a Security Champion points out a bug and its consequences, their word carries more weight.<\/p>\n

Developers also know their code better than any security expert. For someone with at least 5 projects in a static analysis tool, it\u2019s usually hard to remember all the nuances. Security Champions are familiar with their product: what interacts with what and what to prioritize\u2014they are more effective.<\/p>\n

So, consider implementing Security Champions to expand the influence of the security team. It\u2019s also beneficial for the champion: professional development in a new area, broadening technical horizons, enhancing technical, managerial, and leadership skills, and increasing market value. They serve as your \u2018eyes\u2019 in the development team.<\/p>\n

Testing Stages<\/h2>\n

\nThe 20 to 80 paradigm<\/a><\/noindex>\u00a0states that 20% of efforts yield 80% of results. These 20% represent application analysis practices that can and should be automated. Examples of such activities include static analysis \u2014 SAST<\/b>, dynamic analysis \u2014 DAST,<\/b> and\u00a0open source monitoring<\/b>. I will elaborate on the activities and the tools, along with the specific challenges we typically encounter when implementing them into the process and how to do it correctly.<\/p>\n

\"Fear
\n<\/p>\n

Key Issues with Tools<\/h3>\n

\nI will highlight the relevant issues that all tools face, which require attention. I will discuss them in detail to avoid repetition.<\/p>\n

Long analysis times. <\/b>If it takes 30 minutes from commit to production for all tests and builds, then checks for information security will take a day. No one is going to slow down the process like that. Keep this in mind and draw conclusions.<\/p>\n

A high level of False Negatives or False Positives. <\/b>All products are different; they use various frameworks and coding styles. Different codebases and technologies can show varying levels of False Negatives and False Positives. So, take a look at what's specific in\u00a0your<\/b> company and for your<\/b> applications that will yield good and reliable results.<\/p>\n

No integrations with existing tools<\/b>. Look at the tools from the perspective of integrations, considering what you are already using. For example, if you have Jenkins or TeamCity, check the integration of the tools specifically with that software, not with GitLab CI, which you do not use.<\/p>\n

Lack of or overly complex customization. <\/b>If the tool has no API, then what is its purpose? Everything that can be done in the interface should be available through the API. Ideally, the tool should have the capability to customize checks.<\/p>\n

No product development roadmap. <\/b>Development is always evolving; we constantly use new frameworks and features, rewriting old code in new languages. We want to be assured that the tool we purchase will support new frameworks and technologies. Thus, it is essential to know that the product has a genuine and proper Roadmap<\/a><\/noindex> roadmap for development.<\/p>\n

Process features<\/h3>\n

\nIn addition to the features of the tools, consider the peculiarities of the development process. For instance, interfering with development is a typical mistake. Let's look at what other features need to be taken into account and what the security team should pay attention to.<\/p>\n

To avoid derailing development and release timelines, establish different rules<\/b> and various show stoppers\u00a0<\/b>\u2014 criteria for halting the build process when vulnerabilities are present \u2014 for different environments.<\/b>For example, we understand that the current branch is heading to the development stage or UAT, which means we do not stop and do not say:<\/p>\n

\u2014 You have vulnerabilities here; you\u2019re not going any further!<\/i><\/p>\n

At this stage, it is essential to inform developers that there are security issues that need attention.<\/p>\n

The presence of vulnerabilities is not an obstacle for further testing.<\/b>whether manual, integration, or manual testing. On the other hand, we need to improve the product's security somehow, and ensure that developers do not overlook the findings of the security team. So sometimes we do this: when a release goes to the development environment, we simply notify the developers:<\/p>\n

\u2014 Guys, you have issues, please pay attention to them.<\/i><\/p>\n

At the UAT stage, we again show warnings about vulnerabilities, and at the production launch stage we say:<\/p>\n

\u2014 Guys, we warned you several times, you did nothing \u2014 we will not release with this.<\/i><\/p>\n

When it comes to code and dynamics, we need to show and warn about vulnerabilities only for those features and code that have just been written in that feature. If a developer moved a button 3 pixels and we tell them that they have an SQL injection and need to fix it urgently \u2014 that is incorrect. Only look at what has been written now and at the changes coming into the application.<\/p>\n

Suppose we have some functional defect \u2014 that is, how the application should not work: money is not transferred, clicking on a button does not lead to the next page, or the product does not load. Security defects<\/b>\u00a0are similar defects, but not in the context of application functionality, rather in terms of security. <\/p>\n

Not all software quality issues are security problems. However, all security problems are related to software quality. Sherif Mansour, Expedia.<\/p><\/blockquote>\n

\nSince all vulnerabilities are similar defects, they should be located where all development defects are. So forget about reports and scary PDFs that no one reads.<\/p>\n

\"Fear
\n
\nWhen I worked at a company that was involved in development, I received a report from static analysis tools. I opened it, was horrified, made coffee, flipped through 350 pages, closed it, and went back to work. Large reports are dead reports.<\/b>Usually they go nowhere, emails get deleted, forgotten, lost, or the business says it accepts the risks.<\/p>\n

What to do? The confirmed defects that have been found are simply converted into a format suitable for development, for example, stored in the backlog in Jira. We prioritize and eliminate defects in order of priority along with functional defects and testing defects.<\/p>\n

Static Analysis - SAST<\/h2>\n

\nThis is code analysis for vulnerabilities.<\/b>, but it is not the same as SonarQube. We check not only against patterns or styles. A range of approaches is applied during analysis: by vulnerability tree, by\u00a0DataFlow<\/a><\/noindex>, by analyzing configuration files. This all relates directly to the code.<\/p>\n

Advantages of the approach<\/b>: identifying vulnerabilities in the code at an early stage of development<\/b>, when there are still no environments or ready tools, and\u00a0the possibility of incremental scanning<\/b>: scanning the part of the code that has changed, and only the feature we are currently working on, which reduces scanning time.<\/p>\n

Cons<\/b>\u00a0\u2014 there is no support for the necessary languages.<\/p>\n

Necessary integrations, <\/b>which should be in the tools, in my subjective opinion:<\/p>\n