Get ITSM Up to Speed on Security for DevOps
Feb 12, 2020
Traditional ITSM processes, whilst designed for all the right reasons; to protect us, to improve our predictability and to enable common understanding, are frequently accused of being onerous and of blocking the flow of value from idea to realization to the customer.
In the past, when we have experienced an issue or problem, a typical response is to add a control; this is why large enterprises that have operated for a significant amount of time are often bogged down in bureaucracy - layers of process that have built up over time. Additionally, these types of organizations have evolved system and organizational designs (not necessarily by intention) that contain large numbers of (sometimes unknown) dependencies, exacerbating the sense, and actuality, of fragility.
DevOps seeks to improve sustainable working practices and reduce workplace burnout and stress. It remodels the ways of working to improve velocity, consistency, and predictability, visualizing the flow of work and removing constraints. Our focus moves from managing dependencies to breaking them to create loosely coupled organizational and technology systems that allow us to build, test and deploy in small increments.
The Relationship Between Security, DevOps, and ITSM
Security is of primary and crucial importance to enterprises and large organizations in particular. It affects the bottom line of every organization and plays a key part in retaining customers' trust. Unfortunately, security has been late to the DevOps party, or their invitation was sent late.
In many organizations, security represents a severe constraint, unsurprisingly since there are many reports of cybersecurity skills shortages, and often are significantly separate from the rest of the technology team. It’s not uncommon, when performing value stream mapping exercises, to find delays of several weeks while teams wait for penetration tests.
Is Security Just Another Test?
There are many who say that security is just another test and just another non-functional requirement, and whilst elements of this is true, it’s also true that the extreme separation of the security team and their often being seen as a ‘black-box’ means that incorporating them into the pipeline earlier (shifting left) is more difficult to do than with some other areas of testing. For example, it’s relatively easy for developers to start incorporating unit tests as part of their automated build process. Automated integration tests and user acceptance tests follow fast.
In the integrated development environment (IDE), the security tests are pushed as far left as technically possible into the developers’ hands. This provides developers with the knowledge they need about vulnerabilities in the components that they are accessing from their IDE in the artifact repository, handing them control over the software supply chain.
Penetration Tests in Production
Most organizations perform regular or sporadic penetration tests or vulnerability assessments in production and many are required by regulators to do so and audited to ensure they happen. They can be done either manually or using tools, typically a combination of the two, and produce a report that is then passed to developers who work the actions into their backlog. Or not.
Ultimately the security constraint is broken so there is no wait time for security activities to complete and the teams are confident that their product is as uncompromisable as possible. We break the security constraint through culture and the sharing of knowledge and from automating checks and remediation.
Shift-Left and Automation are Key
As described, in DevSecOps security testing happens much earlier than penetration testing in production (in many cases this may still need to happen, not just for auditing purposes but for configuration cases also). Where the teams are using artifacts, the repositories can be used to scan and flag for vulnerabilities at the point of software composition. The developer can be informed as they access a component of its vulnerability status and advised if another version fits the organization’s security policies better. If the teams don’t want developers interrupted in this way, non-compliant vulnerabilities can break the build in the CICD pipeline.
Static and Dynamic Application Security Testing (SAST and DAST) are also used to test the source code and the application when it’s running. IAST (Interactive Application Security Testing) analyzes code for security vulnerabilities while the application is running from inside the application and reports in real-time. As cloud and CICD proliferate machines, automated identity management tools are also recommended.
Do Developers Care About Security?
The relationship between development and security is fractious in many organizations, with security believing that developers don’t care about security and developers feeling that security is overly zealous, detailed and doesn't understand the myriad of pressures that they are under.
An effective pattern is to have security people work in a product team or feature squad on a temporary basis. Whilst there may not be a lot of security people to go around (some refer to the 100:10:1 ratio of developers:operations:security), the payoff is worth it as there are two key benefits; the first is the building of empathy and relationships and the second is knowledge transfer as the 80:20 rule applies here: 80% of the security issues relate to 20% of the knowledge. This 20% of knowledge is relatively easy for the engineers to access, retain and share in this scenario.
Developers do care about security, since they care deeply about their code, particularly when they are transitioned to a ‘you build it, you own it’ way of working. They also care about the customer experience and for the organization that they work for - few people are ignorant of the wide-ranging impact on company performance and reputation that a breach causes. However, they are focused on new features that deliver value first then the improvement of the way in which they deliver value. Although we aim for multi-functional, ‘comb’-shaped people, nobody can know everything. Expecting a developer to know of, understand, and remediate every possible vulnerability is unreasonable. To ask them to be aware of and follow visible coding policies and use tools that break the knowledge constraint is not unreasonable.
Customer Feedback and Bug Bounties
In DevOps ways of working the focus is on the customer and the flow of value to them (The First Way). The Second Way teaches us to shorten and amplify our feedback loops. Highly evolved and performant organizations seek feedback from customers and the market on security too; they understand that transparency leads to trust. Having a public bug bounty program is an effective way of collaborating with customers and the market to receive feedback and improve security posture.
Software is Like Milk, Not Wine
New vulnerabilities are found and appear constantly so software that passed its security tests today may not tomorrow. Tools are available that continuously assess the bill of materials in applications and offer teams fast remediation capabilities. We can look forward to a future where products are automatically updated with security vulnerability fixes.
However, data breaches aren’t the only way for threat actors to cause problems with the operation and safety of an organization’s products. They can do other things, like distributed denial of service (DDOS) attacks for example. In order to protect yourself from these sorts of attacks, you’ll need support from a cloud vendor or a specialist security vendor in this space.
Whilst shifting security left and continuously scanning products in production for vulnerable components goes an enormous distance in protection against breaches, it’s doubtful that human penetration testing or vulnerability assessments on products in production will be in the past any time soon. Not only do regulators continue to require evidence for these activities, but humans are also infinitely creative and will find configurations and routes into systems that may not directly relate to a specific vulnerable artifact.
You Can Have Speed AND Safety
The end goal of any enterprise is to deliver more value to the customer as quickly as possible. With so many alternatives and options out there in the post-digital transformation market, it’s more important than ever that your software is secure. Rather than bolting on security features at the last second, organizations should strive to integrate security-focused measures into all the phases of the software delivery lifecycle.
With this model, security becomes a team effort that involves active collaboration between QA, Development, and Operations. To this end, ITSM must consciously strive to overhaul its cumbersome processes.
Learn how service management can address these challenges by reading our free eBook: Service Management in a DevOps World
Download our free eBook
Mastering Software Delivery with Value Stream Management
Discover how to optimize your software delivery with our comprehensive eBook on Value Stream Management (VSM). Learn how top organizations streamline pipelines, enhance quality, and accelerate delivery.