Usually when we talk about DevOps, there's an emphasis on development and operational activities. Often, a key focus is neglected: how we inject security into the DevOps context.
If we examine the confluence of events leading to the current issues we face around security and DevOps, two broad factors become clear. For one, security has been left behind in the DevOps discussion, as traditional (useful) security controls haven't fully migrated into the DevOps workflow. Secondly, for those teams that embed security into DevOps, the security mindset gets in the way of rapid release cycles. This leads to hasty or missed security reviews.
These two broad factors illuminate various issues:
- A communication deficiency across teams
- A set of anti-patterns at the program level
- A focus on incorrect security metrics
- A lack of audit and control points
- Vulnerabilities within the deployment pipeline
Lest we think these issues are only for technology companies, it cuts across a number of different industries. The telco industry has to deal with Distributed Denial of Service (DDoS) attacks, the medical industry is concerned about medical record distribution, and the transportation industry worries about logistics security - just to name a few.
It doesn’t stop there. It affects several roles within organizations, not just development and operations. Project managers justify technical debt and poor security practices to accommodate a quick release; quality assurance can’t clearly deem the software’s security as bug free; customers don't know what to ask for regarding security; developers find current best practices to be insufficient; and operations teams are struggling to make sense of large data sets.
The industry has placed great emphasis on automation. Not surprising given the historic context around DevOps. There are an abundance of practices and tools out there around developing, testing, deploying through automation. The challenge arises when the focus shifts to security, compliance and risk, as we find stormy collaboration between developers, operations teams, security teams, risk teams, and compliance teams.
Drivers of application security
When we asked large organizations what the drivers of application security were, they told us that general risk management and compliance requirements were the top two.
If we take a look at the current body of knowledge around best practices for secure DevOps, we barely hear about risk and compliance. Here’s what our research shows:
We know that application security ranks very high on the list of priorities for organizations in 2018, so we need to figure out a way to help bridge this collaboration gap between the development teams, operations teams, risk teams, and compliance teams if we are to truly develop secure software.
At a recent SecureCISO conference, we asked who is responsible for triggering discussions on functional and nonfunctional security requirements. Responses were split between IT and security as being responsible. Very few indicated that compliance and risk should also be in the picture.
We are isolating ourselves and ineffectively collaborating across the various teams.
If we take a look at security, development, and operations teams, the highest levels of collaboration exist between the latter two. This is not surprising, because DevOps has been with us for some time. The collaboration between development and security teams is minimal, and collaborations between the operations and security teams still have room to improve. The challenges between development and security teams are really around skills, regulations, and cultural issues. The challenges between operations and security teams, include the vast quantity of data, and the difficulty in effectively using analytics to produce actionable information from SecOps data.
There is a common misunderstanding that development teams understand security. Not all development teams are equal; some have a basic awareness of security that others lack.
Unfortunately, a business often assumes that development teams will ask security questions based on business-functional requirements, but this is not the case across the board.
Continuous Security Compliance
Fundamentally, we have to look at three different groups from a business-architecture perspective: technical teams (comprising of development and operations), compliance teams, and security teams. Security teams are responsible for App Sec and Op Sec, vendor risk, and awareness and training. Our risk and compliance teams focus on policy creation, policy management, compliance, and auditing.
Security policies don’t always extend properly to developer procedures. Our risk and compliance teams typically use a set of best-practice frameworks and standards like ISO 27001 or NIST 800–53. IT teams use frameworks like COBIT and ITIL. Thankfully, translations exist between these IT governance frameworks and industry standards. However, this doesn't go far enough. We really need to address the last mile gap that goes from high-level IT governance frameworks to actual tasks and procedures that development teams can act upon.
We are dealing with a complex problem: the need to create secure software applications across a number of different teams while each team undergoes unique disruptions and evolves according to their own schedule. We deal with this problem by encouraging the retention of deep knowledge within each of these areas. What's missing is collaboration across teams.
Fundamentally we are talking about tracing a given policy to application archetype, then determining which policies apply to those archetypes and converting that into actionable statements that development teams can execute. Then, as these development teams complete their tasks, internal integration and mapping enables the mapping of policy requirements that are actually being fulfilled. At any point, we should be able to defend our application portfolio security posture.
When testing or security aren’t considered until the very end of the application lifecycle, it becomes very expensive to go back and attempt to address those issues. Our method of injecting security into the pipeline for application-lifecycle management is less disruptive.
The discussion today is no longer about project based security activities like penetration testing, code scanning, and security requirements gathering as isolated activities. We now need to consider program level activities that engage multiple teams across multiple projects that all need to be actionable against security policies. Our research shows that deep tribal knowledge coupled with sharing across domains is one way to manage this difficult problem of mapping security policies to actionable DevOps procedures.