This article was originally pubished on SecurityWeek.
“Dear kindly Sergeant Krupke,
You gotta understand,
It's just our bringin' up-ke
That gets us out of hand.”
–Stephen Sondheim, West Side Story
Information technology is both an old and a young industry. Like archeologists, we can carbon-date the birth of the modern computing industry – even the birth of enterprise IT – to the IBM System/360 mainframe in the mid 1960s. The IBM mainframe was not only a breakthrough in separating applications from infrastructure, it was a system with perfectly documented and well-understood principles of operations.
Security was built into the actual hardware and mainframe operations and maintained a run-time approach of “privileged” operational states – think about it as the grandfather of today’s role-based access control. For me, this is the Andy Griffith Show, Mayberry RFD era of IT security: there were bad guys around, but for the most part, they were easily kept in check and living was peaceable. Everyone knew their roles and responsibilities and if they didn’t they could look it up in the IBM Redbooks – the social contract of enterprise computing. Everything you needed to know to build and run applications on the System/360 were in the Redbooks.
Flash forward 50 years, and we have had 2 major upheavals in the social order of computing:
- Client-Server/Internet: the PC and Internet era
- Distributed Computing: SaaS, Mobile, Cloud/IaaS, software eats the world, and emerging real-time continuous delivery of micro services
Every time we introduce a new era of computing (and they seem to be accelerating), the bleeding-edge adopters in the enterprise appear like gangs in the musical West Side Story: they are trying to do something new, something fast, and management or security appears to be a beat cop, the slow-footed officer Krupke who tells the innovators no or to slow down.
In this new distributed computing world, security needs to be part of the gang – a member of the Jets or Sharks in West Side Story parlance – and not the beat cop telling them what to do.
In the client-server era – which is not over, just as the mainframe is not completely over – both IT management, which included the emerging chief security officer role in the 1990s/2000s, latched onto the Information Technology Infrastructure Library (ITIL), a set of service management methodologies. This included information security management system that required organizations to design, implement, and maintain a coherent set of policies, processes and systems to ensure acceptable levels of information security risk. Security had a seat at the table, but it was still a silo.
Just as people have gotten their hands around ITIL, today’s emerging DevOps approach and continuous delivery models like Jenkins suggest there needs to be yet a new model, a new change to the social order of IT (including security) to keep up with the pace of development. In this new distributed computing world, security needs to be part of the gang – a member of the Jets or Sharks in West Side Story parlance – and not the beat cop telling them what to do.
Operationally, this requires security to be part of the automated delivery suite. This could mean change controls – patches, updates to existing applications – or more significantly, security should be baked into new application development, making for better code as well as better application onboarding and change processes. Security should get a leather jacket and become part of DevOps.
Of course, this raises the question: are you asking the inmates to run the asylum? In part, yes!
Security should get a leather jacket and become part of DevOps.
While IT security’s role has been a separate party to manage risk and compliance, does starting security oversight outside the continuous delivery process increase risk or lower it? Being part of the automation process provides more of a bulletproof, closed-loop process for security.
There is no going back to the Redbooks. Once application developers and DevOps methodologies enter the enterprise, people are not going back to the ITIL-centric world. The good news, however, is that security can enter the development process much earlier by embracing continuous delivery and deliver continuous security. Moreover, by becoming part of continuous delivery, IT can better educate – not just inspect – application developers on the time benefits of building security in early. Security’s “gonna speed fast and…gonna move like lightning.”