Guest post by UpGuard engineer Nickolas Littau While running a series of unit tests that make API calls to Amazon Web Services (AWS), I noticed something strange: tests were failing unpredictably. Sometimes all the tests would pass, then on the next run, a few would fail, and the time after that, a different set would fail. The errors I was getting didn’t seem to make any sense:
I recently attended the 2013 PuppetConf in San Francisco and spent most of the Thursday in what we affectionally call the "neckbeard" session. It was the "Product and Technologies" stream and seemed to be highly tailored to the relative minority of developers at the conference, or at least the people in charge of developing and maintaining the low level detail contained in Puppet manifests. Those at one with the Puppet DSL. As a developer this seemed like the only stream I would be interested in, seeing as four of the other sessions had sysadmin written all over them and the last one seemed to be targeted at use cases for sales people. In fact, one of the other devs here at UpGuard asked us at the end of the first day if we'd been called sysadmins all day. Thankfully, I hadn't. It is also a common generalisation that Puppet is designed for sysadmins, having a model based way of defining infrastructure, as opposed to code based approaches employed by products like Chef. I went into the start of Thursday's talks with this generalization clouding my judgement.
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.