By Michael Vizard
The best cybersecurity defense is always applied in layers. If one line of defense fails, the next should be able to thwart an attack and so on.
That same, tried and true, security in depth concept applies to DevOps as responsibility for cybersecurity increasingly moving left toward developers. In an ideal world, developers would be given tools that allow them to not only implement cybersecurity controls as part of the application development process, but also discover security gaps as they write code. The best remediation effort in the world is the one that’s never required.
However, as long as humans write code, mistakes will be made. The next layer of DevSecOps should be applied during the build process. As organizations employ a continuous integration/continuous delivery (CI/CD) platform to accelerate the rate at which applications are being built and updated, an opportunity arises to inspect that code. Every CI/CD platform provider now makes tools available to enable DevOps teams to apply and enforce cybersecurity controls and policies.
The final layer of DevOps defense needs to be applied as the application is deployed. Each platform has unique infrastructure and runtime attributes. Oftentimes, the devil in the cybersecurity details is about how application workloads uniquely interact with each platform. Cybercriminals have become especially adept at scanning for these types of attack vectors in a production environment. Fortunately, platforms expose application programming interfaces (APIs) that make it possible to continuously model threats to an application before and after its deployment. It’s critical to remember that platforms such as Amazon Web Services (AWS) regularly add new features and capabilities that developers invoke over the life cycle of an application. Each extension to that application creates another opportunity for cybersecurity mischief.
In fact, most vulnerabilities in a cloud computing environment are introduced when developers employ tools to automate the platform configuration process. A recent report published by Unit 42, an arm of Palo Alto Networks, found more than 199,000 templates that had medium-to-high vulnerabilities in use on public clouds. A separate report published by Accurics, a provider of security tools for scanning cloud infrastructure configurations, found only 4% of cloud vulnerabilities on average are being addressed. As DevOps teams embrace automation tools such as Terraform, the more likely that mistakes will be made – the Accurics report noted 24% of configuration changes in the cloud are now being made via tools that manage infrastructure as code.
This cloud misconfiguration issue is what’s spurring much of the rising interest in DevSecOps. A recent survey of 600 senior IT leaders conducted by Enterprise Strategy Group (ESG) found 90% of respondents are concerned about not having visibility into misconfigured cloud services, server workloads, network security or privileged accounts. Plus, 43% said their biggest challenge with cloud-native applications is maintaining consistency across disparate infrastructures. Not surprisingly, the same number of respondents said DevSecOps automation was their highest cloud security priority.
DevSecOps, of course, is still in its infancy. The good news is security has never been more top of mind. A survey of 3,650 software professionals published just this week by GitLab, a provider of a CI/CD platform, found more than 25% of developers reported feeling solely responsible for security, while 33% of security team members said they own security. Another 29% said they believe everyone should be responsible for security.
While the cybersecurity spirit may be more willing than ever, developers don’t know where to focus their cybersecurity efforts, according to Brendan O’Leary, senior developer evangelist for GitLab.
Cybersecurity teams are highly adept at discovering vulnerabilities. However, they tend to simply throw the list of vulnerabilities “over the wall” to developers, who will need to set priorities based on the severity of the vulnerabilities and other known bugs, and new features that need to be developed. Application development teams can’t scale infinitely to address cybersecurity issues; developers need some way to triage cybersecurity vulnerabilities in a way that allows them to prioritize their efforts within the context of a larger DevOps process.
“There needs to be more integration between security teams and DevOps for organizations to be successful,” O’Leary said.
That doesn’t mean cybersecurity teams need to learn how to code or participate in every scrum session. Rather, it means cybersecurity teams need to provide more context.
Regardless of how best DevSecOps practices are achieved, the priority now should be to get the necessary tools into the hands of developers. No one wants to deploy an insecure application deliberately. DevOps teams need a way to deploy secure applications without slowing the application development and deployment process to crawl as they strive to balance risk versus reward. Unfortunately, far too many DevOps teams simply are not quite sure what the level of risk really is.
ThreatModeler Joins Forces With AWS for a Unique Cybersecurity Offering
ThreatModeler announces AWS Security EPICS Automated, a new offering developed alongside Amazon Web Services (AWS) Professional Services (ProServe) Security and Infrastructure Global (S&I) Specialty Practice (GSP). The offering places automation front and center, accelerating the design of secure AWS cloud environments. AWS consumers can now ensure their cloud infrastructure is secure using guidance from AWS Security Epics to build a threat modeling process that drives security throughout the Cloud Development Life Cycle (CDLC).
Visit the ThreatModeler AWS Security Epics Automated web page for more information.
To learn more about how ThreatModeler™ can help your organization build a scalable threat modeling process, book a demo to speak to a ThreatModeler expert today.