Shift Up: Continuous Security and Feedback Loop In Production

There's a big question in infosec 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 communication 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 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 the 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.