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.” But, 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 that, “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 - that is, 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 peer’s perspective: 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, 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 year, 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
• Only scope is “Don’t take down production”
• Need to 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 here.

This blog series is reviewing sessions from the All Day DevOps conference from November which hosted over 13,500 registered attendees. Last week I discussed, “System Hardening with Ansible”. Next week, look for my review of an awesome session by Erlend Oftedal:  “There is No Server: Immutable Infrastructure and Serverless Architecture.”

IMPORTANT NOTICE: If you want to learn what others are doing in DevSecOps, take 5 minutes to complete our DevSecOps Community survey before February 28th.  Over 2,200 people have participated and we'll share the survey results with everyone.