Information Security (InfoSec) is in trouble across all organizations, but even more so in DevOps orgs. In this video, learn why security is in crisis.
- [Instructor] To say that security has had a rocky relationship with developers, operations and really anyone else is an understatement. To me, security's in crisis. I say this because security has lost its identity and often doesn't seem relevant to the day-to-day business of an organization. However, like many crisis situations, this can get better but before we dive into the remedy, DevSecOps, let's explore why security is at an inflection point in many organizations.
There are three major issues at play here. The first issue is the 100:10:1 problem. This represents the inequitable distribution of labor that has permeated IT for decades. For every 100 developers in an organization, there are roughly 10 operations staff and usually just one security person. Some organizations have a different ratio but you'll find this generally holds true. This means that the crisis has precipitated by an orders of magnitude staffing problem.
Operations developers attempted to solve their part of this problem back in 2009 when DevOps was originally coined and the movement was realized but now it's security's turn. Okay, the second issue is that security people are often seen as outsiders and not part of the teams delivering value. This is in part due to the 100:10:1 problem but it's also due to different priorities. Security follows more closely to PCI standards or security governance councils like ISC Squared CSSIP guidance rather than participate in their own company's goals.
If this sounds familiar to you, I'd recommend checking out the book The Phoenix Project. The story follows a fictional company undergoing a DevOps transformation. In it, one of the main characters is the head of IT security. The story echoes the modern stereotype of security. Security isn't part of the team or the business and security just sort of does their own thing. The final issue is security's roots. It was born out of the Waterfall methodology for software development.
Waterfall treats a project as a month's long series of linear tasks and security performs their tasks only at the very end. And of course, they always find issues which leads to a tense and really expensive situation where the delivery date has to get pushed to fix security bugs. To sum it all up, Steve Bellovin has a great quote in his book Thinking Security. Companies are spending a great deal on security but we read of massive computer-related attacks. Clearly something is wrong.
The root of the problem is twofold: we're protecting the wrong things and we're hurting productivity in the process. This was written for security by one of our own and the problem is is that he's right. So, what do we do? Well, there's a better way and it's been rapidly adopted by companies of all sizes. This approach is called DevSecOps.
- Goals for a DevSecOps toolchain approach
- Development, inherit, build, deploy, and operation tools
- Keeping secrets with git-secrets
- Using OWASP Dependency Check
- Testing for dependency issues using Retire.js
- Options for software composition analysis
- Key security concerns for the deploy phase
- Tricks for making compliance happy
- Cloud configuration monitoring