As the brainchild of the development and operations departments of your business, DevOps is the unicorn of your domain. Why? Like the horned mythical creature, the right implementation is elusive, and it can skewer you(r security record) if not handled correctly. But when well-implemented and maintained, DevOps can bring your company value far beyond a siloed approach to either department.
The truth is, proper DevOps takes security strategy from the start. It’s operations and development playing off each other’s strengths and responding to security threats in real time. Instead of simply blocking potential threats, proper DevOps gets to the root of each issue by involving security and (re)developing structural code in immediate response to attacks; a symphony of equestrian movement that leaves a glitter trail.
What could possibly go wrong? :) Let’s get right down to some real stories from the desk of DevOps pro — James Wickett to illustrate some of these unfortunate unicorn skewerings.
Problem: Security doesn’t like to share!
Sometimes people in the development or operations side don’t feel the need to continuously share crucial details with the other half of the unicorn. Perhaps the DevOps “team” is built in such a way that neither side has the agency to do their job well as development, operations, or security members. So this magical creature ends up just a sad horse with a horn hat.
“One of the issues I have faced is how to blend DevOps with security. Two of the key tenets of DevOps (see CAMS) are Measurement and Sharing. In DevOps environments I have personally seen the benefit of adding visibility into disparate data sources like GitHub commits, CI build events, and something like the connection pool in the database cluster.
But when DevOps adds security to the mix, there is a lot to gain in terms of raw operability, and it lets everyone move faster with more confidence. Sadly, security data rarely if ever provides this level of visibility; usually I’ve seen tools problems, where visibility isn’t available, or people problems, where people are just unable or unwilling to share — often in the name of compliance or separation of duties or concerns.”
Solution: Get over it and share metrics in real time
“Bridging security into DevOps changes both sides of this equation. People should be encouraged to collaborate, and one of the best things that security can do is add measurement through meaningful metrics. Are we getting attacked currently? What’s the current landscape of attacks that are happening? Without security in the mix, most DevOps groups are operating in the dark — they have no idea how to answer these questions.”
Problem: Inequitable staffing and cultural misunderstanding
Continuous, small-batch information sharing (and swift action) are the best ammo for response to ongoing issues. But the lack of control or respect afforded to their side of the unicorn’s big, bulky body can cause frustration to team members. Ideally, developers should have the agency to deploy as needed, ops people should be able to function as ops, but security mustn’t be underfunded and understaffed. RESPECT each other’s magic, people!
“I’ve heard security people say things such as, ‘Those stupid developers!,’ or devs say things like, ‘security just prefers a system turned off and unplugged.’ No. We should not be saying demeaning things to each other, and the ratio of dev to ops to sec should not be 100:10:1.”
Solution: Decide if Security is a core value
“Look at NetFlix and ask yourself again whether resiliency and security isn’t just as valuable as speed and flexibility.”
Problem: We choose compliance over engineering
Sometimes we become more concerned about satisfying compliance rather than building Rugged Software. There is a temptation to spend on audits or vulnerability scanning rather than investing in a dedicated security solution. We blame the very idea of DevOps when we realize we have neutered security and chosen a thin string of glitter and glue in its place.
“There are ways to integrate security from the beginning, but some take the easy way out. For example, people may think WAFs suck, so devs may put in place the most minimal implementation as possible in order to gain compliance.”
Solution: Go back to CAMS
Remember the DevOps tenets: Culture Automation Measurement Sharing. Being merely compliance-driven is just building a facade.
“What buyers and management really need is to put solutions in place to help clue people into threats in as close to real time as possible. I liken this to Application Security Telemetry. I believe the NextGen Web Application Firewall will be more about telemetry and sharing that data with the teams responsible for building the web applications and APIs.”
Its tempting to pursue compliance as just another feature. Check some boxes and you are done. However, once development, operations, and security all add value to the organization it turns into a completely different situation. Instead of being compliance driven, you shift to actually defending your organization. Do that.
Signal Sciences’ industry first Next Generation Web Application Firewall was built in response to our frustrations of trying to use legacy WAFs while enabling business initiatives like DevOps and cloud adoption. The Signal Sciences NGWAF works seamlessly across cloud, physical, and containerized infrastructure, providing security prioritization based on where your applications are targeted, and blocking attacks without breaking production traffic.