In many organizations where cloud native architectures and containers have been successfully adopted as part of a DevOps initiative, the business has quickly realized that the tables have turned and the role of IT has changed from being a business support function, into a business enabler. Yet organizational culture still lacks behind when it comes to security, slowing down the technology adoption.
DevOps introduces a new way of developing and releasing applications into a production environment. With a DevOps mentality, product managers are looking for ‘minimum viable’ products with quick release times, with the aim of adding new features iteratively throughout the lifetime of the product. This can take the release frequency from a couple of times per year, to multiple releases per day in some cases. Using containers to support this DevOps pipeline provide both flexibility and reliability when moving applications between on premise, hybrid, and public cloud environments.
By embracing a DevOps approach, small teams are created combining just the right number of resources to support the task at hand, including people from development, operations, and, in an ideal world, security. There is often limited upfront planning, with development teams taking an experimental approach, and being encouraged to admit failure, but learn from mistakes, in order to get a high quality product out of the door as quickly as possible and maintain or create a competitive advantage.
As security professionals, we’re used to providing tried and tested security controls that are supported by or integrated into an industry-recognized security framework (for example ISO 2700x or PCI-DSS). But in a DevOps environment, static security controls won’t necessarily scale to the speed of application development and new feature releases. Especially when looking at application development with containers, there are a number of container-specific threats to consider in a security model – for example platform vulnerabilities, excessive user rights, and misconfigurations.
Businesses start to have concerns around the lack of time to review ‘security’ (whether it be code quality or threat modeling) in advance, and receive pushback from development teams when they suggest engaging with a penetration testing team, or carrying out a controls-based security audit due to the time assessments typically take. Businesses also run into challenges around risk acceptance – if there is no upfront design with a container or cloud-native application architecture, how can the business understand and subsequently accept the risk that the development team may or may not have introduced?
At the same time, the development and operations teams are not used to having to make security decisions – in the past the security team has taken responsibility for that – so without a security first approach as part of the DevOps adoption, the chance for security to be forgotten about, or put to one side to deal with later, increases, and businesses end up introducing unknown risk into their environment.
HPE Pointnext Services believes in following a ‘security first’ approach to cloud native application development, and advises customers on adopting DevSecOps, rather than DevOps. With this vision, and a security focused development and operations environment, businesses can deliver upon three business level security principles:
- Better control by providing an environment that offers ‘security by design’, and integrated security controls in the CI/CD workflow that make keeping applications secure easy and automated
- Better resiliency by ensuring scalability, availability, and business continuity levels that can cope with unpredictable business demands
- Better assurance by providing end-to-end security covering business, functional, and technical requirements. Specifically from a DevSecOps perspective, this includes not only delivering the right security controls, but also supporting a culture shift with a focus on education
We have identified five principles that an aspiring DevSecOps organization can follow in order to make sure that security is well represented at every stage of the product development lifecycle.
Ongoing cultural shift
The cultural shift that is required in order to adopt security into a DevOps workflow is perhaps the hardest to address as it can’t be solved simply by installing a new technology or configuring software in a certain way. Every organization today has to become a software company in one way or another in order to remain competitive, or to create a competitive advantage over their closest rivals.
In order to fit security into this new software defined world of business, it’s important to have support driven from the executive level. Unfortunately, the business, faced with time to market pressure, will quickly overlook security in a misguided attempt to save time. Traditionally security has been seen as a cost center – the inconvenience of paying for an insurance policy – and very difficult to justify the return on investment. If the executive level isn’t buying into this new ‘security first’ approach, it is likely to fail, as such a cultural shift requires top down support as well as bottom up enablement. To help support this, management needs to put a structure into place, and make people responsible for creating and managing the security program.
Developers take pride in their work, and want to ship the highest quality product to market. From a security perspective the challenge is often one of awareness – the average developer has not been trained on secure coding best practices, and is often blissfully unaware of the steps that can be taken to improve upon the number of security defects. It’s a good idea to set up a secure coding education program internally to help enable developers to play their role in DevSecOps. Part of the education program can also include identifying ‘champions’ to further the message within the developer community, as well as provide an interface to the executive team to report upon progress and metrics.
Security design in DevOps
As we’ve mentioned already, the lack of upfront design can cause concern for security teams, as it becomes difficult to perform efficient threat modeling. We’ve also mentioned the existence of small development teams made up of key players in the development life cycle to address particular modules of product development.
By integrating security representatives into the development teams, either as dedicated or roving resources, it will be possible to create visibility into the lifecycle of the product, as well as identify potential security risks early on. Having a security specialist involved in the product development process from day one will provide the opportunity to deliver ongoing threat modeling, identifying and mitigating potential risk factors at the design stage. It will also offer greater visibility into the software supply chain, which is critical in a container-led development model to avoid inheriting vulnerabilities and misconfigurations.
Shift left
Testing following the waterfall model of software development has traditionally been positioned as a ‘last mile’ activity – something that takes place after the software has been coded, and before it is passed over to operations. This approach has two major drawbacks – firstly, testing teams become a bottleneck in development processes, potentially holding up release dates if they find problems, and secondly, the team is not utilized in the best possible way and can be left sitting on the bench in between software release cycles.
The notion of ‘shifting left’ means moving the testing cycle earlier in the software development lifecycle. For example, having the software testers involved in product development discussions to understand how customers are likely to use the product (and therefore develop testing schemes based upon this, or maybe even influence design changes). Or providing testing during coding, working closer with the developers, so that problems can be identified even before the software code gets into an official build.
Following shift left makes a lot of sense from a DevOps perspective, as DevOps is all about making small, iterative changes to a product, making release day a thing of the past as releases are scheduled multiple times per day/month. It makes even more sense when put into a security perspective, as it provides another proof point of the value of embedding security into the DevOps team, and using the expertise and knowledge to identify potential security issues early on. This will also have an impact on overall development costs, as it has been demonstrated that fixing a security issue when writing code in the IDE costs 30 times less, compared to detecting and fixing a vulnerability in committed code[1].
Secure by default
Most developers are not security experts, and whilst the integration of security personnel into the DevOps team can fill the knowledge gap, addressing the problem head-on can provide a number of benefits.
‘Secure by default’ is about offering developers and operations staff a secure set of tooling to use when building applications and operational processes. This will help to build up security as a self-service function. There are a number of ways to help support this:
- Developer education – introduce trainings in secure coding techniques and security awareness to the product teams to help instill a security-based culture
- Software repositories and registries – by centrally managing the software libraries and services that developers can use in their projects, the number of potential vulnerabilities introduced into the software supply chain can be reduced. An example of this is the Docker Secure Registry – by using a private registry, the security team can control the lifecycle of the libraries, services, and containers, replacing images as vulnerabilities are patched, and decommissioning vulnerable images as appropriate
- Infrastructure as code and Compliance as code – Infrastructure as code offers template based provisioning, allowing organizations to deliver infrastructure instances following a script. The script can contain steps to preconfigure instances to follow the appropriate security policy, meaning that all instances going into production follow the same security baseline. Compliance as code then provides regular scanning and remediation to ensure that the configuration doesn’t change from the baseline, and that newly discovered vulnerabilities are quickly remediated.
Continuous delivery
By integrating security into a continuous delivery model, the organization can move from risk to benefit. The addition of security checks and controls into the delivery pipeline will provide greater compliance, and the ability to deliver higher quality, more frequent, software releases – perhaps the ultimate aim of a Dev(Sec)Ops culture.
HPE Pointnext Services offers consultancy, education, and implementation services to ensure customers are able to benefit from adopting DevSecOps, cloud native architectures, and containers in a secure manner. For more information, click on the links below, or reach out to your HPE account manager.
Featured articles
- DevSecOps and containers: How a cloud-native model places new demands on organizational security via HPE's Enterprise.nxt
- How to build a container strategy via HPE's Enterprise.nxt
- Want to know the future of technology? Sign up for weekly insights and resources
Find out more about HPE Pointnext Services and our Security and Risk Management practice
Read a related blog around Digital Transformation and DevOps
This week HPE launched the HPE Container Platform. With this Kubernetes-based software solution, customers can bring the agility and efficiency benefits of containers to a wide range of enterprise applications – running on bare-metal or virtualized infrastructure, on any public cloud, and at the edge.
Learn more about the HPE Container Platform
Watch the HPE Container Platform demo video
[1] https://resources.sei.cmu.edu/asset_files/WhitePaper/2013_019_001_295670.pdf
SimonLeech
Simon is Deputy Director in the HPE Global Security Center of Excellence. He is responsible for bringing together cyber experts from across HPE to support the vision of an open and secure edge to cloud platform, and works with HPE's enterprise customers worldwide, evangelising the strategy of HPE Global Security and articulating our ‘Secure by Design’ and ‘Operationally Secure’ principles. Simon has worked in the IT security industry for over 25 years and is well versed in many areas of IT security, including network security, operational security, malware, cyber threats, vulnerability management, hybrid cloud security, container security, zero trust security, and cyber resilience. Simon is active on Twitter as @DigitalHeMan
