Take a risk-based approach to DevSecOps: Embedding cyber security in application development

Just as rapid, secure and modular code development can help drive digital transformation, insecure code can add risk and ultimately undermine digital transformation efforts. The release of “buggy” software — that requires time-consuming revisions or introduces unknown vulnerabilities that result in costly breaches — can lead to a loss of trust among developers, security teams, customers and business leaders. There is also the hidden cost of unmanaged patch processes.

Per numerous estimates, 50 percent to 90 percent of all successful exploits against enterprises and systems can be traced back to vulnerabilities in software as the root cause. So companies must take proactive steps to protect against software vulnerabilities by baking security into the DevOps process, rather than bolting it on at the end. Firms should also be better prepared for their reactive processes, such as vulnerability disclosure programs, penetration testing and vulnerability bounties.

If we consider DevOps to be an environment in which developers who think and act like operators work collaboratively with operators who think and act like developers, then DevSecOps is the extension of that orientation. In such an environment, security concerns that affect activities from development through release and run would be addressed up front, ensuring confidentiality, integrity and availability. The entire process requires the CIO’s commitment to introducing new policies and processes
to bring developers and security teams together.

Organizations today should consider operating in a comprehensive DevSecOps model to enable secure digital transformation. DevSecOps supports faster release schedules and innovation, but for this approach to succeed, organizations must make fundamental commitments, including changing the culture of collaboration, building security throughout the development life cycle, and evaluating technical and business risks.

Identifying the problem

The issue of security is so broad and diverse that embedding it in a continuous integration and delivery pipeline can be a daunting task. For example, in the development phase your developers will need access to build and test environments. How will these be managed to ensure that appropriate controls are in place? Will you enforce controls on local versions of applications services, such as messaging and database, so they align with access controls that will be applied to the application in production? How will you manage credentials needed by applications to authenticate application services?

Align development, operations and security

Critical to the facilitation of DevSecOps is the separation of concerns, e.g., separating configuration from application, which is a facet of cloud-native application development. Many organizations are finding it complex to merely align development and operations; certainly, this third dimension will have its challenges as well. Automation, frameworks, and strong policy and governance will, ultimately, simplify the cooperation required for this type of environment. However, you should expect that at the beginning, it will be seen as disruptive and burdensome.

A few companies have long understood that security should be a part of the software development process, and the industry has come up with a variety of frameworks over the years, such as the Open Software Assurance Maturity Model (OpenSAMM) and the Building Security In Maturity Model (BSIMM). A general term for security in the software development life cycle, which we’ll use in this paper, is the secure software development life cycle (Secure SDLC).

Implement a Secure SDLC

The idea is to spot early in the process any potential problems, such as missing or incomplete security requirements and vulnerable architecture, design, libraries, platforms, function calls or code. In practice, however, few companies have successfully implemented a Secure SDLC. Or if they have, it has been applied ad hoc
and with limited scope.

A key inhibitor is the fundamental tension between the developer’s desire to move quickly and the security practitioner’s need to minimize vulnerabilities, even at the risk of slowing things down. That tension was already present in the older world of waterfall-style application development and has only been exacerbated by the move to agile development, where release cycles are quicker, the lines between the various steps in the process have become blurred and processes can overlap. In the agile development world, the increase in velocity also increases the risk that errors will be introduced into the process.

Understand the impact of “technical debt”

The authors would like to introduce here the concept of technical security debt. In software development, technical debt refers to suboptimal decision making that sacrifices long-term benefits for short-term gains; for example, quick-to-implement hacks, poor requirements gathering or just lack of knowledge. However, over time and with increasing changes, this debt accumulates. The higher debt then needs to be paid off by implementing increasingly difficult-to-make changes. Let’s take this concept of technical debt and apply it to DevSecOps, where debt can be in the form of known or unknown vulnerabilities (security defects) that arise through poor security governance of the software development and release processes.

When developers race through the software development life cycle without appropriate support and governance, hidden technical debt (e.g., unknown vulnerabilities) builds up.

CATA: Foundation for future development

The good news is that there are ways to design security into the DevOps process, such as using DXC Technology’s Comprehensive Applications Threat Analysis (CATA) service. The long-term benefit of CATA is ensuring that the architectural and security recommendations become the foundation for future development projects. DevSecOps enables teams to create infrastructure and security as code, going forward. The long-term results are improvements in consistency, quality and reliability. The challenge is that full-blown threat analyses such as a CATA review could take 3 months or more, so it’s critical for organizations to perform routine scanning more frequently to meet the demands of a weekly or biweekly code release schedule.

Let’s consider: If the technical debt is not addressed, applications might need minor revisions or complete rewrites, which effectively cancels out the benefits of agile development. Even more critical, vulnerabilities remain undetected and uncorrected, which could ultimately cause major security breaches or exploits. Real examples from the news include hospitals being held hostage to ransomware; or organizations having many people’s credit card and Social Security numbers stolen, leading to the risk of mass identity theft or disclosure of Protected Health Information (PHI). In the case of software vendors, this feeds the patching cycle of their customers, which assumes a vulnerability disclosure process with which to notify the market of such issues.

It’s the old “you can pay me now or you can pay me later” scenario, and similarly, the economics reflect that of personal finance. Paying later comes with interest, except that in the case of defects and vulnerabilities, the interest rates are exorbitant (fixing issues post-release can cost orders of magnitude more than during the early life cycle). The preferred approach is to reduce/repay technical debt as early in the pipeline as practical, before it accumulates. Periodic security reviews are able to turn hidden technical debt into visible technical debt, which is then drained down far sooner and at lower cost than without such security reviews.

Short- and long-term assessments

This is a continuous process that needs to be prioritized, especially for specific applications, based on their risk profile. Such a process most benefits those organizations that know the value of their information assets and have a policy
and process(es) in place to classify them.
Gearing to technical debt refers to a way of calibrating the weekly or biweekly pace of agile development sprints against the much slower cycle of security reviews. Applying the principles of gearing to technical debt is critical to the successful implementation of DevSecOps.

Here’s how it might work. A security scan might be applied every five iterations or sprints for a high-risk application and applied every 20 sprints for a low-risk application. And a full CATA review might be conducted once a year for a low-risk application. For a high-risk application, it might be conducted twice a year or at the time of a major release, whichever comes first. This CATA assessment would cover all changes made to software applications over the period in question.

Understanding the roles of CIO and CISO

Ideally, a move to DevSecOps should start at the top, although it doesn’t always have to. But a chief information officer (CIO) who is driving digital transformation should create policies designed to bridge the gap between developers and security teams. There must also be an effort to change the culture and to bring developers, operations teams, security groups and business units together so that they all understand how important DevSecOps is to the company’s overall success.

Continue reading about DevSecOps assessment strategies and tools for securing rapid application development practices.

Contact us to learn more about improving cyber resilliency throughout the enterprise.