DevOps usually emphasizes development and operational activities. But increasingly, the need to inject security into the DevOps context is taking hold.
The fast-paced discipline of DevSecOps is maturing—quickly gaining support and traction both within and beyond information security teams. However, two broad problem areas persist:
- When security is left behind in the DevOps discussion, (useful) security controls aren't fully migrated into the DevOps workflow.
- When teams embed security into DevOps, the security mindset gets in the way of rapid release cycles. This leads to hasty or missed security reviews.
These factors illuminate other issues that arise when an organization attempts to take a collaborative approach to securing applications, including:
- Communication deficiency across teams
- A focus on incorrect security metrics
- A lack of audit and control points
- Vulnerabilities within the deployment pipeline
These challenges don't just affect technology companies; they cut across many different industries as well. The telecom industry, for example, must deal with distributed denial-of-service (DDoS) attacks, while the medical industry is concerned about medical record distribution, and the transportation industry worries about logistics security.
Here's what your team needs to understand about the security policy-development gap and how to get beyond it.
The divide reaches wide—and deep
The problems outlined above can affect several roles within organizations beyond development and operations. Project managers justify technical debt for 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 around security; developers find current security best practices to be insufficient; and operations teams are struggling to make sense of large datasets.
The industry has placed great emphasis on automation. There is an abundance of practices and tools out there for developing, testing, and 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.
When large organizations were asked what the drivers of application security were, general risk management and compliance requirements were the most common responses.
With a closer look at the current body of knowledge around best practices for secure DevOps, it is apparent risk and compliance is barely shared.
Application security was the leading cause of breaches in 2017 and as such ranks high on the list of security priorities for organizations in 2018. Bridging the collaboration gap between development teams, operations teams, risk teams, and compliance teams is needed to truly develop secure software.
At a recent Secure CISO conference, I asked attendees, "Who is responsible for triggering discussions on functional and nonfunctional security requirements?" Responses were split between IT and security. Very few noted that compliance and risk should also be in the picture.
Isolation and ineffective collaboration is the norm
Among security, development, and operations teams, the highest levels of collaboration exist between the latter two. This is unsurprising, because DevOps has been with us for some time. The collaboration between development and security teams is minimal, and collaboration between the operations and security teams still has room to improve. The challenges between development and security teams are really around skills, regulations, and cultural issues. Between operations and security teams, the challenges exist around the vast quantity of data and the ability to effectively use analytics to produce actionable information from SecOps data.
There is a common misconception that development teams understand security. Not all development teams are equal; some have a basic awareness of security that others lack.
All too often businesses assume that development teams will ask security questions based on business-functional requirements, but this is not the case across the board.
From a business-architecture perspective, we must look at three distinct groups: technical teams (comprising development and operations), compliance teams, and security teams. Security teams are responsible for app sec and op sec, vendor risk, and awareness and training. Risk and compliance teams focus on policy creation, policy management, compliance, and auditing.
Focus on the last mile
Security policies don’t always extend properly to developer procedures. Risk and compliance teams typically use a set of best-practice frameworks and standards such as ISO 27001 and NIST 800–53. IT teams use frameworks such as COBIT and ITIL. Thankfully, translations exist between these IT-governance frameworks and industry standards. However, this doesn't go far enough.
What's needed is a way 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.
The industry and development teams are grappling with a complex problem: the need to create secure software applications across different teams while each team undergoes unique disruptions and evolves according to its own schedule. To date, the industry has dealt with this problem by encouraging the retention of deep knowledge within each of these areas. What's missing is collaboration across teams.
Fundamentally, cross-team collaboration is 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, the internal integration and mapping enables the mapping of policy requirements that are being fulfilled.
Shift left or pay the price
When testing or security isn’t considered until the very end of the application lifecycle, it becomes very expensive to go back and attempt to address issues. Injecting security into the pipeline for application lifecycle management is less disruptive.
The discussion today is no longer about isolated, project-based security activities such as penetration testing, code scanning, and security-requirements gathering. Instead, you should be discussing program-level activities that engage multiple teams across multiple projects that all need to be actionable against security policies.
Research shows, and real-world implementations prove, that deep, tribal knowledge, coupled with sharing across domains, is one way to manage the difficult problem of mapping security policies to actionable DevOps procedures.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
