By Splunk September 15, 2017
As a Global DevOps Practitioner for Splunk, I get to talk with many different customers. Typically, our conversations focus on solving problems in their planning process, build systems, and release framework.
But lately, I been catching customers off guard by asking how they handle security in their SDLC process; and if they have good and open communication with their Security Operations team.
In most cases, the customer gives me the "deer in the headlights" look and asks how security can be implemented in the DevOps pipeline without a lot of human intervention. Here are the three major ways I recommend to customers secure their SDLC process.
Planning & Code Review:
This is the first major data source that most customers overlook, when it can actually reveal significant anomalies. Many customers are used to traditional ITIL processes, where changes are documented in a system of record, so all stakeholders can have visibility into new work. However, they often do not realize that DevOps teams can also use a system of record to document changes and tasks and provide visibility to all teams. By correlating a task, epic, or print ID to a repository commit or change request, security teams can see if new development work is part of a planned change, or if an unauthorized change is about to happen.
When developers are about to commit code to a master branch, and before it becomes a Pull Request the process of peer review is critical and can easily be documented in this same process. By correlating tickets with commits and then pairing that data with the build system you can get amazing visibility that benefits security team and protects the business as a whole.
Build Chain Automation:
Moving further through the pipeline, I recommend a second layer of defense to protect what gets deployed into production. Multi-stage builds plans allow development teams to not only benefit from better organization, but also to test each separate phase of the overall process. Basics like unit & functional test allow teams to get a handle on simple mistakes. Tools for automatic code scanning give more visibility to technical debt, line counts, and complexity. But what makes the difference is using tools that scan modules and test for vulnerabilities. These tools automatically check signatures and CVE mappings to determine whether code about to be released will be a higher risk to the company.
By correlating the data from these multiple tools, Security teams can document =Key Security Indicators (KSIs) so release teams can understand whether any given artifact is ready to be put into production. Correlating this data with data from the planning process and build system means security teams can spend more time on penetration tests and compliance, while also facilitating a frictionless DevOps culture.
Release and Monitoring:
The third – and hopefully last – main layer of defense is the automation of your environment. Taking the same concept of correlating data from your planning, SCM, build, and testing systems, you can also make sure your configuration catalogs are consistent. By using a data-driven approach to gain visibility into your environment, your release teams can have the confidence of pushing out new configurations and settings without having to worry about security, and without any unexpected surprises.
For example, automation frameworks like Puppet can not only help you manage your workloads, but can also provide a layer of compliance. When a configuration goes out of compliance, the Power of Splunk with Puppet Automation, for example, and leveraging the ability to generate KSI for your whole team, you can now give you the confidence to sleep at night. This allows your developers to focus on improving your product, rather than having to build layers and layers of protection that increase latency or degrade the customer experience.
Making DevSecOps Real:
In summary, when you take a look at your DevOps pipeline today, can you say you are taking the appropriate measure to protect your teams, and most importantly, your customers? If not, take the time to start pulling your data in Splunk and see what you can do to minimize your risk. Sometimes it just takes 15 minutes of white boarding and working with your Team to understand the pains. Let’s work together to change the world of traditional IT and drive the next generation of DevSecOps.
----------------------------------------------------
Thanks!
Domnick Eger