Shift Up - Continuous Security & Feedback Loop In Production

There’s a big question in infosec. That question is “how do we know that we have the right security solutions in place?” And sure, that’s a great question. But there are others to address as well. Here are some additional challenges for us to solve.

The problems

First, security tooling is biased toward non-production. Too much testing is done there. The tools used in production need to have as much focus as those in non-prod. By analyzing in production, we’re actually addressing security risks where they are most likely to be exploited.

Secondly, the environmental differences happen the other way too. There isn’t a feedback loop from production back to non-production. This can be attributed to a basic lack of communications between segments in the organization.

Furthermore, there seems to be a layered patchwork of defenses. A more consistent network of defenses will be stronger since it can self-heal. The parts can learn and improve together using the network effect.

Worse still, third party and open source libraries can contain vulnerabilities. There isn’t a way to sandbox some of these issues. Small breaches can become extremely costly.

Solving the problems

How do we solve for these problems? The first step is to be proactive. Take inventory of what’s in the environment.

A second step is to do vulnerability scanning. This type of testing needs to happen continuously. As the systems change, new vulnerabilities can be introduced. When DevOps is releasing hourly, this means new vulnerabilities can release every hour right along with those new features.

The third recommendation Deshmukh has for us is chaos engineering. Introduce problems in order to shake out vulnerabilities. This is kind of like a stress test to see how your security system responds. But don’t mistake this for chaos-driven development, which is slang for not having a sound process in place.

And finally, don’t forget your inventories and portfolios! You need some way to keep track of what you own. An aging app sitting out there somewhere can get lost. These are vectors for breaches!

Remember: there are no silver bullets. For example, when it comes to components, we can focus on data. When it comes to chaos engineering, it’s important to understand if data can be changed in a way that brings down the system. Don’t do this in production, though. Think of things like force encrypting records database. (Author note: This is basically what they did on the popular USA Network series Mr. Robot when they took down the world’s largest corporation.)

If a tool isn’t cutting the mustard when it comes to open-source, you need to either find an alternative or weigh the risk against the value.

When it comes to setting optimal parameters for your tools, the environment matters. If it’s a healthcare environment, it’ll have different needs than a web app environment will. The security parameters need to be optimized per your needs. Change management for settings and inventories (AKA configuration management) isn’t the only issue in this area. The tools need to be smarter about detecting issues with misconfiguration.

Taking an overall proactive approach, measuring, and continuously improving are the keys to a successful upward shift in your security.

***

Missed Swapnil Deshmukh’s session, or want to see some other great presentations from October 17? Head over to https://www.alldaydevops.com/live and make sure you’re registered. Then, catch up on what you missed (or re-watch your favorites)!

About the author, Phil Vuollet

Phil Vuollet uses software to automate process to improve efficiency and repeatability. He writes about topics relevant to technology and business, occasionally gives talks on the same topics. You can find him blogging at thedailylessonlearned.com.