From a Commodore 64 to DevSecOps

We all know the story: a farm, a kid, a Commodore 64, and a modem maxing out at 300 bps. A few unexpected phone bills later, and young Ian Allison is figuring out how to game the system so he can keep using his newfound gateway to the world of tech. According to Ian, that is where he began building the foundation of skills for his career in computer security.

At the recent All Day DevOps conference, Ian (@iallison), now with Intuit, talked about his history of being “that” security guy. You know, the one who thinks developers don’t care about security or deadlines, and, really, are just plain “stupid.” Don’t worry — he is enlightened now and realizes that we all have the same goal: everyone wants to build a secure system.

Ian realized:

“Security doesn’t understand how developers or operations works. Security solves for security, but that leaves everyone else in their own place.”

He started his enlightenment when his career path led him to a place called DevSecOps — DevOps where security plays a more integral role.

Ian pointed out that traditional InfoSec relies on compliance, regulations, appliances, and perimeter (CRAP). He then realized the selfishness of his own and his peers’ perspectives: remediation was left up to the developers, the feedback they get are 200-page scanner reports, and it only solves problems for security and compliance. It doesn’t help developers reach their shared goal of a secure system.

DevOps creates an opportunity for security to get a better view into our infrastructure, operations, and development efforts. DevOps is not only fast, lean, and efficient, but when done right, it is collaborative and empathetic. Couple speed with collaboration and empathy and DevSecOps can blossom.

Here is the reality that Ian was facing: Scanners find the absolute bare minimum, bad default configs are a huge problem even with SaaS vendors, manual testing can uncover defects that have been hiding for years, and the attackers are more skilled and motivated.

How do you implement it and make it better?

• Allow Dev teams to assume the risk of their decisions.
• No more security exceptions or sign-offs.
• Security is everyone’s responsibility.
• Test the crap out of your own stuff like an attacker would.

At Intuit, Ian wanted to help build stronger bridges between development, operations, and security teams. To do this, he set up a Red Team to:

• Use same tactics as attackers.
• Have only one scope: don’t take down production.
• Adapt and evolve like an attacker.
• Prove risks actually exists.
• Should be writing their own exploits.
• Should have ongoing campaigns that mimic attackers.

The Red Team started small, lean, and focused on the cloud. They worked like an Agile DevOps team, working manually with the use of some tools. In the end, they found, reported, and fixed thousands of vulnerabilities not found by scanners.

Ian goes into more details and lessons learned in his full All Day DevOps conference session (just 30 minutes). The other 56 presentations from the All Day DevOps Conference are also available online, free-of-charge.