We’ve all been there … A new application or feature needs to be deployed yesterday and the last thing anyone wants to do is address security requirements. On the flip side, the very last thing anyone wants to address later is a security breach or a cost associated with non-compliance. Not only is it a massive headache but also it’s extremely expensive. According to the IBM X-Force Threat Intelligence Report 2016, the average cost of a data breach in 2015 was $154.20 per record ($363 per healthcare record) with the average total cost of a breach estimated at $3.79 million.
Not only is a breach expensive in terms of cost that can be easily quantified, but there are also costs that are harder to quantify such as the impact to branch image and customer loyalty. According to a new FireEye research report, 76 percent of respondents would likely take their business elsewhere due to negligent data-handling practices. In an incredibly competitive technology space, none of us can risk turning a blind eye to security if we want to attract customers with cool new features and then keep those customers with trust and reliability.
Security seems to be one of those topics that you either love or hate. I’m personally interested in it; however, I realize it’s not an interest shared by all. In the land of unicorns, we want all developers (infrastructure and application) to have more ownership in security, but tight schedules combined with the lack of expertise and reliable controls often can make that strategy unreliable. To make matters worse, a secure system and application isn’t something that is always glaringly visible to an end user or product owner. As a result, security may easily get deprioritized as something that “can be fixed later.” The “fix it later” strategy can be a dangerous decision, as many cybercriminals now are actively taking advantage of those that deploy quickly without adequate controls. How do you balance the customer’s desire to have new features delivered quickly with the fact that they need secure systems protecting their data against malicious threats?
Several common DevOps practices inherently lend themselves to providing a development and delivery pipeline that can improve your overall security posture. DevOps combined with SecOps includes practices that shift operational and management aspects of a system to the left to ensure we are able to reliably delivery and manage secure systems.
5 Security Practices Worth Considering
Below is a list of the top five DevOps practices and tooling that can help improve overall security when incorporated directly into your end-to-end continuous integration/continuous delivery (CI/CD) pipeline:
- Collaboration
- Security test automation
- Configuration and patch management
- Continuous monitoring
- Identity management
If you iteratively build in security practices as you move infrastructure and application code through the deployment pipeline, it greatly increases your security posture as well as decreases the cost of future rework.
Collaboration and Understanding your Security Requirements
Many of us are required to follow a security policy. It may be in the form of a corporate security policy, a customer security policy and/or a set of compliance standards (ex. SOX, HIPAA, etc). Even if you are not mandated to use a specific policy or regulating standard, we all still want to ensure we follow best practices in securing our systems and applications. The key is to identify your sources of information for security expertise, collaborate early and understand your security requirements early so they can be incorporated into the overall solution.
Security Test Automation
Whether you’re building a brand new solution or upgrading an existing solution, there likely are several security considerations to incorporate. Due to the nature of quick and iterative agile development, tackling all security at once in a “big bang” approach likely will result in project delays. To ensure the project keeps moving, a layered approach often can be helpful to ensure you are continuously building additional security layers into your pipeline as you progress from development to a live product. An example of building gates in as you progress through your pipeline is shown below. Security test automation can ensure you have quality gates throughout your deployment pipeline giving immediate feedback to stakeholders on security posture and allowing for quick remediation early in the pipeline.
Configuration Management
In traditional development, servers/instances are provisioned and developers are able to work on the systems. Sometimes there is a “golden image” developers use to provision that can ensure that the provisioned servers/instances have a hardened operating system. However, as soon as any additional development and configuration activities happen on those servers, that server is no longer golden. To ensure servers are provisioned and managed using consistent, repeatable and reliable patterns, it’s critical to ensure you have a strategy for configuration management. Your strategy may include Chef for one situation, Salt for another situation, immutable infrastructure, or a combination of practices. The key is ensuring you can reliably ensure and manage consistent settings across your environments.
Patch Management
Similar to the concerns with configuration management, you need to ensure you have a method to quickly and reliably patch your systems. Missing patches is a common cause of exploited vulnerabilities including malware attacks. Being able to quickly delivery a patch across a large number of systems can drastically reduce your overall security exposures.
Continuous Monitoring
Ensuring you have monitoring in place across all environments with transparent feedback can alert you quickly of potential breaches or security issues. It’s important to identify your monitoring needs across the infrastructure and application, and then take advantage of some of the tooling that exists to quickly identify, isolate, shut down and remediate potential issues before they happen or before they become exploited. Part of your monitoring strategy also should include the ability to automatically collect and analyze logs. The analysis of running logs can help identify exposures quickly. The collection and analysis of security logs can identify issues that require remediation as well as provide automatic collection of compliance evidence. Compliance activities can become extremely expensive if they are not automated early.
Identity Management
DevOps practices help allow us to collaborate early with security experts, increase the level of security tests and automation to enforce quality gates for security and provide better mechanisms for ongoing security management and compliance activities. While painful to some, it has to be important to all if we don’t want to make the headlines.
We are all busy keeping up on everything that is emerging in technology and it’s difficult to keep up on all of the latest issues, so relying on reputable tools and reliable sources of information can be extremely beneficial. Some of my favorite resources in this area are The OWASP and SC Magazine. IBM X-Force is another great reliable resource to check out for the latest threat research and services. There are also a slew of tools out there to help with different areas of security in each of the practices covered in this blog. I’d love to hear about some of your favorites at @Shelbee_SE.
About the Author / Shelbee Smith-Eigenbrode
Shelbee Smith-Eigenbrode is a senior software engineer/IT architect at IBM and has been in IT for 19 years. She has worked across varying roles spanning the software development life cycle. Her experience across functional roles as well as performing that work deeply inside traditional silos has contributed to her passion for embracing the DevOps culture and transforming the way teams are delivering technologies by adopting DevOps practices. She is a member of the IBM Academy of Technology committed to driving innovation and technical advancement.
