DevSecOps - How to be secure at every step

DevSecOps, shifting left, and GitOps: you’ve probably heard all of these terms recently, but you might not be sure about what they mean. The reality is that these practices share a lot of the same principles—to reduce the time developers need to spend on security, while achieving better outcomes

One of the greatest challenges currently facing security and development teams is striking a balance between speed and security. Application security testing (AST) tools that leverage automation to produce high-quality results must continue to evolve, in order to help organizations bring these two components together. The goal should be to shift to a true DevSecOps model, by automating vulnerability detection and triage to reduce secure software time-to-market.

By automating the steps required to scan code earlier in the SDLC, it eliminates the need for time-consuming manual configuration of scans. It also allows developers to publish and update scan findings, based on a pre-configured policy within the code management tools. After the initial configuration, AST scan activity is performed hands-off with no human intervention required, beyond a pull request initiated by a developer.

What is DevSecOps: Applying DevOps principles to security

DevOps is an increasingly popular trend in recent years—a shift that makes developers more accountable for operational issues. The idea is that when a system goes down, it’s everyone’s responsibility to fix it. And so is preventing outages to begin with. Rather than separating development and operations,

The same mindset shift you’ve seen in the industry generally with a move towards DevOps has also been felt within security specifically. It’s commonly called DevSecOps. This is about making all parties who are part of the application development lifecycle accountable for the security of the application, just as they are accountable for operations and supportability.

So is there is difference between DevOps and DevSecOps? In the first, everyone becomes accountable for outages, even if they don’t manage the infrastructure. Just like the business goal of DevOps is fewer outages, the business goal of DevSecOps fewer outages along with is no data loss. DevSecOps addresses the concern of development teams not satisfactorily addressing security requirements.

With the term Continuous security being talked about now, there is a parallel being drawn to continuous integration and continuous delivery: which means you should continuously integrate security into your development process as well. Since this is a mindset shift, there’s no canonical list of practices, but rather the principal change is to apply security practices earlier in the development lifecycle.

Focus on Shifting left, including security controls

In practice, to hold teams accountable for what they develop, processes need to shift left to earlier in the development lifecycle, where development teams are. By moving steps like testing, including security testing, from a final gate at deployment time to an earlier step, fewer mistakes are made, and developers can move more quickly. The principles of shifting left also apply to security, not only to operations. It’s critical to prevent breaches before they can affect users, and to move quickly to address newly discovered security vulnerabilities and fix them. Instead of security acting as a gate, integrating it into every step of the development lifecycle allows your development team to catch issues earlier. A developer-centric approach means they can stay in context and respond to issues as they code, not days later at deployment, or months later from a penetration test report. Shifting left is a process change, but it isn’t a single control or specific tool—it’s about making all of security more developer-centric, and giving developers security feedback where they are. In practice, developers work with code and in Git, so as a result, we’re seeing more security controls being applied in Git.

Benefits of DevSecOps By including security at every stage of the software delivery lifecycle, the cost of complying with regulation and governance standards is reduced overall and the speed of software delivery is increased. Simultaneously, greater transparency enables superior threat hunting across the board and much more flexible reaction and recovery times

• Cost reduction is achieved by detecting and fixing security issues during the development phases

• Speed of delivery is increased as security bot‑ tlenecks are minimized or eliminated

• Speed of recovery is enhanced in the case of a security incident by utilising templates and pet/ cattle methodology

• Enhanced monitoring and auditing leads to improved threat hunting, which reduces the likelihood of a breach, avoiding bad publicity and reputational damage (to say nothing of regulator fines)

• Immutable infrastructure allows companies to tear down infrastructure while managing an attack vector identified by scanning. If a node is compromised, it won’t remain compromised for long, as it will be torn down and rebuilt with new credentials. Zero defects in the code is the ideal to aim for, although zero variations are the minimum requirement.

• Security auditing, monitoring, and notification systems are managed and deployed so that they can be continuously enhanced, to keep in step with the frantic innovation intrinsic to cybercrime.

• Ensures the ‘secure by design’ principle by using automated security review of code, auto‑ mated application security testing, educating, and empowering developers to use secure design patterns

• Creates targeted customer value through se‑ cure iterative innovation at speed and scale

• Security is federated and becomes the re‑ sponsibility of everyone, not just a specialized team, or even individual

• DevSecOps fosters a culture of openness and transparency from the earliest stages of development

Best Practice DevSecOps Successful security programs are comprised of three intersecting parts: people, processes, and technologies. DevSecOps is no different, but DevSecOps recognizes that security is the responsibility of everyone in an organization, and everyone has a role to play in security

PEOPLE

No matter how many technologies you implement, the weakest link will always be the human factor. This is the starting point for any DevSecOps implementation

Breaking Down Silos and Integrating Security Personnel

For security to be effective, we need to include security personnel as early as possible in the software delivery pipeline. One way of doing is this is with security champions. Security champions are “members of a team that help to make decisions about when to engage the Security Team. Security champions act as the ‘voice’ of security for a given product or team, and they assist in the triage of security bugs for their team or area.” This role is also responsible for reporting on project status to the security advisor and to other relevant parties (for example, development and test leads) on the project team. Security Champions are a key element of the DevSecOps methodology, since they are the first step to creating a cross-functional team focused on application security and security operations.

Cross-functional teams are created from experts, influencers and diverse members to foster serendipitous conversation and tackle issues outside of the boundaries of rigid meetings. Some of the most important duties of the security champion include the following:

• Ensure that security is not a blocker on active development or reviews

• Empowered to make decisions

• Work with AppSec team on mitigations strategies

• Help with QA and Testing

• Write Tests (from Unit Tests to Integration tests)

• Help with development of CI (Continuous Integration) environments.

Training

Any successful DevSecOps programme will invest in good training and professional development for its staff. To foster and develop good security staff, organizations must provide new hires with the appropriate training and tools they need to do their jobs well, and to contribute to the successful release of secure software. Engaging specialist security and DevOps training organization(s) to raise staff skills and awareness are essential for maintaining consumer trust. Training can be computer-based, instructorled, or a combination of both. Good training ensures that standards are implemented correctly. Training must be rooted in company goals, policies, and standards for software security, and learning media must be flexible and tailored. Although software developers are typically not meant to become professional pentesters, it is still valuable to teach them about the attacker’s perspective, and about practical hacking

PROCESS

People implement the processes in any organization. Processes are typically siloed within separate IT teams, which leads to miscommunications, bottlenecks and delays. DevSecOps aims to align and implement processes common to an enterprise to facilitate cooperation and achieve more secure development processes as a whole

Version Control, Metadata, and Orchestration

Within an automated world, the only constant is change, and change needs to be both consistent and traceable. To track all changes, we must ensure that adequate and immutable versioning is in place. To allow for quick recovery, every action needs a version, in the same way that code is managed. Once turned into metadata, operations teams can efficiently track a change and measure it. Orchestration software doesn’t only provide a repeatable way to deploy infrastructure, it also provides a huge amount of metadata regarding any task.

Integration of Processes

Integrating information security into agile development enables organizations to have a fully secure workstream through every single stage of the project development cycle. In the agile world, the integration of security must start at the earliest possible stage which in most cases is the requirement definition stage. This methodology has been called ‘shifting security left’ and it strives to reduce the cost of implementing security.

Compliance

Implementing compliance doesn’t have to be a paper -based exercise. We can create metadata representing the compliance requirement and integrate it in our assets. This can also be used by security policy automation by tagging assets that can in turn implement the desired security architecture, for example, zoning. Imagine the ability to respond to a breach under the new GDPR rules in 72 hours. By codifying your compliance requirements, they can be automatically rolled out across your assets and continuously refreshed.

Incident Management

Responding to security incidents should not be an improvised or non-scripted activity. It is key that workflows and action plans are created in advance. This is to ensure that the response to an incident is consistent, repeatable, and measurable. Incident management should make use of the metadata to help simplify this process, thus changing the metrics to highlight the time taken to redeploy a compromised asset. In turn, once the playbooks have been codified, they can be integrated into your CI/CD pipeline to automate them. In a DevSecOps world, proactive and preemptive threat hunting as well as continuous detection and response to threats and vulnerabilities mean that there are fewer major incidents and more mitigations.

Red Teams, Blue Teams and Bug Bounties

The use of red teams, blue teams and bug bounties also mitigate against breaches. The purpose of red teams is to test the effectiveness of security programs. Blue teams defend against the red team’s attacks. All companies should deploy a red team to hunt for threats as part of the DevSecOps methodology. Red teams are built from security team personnel and are usually virtual to facilitate their ad hoc nature. Instead of discussing what is wrong with an application, the red team demonstrates what is wrong and provides the solution. This allows for a positive feedback loop between security and the developers, demonstrated by clear recommendations to improve the software quality. During a red team attacking phase it can be beneficial to have your security champion take on the responsibilities of a blue team member, analysing logs and network activity to look for patterns and to give some idea of the attack vectors the red team are employing. This not only gives valuable experience of being able to spot when a malicious attack is in progress against your production environment, but can also allow development teams to foresee an upcoming compromise and potentially patch this before it is found by the red team. All companies should also, occasionally, implement bug bounty programs. These are rewards given for finding and reporting a bug in a software product.

TECHNOLOGY

Technologies are what enable your people to properly execute DevSecOps processes. This section outlines the required technologies to implement a successful DevSecOps methodology within your enterprise

Automation and Configuration Management

Leveraging automation and using orchestration to implement DevSecOps is key to success. Orchestration and automation make auditing easier through the use of metadata making decisions easier to achieve as they are based on data points and repeatable processes. The use of templates within configuration management helps to implement traceability of each code/configuration change, thus making it easier to identify the root cause of an issue and any deviation from immutable artefacts

Secure Coding Practices/ Security as Code

All coding standards must be constantly checked against new security recommendations. All changes to the code need to be verified and tested against these recommendations: no change is too small to avoid in this process. This is not a trivial exercise, and the benefits associated with such practices should not be underestimated; they are not limited to the amount of changes occurring in the development lifecycle.

Host Hardening

The practice of host hardening is not new but, if it were used more often, fewer services and applications would be unnecessarily exposed to the Internet. Countless examples of security incidents can be directly related to leaving a generic attack surface that allows automated attack tooling to succeed in even the most basic attacks. The Center of Internet Security has developed a set of industry-standard benchmarks for infrastructure hardening. The hardening checklist and methodologies are mature enough to be easily included in the creation of templates to reduce the attack surface, reinforce a trust model and can be codified into compliance tooling such as Inspec. The trust model can be codified as metadata for further processing by the CI pipeline, and then used for other processes such as patching.

CI/CD for Patching

Once your metadata has been associated with each asset, we can use this data to implement patching at the CI/CD level. Feeds from Threat intelligence and Vulnerability Management are compared to the deployed software stack to identify matches in the templates in turn queued for deployment. Patching live systems becomes a thing of the past, thus limiting the impact of downtime. This will also provide the ability to have a risk exposure in near real time.

Application-level Auditing and Scanning

Auditing and scanning are a crucial aspect of DevSecOps that allows business to understand fully their risk posture. Each of the following solutions represents a higher degree of security assurance of the code, as reflected in the organization’s risk appetite

1. Source Code Scanning

2. Dynamic Application Scanning Tool

3. IDE Integration

4. Binary Scanning

Pre-Deployment Auditing

Using a pre-defined template for building assets is essential to ensure the desired internally certified security level. Validations should be blocking and required to be integrated into a CD pipeline at this stage, since this is the last turn before the exit. Applying this principle to infrastructure as code enhances compliance by ensuring that not only your software, but the infrastructure you deploy it on is automatically compliant. This also has the advantage of engaging security teams early in the software development pipeline, rather than announcing their requirements at the end.

Post-Deployment Auditing

The idea behind Post-Deployment Auditing is to ensure that the certified security level which you achieved with Pre-Deployment Auditing is still applicable and valid. That’s why the number of Post-Deployment tests usually exceeds Pre-Deployment tests. There are several ways to achieve a postdeployment audit. An instant validation can be triggered just after the infrastructure build or an automated regular auditing can be scheduled based on your business needs. Both are recommended, since early detection is one of the pillars of DevSecOps

To summarize, DevSecOps is the mindset shift to recognize and continuously apply security practices as part of the development lifecycle, with responsibilities shared across teams. This is frequently accompanied by shifting security testing left to earlier in the lifecycle as part of development. This keeps security—and developers—in the flow and in context, allowing security issues to be addressed earlier. And, by using Git as a source of truth for your environment, you can more easily apply these principles not only to your code, but also to everything around your code, like your configurations. There’s no one way to apply these concepts, but rather, they are acknowledgement that security is an increasingly important and integral part of your development workflow today.