To understand an enterprise’s current state of software security risk, executives, security practitioners and development teams need information. Benchmarks provide useful information on performance and risk. However, ideas about which benchmarks are most important will differ depending upon the corporate stakeholder to whom you’re speaking.
For example, a business decision-maker has to justify the expense of technology purchases, and so their focus might be gauging the efficiency of application security investments in alleviating business risk. However, assessing how the company’s applications perform against wider industry standards for vulnerability or remediation might be what keeps a security professional up at night. Still, the development and OpEx teams are tasked with moving ever faster and using methodologies that shorten the software life cycle, yet still comply with the company’s overall security policies – a tricky tango of goals that are often seen as incongruent.
As a practice, DevOps helped to redefine the relationship that links enterprise development with IT operations, the goal being improved communication and collaboration between the business units. DevSecOps, therefore, is a similar philosophy or culture, defined by continuous, agile collaboration linking release engineers with security teams, the goal being to realign security best practices with DevOps processes through the code itself.
Especially in cloud-based settings, information security advocates encourage adoption of the DevSecOps approach, to create a similarly positive impact that DevOps had on the development and OpEx teams. This produces an environment where ensuring security as foundational principal becomes automatic and instinctive, not an adjunct to the process.
What then, are the top considerations for reducing security risk? Recently, I co-authored a paper through the Cloud Security Alliance that identified the Six Pillars of DevSecOps. Here’s an explanation of some of the insights we shared.
Move the culture mountain
The old adage, ‘change is hard,’ was coined for good reason. In this case it may ring true too, because shifting an organization’s collective mindset regarding security can sometimes feel like you’re trying to move a mountain. And, depending upon your organizational stakeholders’ history for dealing with cultural change, that mountain might as well be Mount Everest.
However, sometimes change happens easily because the goal is clear to all involved. At the core of this effort is getting every stakeholder, regardless of individual responsibilities, to invest in the security of the company. They must clearly see and understand their role in ensuring security at the foundational levels of everything they do. Beyond that, their outlook or acceptance of the security process should be linked to the company’s business objectives, so that efforts to enforce it can be accurately measured.
When every employee is responsible for the security posture of an organization, the company is strongly positioned for better outcomes.
Align in the sand[box]
Similarly, once you have cultural buy-in, building the bridge to closer collaboration and true organizational partnership for the development, operations and security roles is not as difficult. And even more good news is, that by aligning these disciplines more closely, organizations can remove previously confrontational, hard ‘lines in the sand,’ and begin to address the vast skill and talent shortages in the software landscape. With eyes toward building a successful security posture, cross-functional teams are more productive at reporting potential risks and anomalies.
Remove complexity for a universal view
For every positive aspect of culture change and increased collaboration, there are likely to be some consequences. While many enterprises have started to adopt a DevSecOps model and implement security across the software lifecycle, for some, this has led to enormous operational complexity. Development and security teams are struggling to manage and maintain an abundance of security tools, and it’s pulling time and resources away from more critical tasks while also negatively impacting productivity.
Despite the propagation of application security tools, services and platforms in recent years, very few offer universal security management across the entire software lifecycle. The high cost of using, managing and supporting so many point solutions results in a lack of actionable security metrics, which makes reporting a burden.
However, for a universal view of the software lifecycle, that includes the organization’s security needs, as well as the goals of its security program, a platform that offers significant integration to meet the needs of stakeholders (development, operations, and security) and ensures security is built into applications, as well as the lifecycle, is prescribed.
Mind the gap with compliance
A truly risk-averse organization will not only be keenly aware of its regulatory requirements, it will have processes in place to ensure its compliance. Compliance might indicate that certain security standards and regulations are met, for example the security standard of PCI DSS, which applies to the handling of credit card data. Or maybe the security requirements included in legislation such as the European Union’s General Data Protection Regulation (GDPR). However, complying does not necessarily mean secure – these are two distinct considerations.
Further complicating the issue of compliance is, as stated earlier, that incongruent priorities have emerged between software development practices like Agile, and the regulatory and compliance function, which is centered on process.
Therefore, enterprises must look beyond compliance with security standards and regulations, to address security within products and DevOps processes, too. With appropriate controls and interpretation of metrics, organizations can reveal nuances in the software lifecycle where automation can improve the quality of risk mitigation and therefore compliance.
Use automation to an advantage
It’s hard to discuss the previous points about culture, collaboration and integration without eventually addressing functional ways to make them work for an organization. One reason secure deployment doesn’t happen faster is that organizations still struggle with things like manual and haphazard coding, testing, deployment and patching practices.
In a time where automation is so often hyped for the efficiency it creates, why would any company want to risk poor performance or vulnerable, insecure software if there’s a faster, easier way to accomplish quality checks?
Automated security practices should guide teams, and any process that can’t be automated should be examined for its relevance and then removed if its purpose cannot be justified. A word of caution: it is possible to create new issues with automated security checks, but workflow improvements and semi-automated approaches are a helpful remedy.
Begin with the end in mind to measure success
To decide whether the improvements to securing the DevOps process have been successful, organizations must examine actionable metrics. According to Dr. Stephen Covey’s habits on productivity, companies should “begin with the end in mind,” as a guiding principal to help determine which metrics are most useful before embarking on a complex DevSecOps initiative that could take months or years to implement. The danger of skipping this part of the process is that you will lack visibility into progress, and also failure, which leads to vulnerability if not discovered aptly.
Some recommendations for what to measure in DevSecOps are deployment metrics that indicate the health of your deployment process and ensure that applications are stable. These include frequency, vulnerability patch time, percentage of code automatically tested, and automated tests per application.
In defense of the DevSecOps approach
The proliferation and portable nature of powerful computing devices have led to an ever-increasing expectation for available services. The app economy and the need to constantly deliver new code and new features has given way to trends like DevOps, Microservices and Open Source, and forced the acceleration of deployment cycles. These faster business conditions make the detection and remediation of vulnerabilities even more difficult, resulting in greater security risks.
By ensuring that security is directly built into DevOps, companies can experience significantly better outcomes. This includes having earlier and enhanced control over the security-related performance of the software development life cycle and reducing complexity in the creation and delivery of software. Perhaps more importantly, a DevSecOps approach can galvanize your software development teams to embrace a new culture for monitoring their work, and sharing resources that ultimately deliver a higher quality, secure product to the market.