Leaning Into Chaos the Journey to DevSecOps

Information Security is not usually the team leading the innovation curve or even supporting it. Yet with data breaches increasing and rapid changes in technology, it’s time to re-think that approach.

Generally security controls are added post-production — picture castle walls built around treasure with moats, large iron doors, and tall towers. InfoSec and IT Risk are relatively new fields, but this has been the strategy from the beginning. Legend credits the start of computer security to an incident about 30 years ago triggered by Cornell University graduate Robert Morris. He activated the first computer worm, the Morris Worm, using an MIT computer in an effort to move suspicion away from Cornell. The year was 1988, and the worm took down much of the internet at the time. Although Morris claimed it was an intellectual exercise that got out of hand, he became the first person convicted under the 1986 Computer Fraud and Abuse Act[1,2]. MIT took a different view. He’s a tenured professor there today.

The fallout was collaboration between computer scientists, mathematicians, and military historians on how to build digital castles leveraging ancient cipher concepts, virtual locks, and strict change management protocols. Laws and industry regulations like the Health Insurance Portability and Accountability Act[3] (HIPAA) in 1996, the Gramm-Leach-Bliley Act (GLBA)[4] in 1999, and the Payment Card Industry (PCI) Standard in 2006[5] formalized this one-size-fits-all adoption of security standards. Best practices aligned them with InfoSec principles of Confidentiality, Integrity, and Availability (known as the CIA triad).

In reality this strategy is no longer keeping pace with sentient opponents and rapid transformation of the digital ecosystem where “Who” we are is who our devices say we are and “What” is known about us is shaped by data brokers. It doesn’t optimize the right balance of proactive prevention and reactive resilience or position security as a business growth enabler.

Leaning into the Chaos
Enova’s Tech Team is very innovative. In 2019 we begin rapid adoption of DevOps practices. On the surface, it looked like the chaos was getting worse from a security perspective. We have aggressive goals driving automated deployments, more data distributed across multiple cloud providers, and AWS lambdas running hundreds of microservices. For many reasons, IT Risk couldn’t continue to follow the traditional path and hope to be effective partners. Our challenge is shared with many organizations as noted in The DevOps Handbook:

One interpretation of DevOps is that it came from the need to enable developers’ productivity because as the number of developers grew, there weren’t enough Ops people to handle all of the resulting deployment work. This shortage is even worse in InfoSec — the ratio of engineers in Deployment, Operations and InfoSec in a typical technology organization is 100:10:1[6]”

Our decision to change strategies has turned in a transformative journey. Chaos and resiliency are inherent with DevOps, but these principles actually align with the direction IT Risk needs to go. The traditional CIA triad shows the values of InfoSec, but these are not controls that secure data. Encryption and access controls keep data confidential, monitoring retains its integrity, and planning out disaster recovery mitigate risk of catastrophic availability impacts.

Security controls for DevOps support InfoSec values in a different way, which disrupts how we have always thought about security. These controls are not flawless, but they play an important part in reducing overall security risks.

So, what are the security controls?

Implementing this at Enova
We have gradually revised our IT Risk position and brought a new perspective to the system architecture and cloud strategy debates. This has helped create constructive discussions about the trade offs of automated versus manual deployments and configuration management. We continue to apply risk frameworks, like the bowtie model[6], to ensure we thinking through everything from both proactive and reactive responses. Now we have a better balance between the right and left side.

We still have many of the traditional security controls, but gradually we are shifting from static digital castles around on-prem hardware and OS layers to cloud-based infrastructure managed by configuration management systems. Microservices and serverless architecture are pushing our applications to handle both authorization and authentication tasks and making our systems more data-aware. We reduced the time to patch vulnerabilities by giving them more visibility as a tech-wide goal. We have more buy-in because we co-developed the security controls used in the automated deployment process. This has also allowed us to enhanced our process to scan for vulnerabilities prior to deployment.

The journey has not been without some setbacks. Our recent approach to security controls is ahead of some of the commonly used frameworks. We designed a type of IT Bootcamp with the help of our technical team to give more context about our strategy to our outside partners. This has also created more shared responsibility for security between IT Risk and Software Engineers.

Overall our new perspective has helped us embrace the chaos and build a security strategy that enables business growth. We are early in the journey and will continue to evolve. And in true Enova fashion, we’re always open to suggestions in pursuit of the best answers.

[1] https://www.infosecurity-magazine.com/opinions/the-history-of-cybersecurity/
[2] https://www.fbi.gov/news/stories/morris-worm-30-years-since-first-major-attack-on-internet-110218
[3] https://www.hipaajournal.com

[4] https://www.ftc.gov/tips-advice/business-center/privacy-and-security/gramm-leach-bliley-act
[5] https://www.pcicomplianceguide.org/faq/
[5] Kim, G., Willis, J., Humble J., Debois, P., (2016) The DevOps Handbook IT Revolution Press.
[6] Talbot J., Jakeman M., (2011) Security Risk Management Body of Knowledge, John Wiley & Sons.