When we think about cyber attacks, we usually think about the malicious actors behind the attacks, the people who profit or gain from exploiting digital vulnerabilities and trafficking sensitive data. In doing so, we can make the mistake of ascribing the same humanity to their methods, thinking of people sitting in front of laptops, typing code into a terminal window. But the reality is both more banal and more dangerous: just like businesses, governments, and other organizations have begun to index data and automate processes, the means of finding and exploiting internet-connected systems are largely performed by computers. There’s no security in obscurity if there’s no obscurity.
One of the challenges of building and running information technology systems is solving novel problems. That's where frameworks like scrum and agile come in– getting from the unknown to the known with a minimum of frustration and waste. Another challenge is performing known tasks correctly every single time. Here runbooks, checklists, and documentation are your friend. And yet, despite a crowded market for IT process automation offerings, misconfigurations and missed patches are still a problem– and not just a problem, but the root cause of 75-99% of outages of breaches depending on platform. Executable Documentation
So a cat walks into a bar. No, that’s not right. He walks into a box. The cat gets bombarded with radiation. It used to be a bar but a lot of people died from the radiation so they turned it into a box. Is the cat dead or alive?
Going from nothing to automation using one of the many tools available can be a daunting task. How can you automate systems when you’re not even 100% sure how they’ve been configured? The documentation is months out of date and the last guy to configure anything on that box has since left the company to ply his trade somewhere that will more fully appreciate his Ops cowboy routine.
It's been really interesting to watch the dramatic uptick in activity around the automation space the last year or two. I don't need to go into too much detail on the benefits that automation offers here; consistency and scalability are two of the more prominent that come to mind. What has struck me, though, is that it feels like the way that companies are going about it is missing a key step.
Configuration testing should not only be an essential step in the overall development process, but also important in the process of installation of new apps for use on web and application servers. Without proper testing, apps can often fail or be open to vulnerabilities. Exposure to attack by hackers or viruses can lead to needless expenses and excessive time correcting these problems. It is not unusual for app developers to overlook the need for configuration testing. This is because they believe that using automated methods, like Chef and Puppet (or other systems that test the deployment of their products), will work just fine. They feel that by using these fully automated processes they can test consistency, reproduce outputs adequately, and determine if things are working as predicted or not. This kind of thinking can delay a timely product delivery, produce unnecessary costs, and create additional workloads to address vulnerabilities that can occur later in production.
Upon the application of Chef/Puppet with a view towards the automation of system architecture, it is possible to apportion the systems environment piece by piece and start up applications in a heartbeat. This is ideally the configuration management pinnacle of achievement, encompassing a time saving mechanism, highly replicable, and with unrivaled ability to replicate.
Why IT Automation Needs Configuration Testing
The Sinkhole That is Manual Configuration Testing Testing is a crucial part of software development: it involves the execution of a program with the goal of locating errors. Successful tests are able to uncover new errors that can then be corrected before the software is released.
Cyber resilience is a fundamental change in understanding and accepting the true relationship between technology and risk. IT risk (or cyber risk, if you prefer) is actually business risk, and always has been. And the cybersecurity industry, for what it's worth, has generally avoided this concept because it goes against the narrative that their respective offerings—whether it's a firewall, IDS, monitoring tool, or otherwise—would be the one-size-fits-all silver bullet that can keep businesses safe. But reality tells a different story.