In the big iron part of the IT world, and the big datacenter parts of the IT world, we’ve always had automation engineers. This isn’t a new thing. Over a decade and a half ago Loudcloud was spinning out what would become Opsware, and later HP Server Automatio and an entire host of enterprise automation frameworks. And that’s just one of hundreds of examples of large scale automation engineering that has occurred regularly across the expanse of the IT landscape.
The thing about automation is, until very recently it was the domain of a select few. This was by necessity. There just weren’t that many people who had to deal with over a thousand systems by themselves.
Thanks to virtualization, and IaaS that’s changed. And now we’re seeing lots of, frankly, small companies spinning up thousands of instances. This gave rise to the DevOps terminology. Basically a bunch of kids who had never had to deal with automation engineering ended up creating their own design culture around the very same concepts that had plagued enterprise and government IT for decades. This was awesome. Because these guys didn’t have any knowledge of traditional engineering in this area, they innovated in ways no practiced automation engineers could have expected. They had no preconceptions, and so they so the problems of automation in a new light. And that brought new ideas into the world. Chef, puppet, salt stack… these are just a few of those ideas. Not nearly as robust as their precursors in many cases, but still a paradigm shift in procedural language and methods.
Now in 2013, the landscape of IT has changed. Even in NYC, among the halls and cubes of the most conservative IT has to offfer, automation engineering and devops are fusing into the common toolkits of modern data center operations and the automation engineers are moving out of centralized global technology teams into embedded positions among various other working groups as well. IT has finally learned to code. And now, the race is on. We are automating all the things. I think Jeff Lindsay expresses this new rennasaince in ways I simply cannot improve upon.
Now it’s time for infosec to learn to code. ( Pause here wait for laughter to die down ). The other day, someone at Appsecusa made this comment:
— rshullic (@rshullic) November 20, 2013
I responded with:
— M̃͒ͪͫ̓ɐʇʇ J̥͕͚̯̟oʎɔǝ (@openfly) November 20, 2013
And that’s pretty huge. Information Security has an idea of coding discipline that’s so far removed from actual real world software engineering practice as to be laughable. This comes from a fundamentally narrow almost tunnel vision focus on their own policy requirements, and very celebrated paranoia. Both of which are things that are a necessity in being a solid infosec professional. The trouble is, while automation is breaking down barriers between development and operations, it’s not really breaching the divide that infosec has silo’ed itself behind.
The need for embedded security engineers in development and automation teams now is greater than ever. And when I say security engineers, I mean infosec professionals that are ready to plug into the software engineering workflows and start being a part of the development process as full citizens. That means, first learning to code if they don’t know how already ( sounds ridiculous, but there are a lot of infosec professionals who just cannot code ), but it also means learning to operate in a team, using the workflows that software engineers rely on to do their job. That means, git repos, gate environments, writing unit tests for all the things ( including THEIR things ), that means taking their automated reporting scripts and frameworks and plugging them into unified gate testing environments like jenkins. That means working with automation engineering teams to ensure their tests are pluggable, and won’t hurt the testing environments. That means putting embeds into teams that are developing new functionality to help them meet their infosec goals as well as their development and automation goals.
It means, that security engineering is now going to join the development team along with automation engineering, and network engineering.
It means we’re no longer a triangle. It means we’re all inside the same circle. Sure up above there will be different LOB mandates and leadership. But on the ground we’re all going to be fighting in the same trenches. Or knitting in the same circle ( i mean hell why make this a war anology when we can go full on hardcore knitting anologies ).
When Security Engineering begins to plug into automation engineering it goes beyond writing gate tests. It means security can begin to write orchestration for environments. They can begin to trigger responses to detected or learned anomolies. Nodes with vulnerable or out of compliance services can be automatically give a little more network scrutiny… maybe by forcing their outbound routes through a more verbose IDS. Maybe you see an unregistered port pop open on a machine and you automatically move that instance or machine into an isolated DMZ and start logging all the things. The sky’s the limit, and bob’s your uncle worth two in the bush.
I want to go deeper into integrity validation on environments. On orchestrating smart responses to anomoly detection. BETTER anomoly detection. But frankly infosec is too busy running their risk management like it’s 2003.
Now you can respond to this in any way you see fit. But I will be very blunt. No one in development, or automation gives a shit what you have to say if you can’t back it with git commits for us to review. Code talks. Everything else is just bike shedding.
So stop fucking bike shedding security and start building it into the environments you are responsible for yah jackasses.