By Piyush Sharrma, VP of Cloud Security at Tenable
Amidst the dizzying uptake of cloud-native technologies to meet shifting customer demands, cybercriminals are capitalizing on cloud misconfigurations, like unsecured storage buckets, passwords or encryption keys in open repositories, improper access controls and others, posing a threat to organizations. Simple cloud misconfigurations have exposed data for countless individuals and could have major financial implications for an affected company.
When business continuity is tied to cyber resilience, organizations cannot ignore the importance of taking a security-first approach to codifying how infrastructure should be configured. Traditional modes of securing software are not enough to detect and prevent a breach, because software development and delivery have inherently changed with the move to the cloud and codification of cloud governance. Because by the time software reaches runtime, it’s already too late. The detection of cloud misconfigurations needs to move from reactive to proactive so that security teams don’t have to wait for infrastructure to be created in order for them to discover and mitigate vulnerabilities in code. This also means that security teams need visibility into the entire line of operations.
While this all sounds reasonable, there is reluctance from DevOps teams when it comes to working with security teams largely because security is seen as an impediment to innovation. Here we chip away at three iceberg misbeliefs that pose a barrier between security and DevOps.
Iceberg belief 1: Security puts the brakes on DevOps
Fixing outages quickly is important, but it discounts newly introduced vulnerabilities and misconfigurations that aren’t being tested or measured against. In an age where cybercriminals are looking for the easiest attack pathway, security needs to be codified throughout the development lifecycle, not at run-time. In cloud environments, cloud infrastructure needs to be born secure. Organizations need IaC tools that generate the code to remediate risks so developers can simply mitigate them before it is deployed. This developer-first approach allows organizations to fix vulnerabilities quickly without worrying about them at runtime. Organizations need to view DevSecOps as an innovative approach rather than an impediment as it makes organizations cyber resilient to the very core.
Iceberg belief 2: Goals of DevOps and Security teams are dissimilar
When security teams find vulnerabilities, they need to convince a developer that it really is a vulnerability, that it needs to be fixed, and that it needs to be fixed now. This is then followed by the process of figuring out the best way to fix the vulnerability. The process seems tedious, and more often than not, it halts the speed-to-market strategy and hours of coding down the drain.
Many organizations envision DevSecOps as a solution to this problem: embed security experts and/or security expertise into the development teams so that vulnerabilities can be found and fixed. But the problem goes beyond that, especially when critical business functions are moved to the cloud.
By the time DevOps teams identify vulnerabilities at runtime, it would be too late to fix them, increasing the cyber risk. Security needs to evolve at the speed of the cloud, which is why software development and security need to be intrinsically linked. Yes, both DevOps and Security teams’ goals are the same: To minimize vulnerabilities but more importantly, minimize the effort to mitigate these vulnerabilities.
Iceberg belief 3: Developers don’t know anything about security
Vulnerabilities for the most part are resolved by developers, who implement code changes. Security teams find vulnerabilities, which developers eventually end up fixing. Developers view their job as writing and deploying code as quickly as possible.
Developers using Infrastructure as code provisions and governing the cloud infrastructure are the ones who fix vulnerabilities. Developers are how to fix security vulnerabilities without impacting their DevOps velocity. Changing the name from DevOps to DevSecOps, and assuming security is still its own functional area misses the point of integration, where both developers and security experts can learn from each other. When security experts partner with the rest of the organization, it should be from the beginning of the development process.
Considering the rapid advancements in technology like Infrastructure-as-Code (IaC), DevOps teams can now describe exactly what they need in code, which automatically provisions infrastructure to the given specification. Extending the “as code” approach to security will help organizations identify and fix vulnerabilities at the speed of development. Organizations in India need tools that can automate identifying vulnerabilities, which can be fixed instantly. Security no longer needs to interrupt development teams with findings of dubious value when it is embedded in the process of writing code itself. These tools, when effectively integrated into automated DevSecOps workflows, increase productivity and boost innovation but ultimately makes organizations cyber resilient.
The rapid deployment of cloud-native infrastructure, greater connectivity and faster production pressures can lead to increased risks. The collaboration between DevOps and security teams from the get-go allows organizations to achieve agility without jeopardising security, stability and governance. Melting these iceberg beliefs requires an organization-wide cultural shift and a new mindset in which cybersecurity sits at the core of the organization.