5 Circular Phases of Sec in DevSecOps

In the ever-changing landscape of Appsec and DevOps, we have recently started to talk about shifting center instead of shifting left. This is because there is no right or left in the circular movement of software development which DevOps symbol perfectly demonstrates. You can also shift center and integrate Sec into entire DevOps through 5 continuous circular phases ;

1. Threat Modeling

2. Scan

3. Analyze

4. Remediate

5. Monitor

Before diving into each phase, it is worth noting that like DevOps, DevSecOps is also a matter of culture. As well as testing your technical expertise, building a solid DevSecOps pipeline will also test your soft skills. Co-working with various team members and defining mutually agreed processes and metrics will be key to a sustainable workflow.

Once you define the processes and convince the people, AppSec tools come into play in the third place and should be the least of your worries. Tools and people can change over time but the culture you create through processes and metrics determines the sustainability of DevSecOps.

Now let’s take a look at the steps we need to go through for a successful DevSecOps adoption.

THREAT MODELING

Unaware of the time that could be saved through proactive thinking, threat modeling is often the most overlooked phase of DevSecOps. A proper threat model considers the possible attack scenarios, lays out the flow of sensitive data within the application, finds mitigations to threats, and repeats itself every time there is a change in the design of the application or a new feature.

Not only useful for improving the knowledge of all stakeholders on security architecture and removing vulnerabilities even before they exist, threat modeling also allows a quicker decision making in the analysis phase.

A self-service model where each team conducts threat modeling for each work item included in the sprint can be useful to spread defensive programming approach within the organization. Questionnaire templates containing certain questions can be filled out in the planning phase to identify risk factors in a standardized way and code accordingly. Some first-level questions to ask for evaluating the risk could be;

• What is the technical difficulty of a successful attack?
• What is the worst possible outcome of a successful attack?
• How many users would be affected?
• How sensitive is the data that can be stolen?
• How accessible is the target?

OWASP Threat Dragon is an open source threat modeling tool that can be a useful stepping stone for starters. STRIDE is a model for identifying and classifying the security threats and stands for six types of threats which are;

• Spoofing
• Tampering
• Repudiation
• Information Disclosure
• Denial of Service
• Elevation of Privilege

SCAN

This phase consists of all manual or automated methods used for identifying vulnerabilities.

Penetration tests were the only go-to solution for most businesses until a few years ago. They are still much better than automated scanners at identifying complex vulnerabilities such as business logic flaws. However, their discontinuous nature has forced businesses to adopt AppSec tools to continuously run security tests in their development pipelines.

Automated scanners that run in different phases of DevOps play a vital role in discovering low hanging fruit vulnerabilities which are among the most common elements of exploit chains in complex attacks. Surprisingly, most of the time cyber attacks do not target zero-day vulnerabilities but these well-known and easily discoverable vulnerabilities.

While performing security tests in the coding and building stages of DevOps with SAST or SCA tools is crucial to minimize the cost of fixing vulnerabilities by catching them earlier, DAST is still needed in the testing phase to perform a block box test through the eyes of an attacker and make sure no doors are left unlocked before production.

IAST, with no false positive results, and easy remediation is also gaining popularity. On the downside, code instrumentation makes it language-specific and the performance can vary significantly between different programming languages. Coverage of IAST also depends on the test scenarios that are performed by the tester which makes its efficiency depend on the users.

No matter what technology is used in the coding and testing phases, security scans keep on after the deployment phase to make sure the containers and the infrastructure that the applications are running on such as ports and operating systems are not vulnerable.

Even though there are various tools used for different purposes in DevOps, lately we have been seeing consolidation efforts in the market. Tools known as software development platforms are now enabling CI/CD features or adding source code analyzers to their offerings and major cloud hosting services have also added certain scanning capabilities. This is a positive evolution for managing tasks at the intersection of AppSec and DevOps from one place.

It is highly recommended that you check your software development platform and cloud hosting service for any embedded scanners to start scanning your code and finding out vulnerabilities before someone else does in production.

There are also many open source SAST, DAST, SCA and container security tools which you can start using immediately. If you still claim you do not have enough funds to start working on Sec of DevSecOps, it is time to stop complaining and roll up your sleeves.

Bug bounty programs also come in handy to spot deeply rooted vulnerabilities which are ideal for organizations that have sufficient human resources to check for the reliability of reported vulnerabilities and the financial power to fund the project. So if you rely on the resources of your organization, it is worth giving them a shot.

ANALYZE

Scanning is only a means to identify the vulnerabilities before an outside attacker does. What determines your success is what you do afterward with those vulnerabilities. You need to correlate vulnerabilities coming from multiple scanners, eliminate false positives and prioritize the most critical ones over others for speedy remediation. A major challenge at this point is having vulnerabilities scattered out across different scanners and engage in manual time-consuming consolidation activities.

Regardless of the size of an organization, security teams are almost always understaffed in today’s world. Near future offers little hope and unfilled cybersecurity positions in the world are expected to reach 3,5 million by 2021. Even more so for AppSec which is relatively a new field in cybersecurity where the talent pool is not as deep as network security. Considering the shortage of staff and abundance of vulnerabilities, threat modeling manifests itself as a lifesaver for speedy and accurate analysis of vulnerabilities.

Vulnerability management tools like our beloved Kondukto are also useful to automatically feed scan results into their platforms and provide a holistic view of consolidated and correlated vulnerabilities. Having all data in one place leads to more accurate and quicker decisions on which vulnerabilities are worth fixing. Prioritizing the right vulnerabilities is key to success and allocation of scarce resources to irrelevant vulnerabilities is a costly mistake.

REMEDIATE

Application security vulnerabilities are mostly fixed by software developers and this is the phase where soft skills are needed more than ever. Priorities and skill sets of software developers and security engineers are totally different and without solid processes in place, vulnerabilities are swung back and forth like a pendulum between security engineers and developers which results in endless conflicts between two teams.

The hardest part is coming to an agreement with software developers on acceptable fix times of vulnerabilities. If this can be achieved, future conversations are much more likely to be driven by data instead of momentary temper and with numbers speaking for themselves there will be no hiding places for anyone.

To shorten the time to fix vulnerabilities, creating an internal remediation wiki and making it accessible by software developers is a useful tactic which is also possible on Kondukto. If developers have reliable information based on previous experiences of peers on how to resolve issues, the time to find the right solution to the problem is dramatically shortened.

MONITOR

Monitoring is meaningful only if you have measurable metrics. Just like in the monitor phase of DevOps, this phase consists of tracking how far off we are from the target values of our metrics. Differences between the actual and the target values pave the way for identifying bottlenecks and smoothening the rough processes.

Separate metrics can be defined for each phase such as % of projects that have a threat model in place, coverage of SAST scans, no. of vulnerabilities assigned to developers for remediation, mean time to fix vulnerabilities, and so on. Having north star metrics in each phase makes it easier to pinpoint which phases are performing well and in which phases there is still room for improvement.

Setting metrics and tracking them regularly will help you create an organization-wide awareness and lead to data-driven conversations when it is time to measure the efficiency of your Sec program.

Remember, the cycle does not end here as we have a circular flow. Now it is time to circle back to Threat Modeling to tweak what we have done wrong and try to do better this time.

Yes, there will be ups and downs and it will not be easy but let these words of Samuel Beckett give you courage for the next time when you feel something is going wrong.

“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.”