Early in Illumio’s history, I saw the future of DevOps security. The CISO of an electronics manufacturer brought us in to help secure a new support service that was built entirely in the cloud. After meeting with the security team, we were introduced to the application development team who cast a cold eye on our technology. About five minutes into the demo, the group’s manager asked to take control of the keyboard and start using our software. “I know how to use this. It’s like network-security Chef,” he said with a wry smile. He flew through the UI.
Fast forward to the recent DevOps Connect event at RSA, which underscored the critical importance of cybersecurity to the application development process. If business increasingly relies on agile software development, the lack of corresponding fast-moving security approaches effectively increases the risk of a breach or a cyberattack. You cannot build and mount applications in a distributed application and computing environment and then rely on a static, hierarchical security model built upon chokepoints, infrastructure control points and organizational silos.
Traditionally, one group created applications and another deployed them on the compute infrastructure. Then, a third group implemented security and ensured applications were trusted, particularly through instrumentation of the perimeter network security. Those days are disappearing.
It is time for a new relationship – and new, shared technologies — among DevOps, infrastructure and security, expressed through what I believe are are 10 principles for DevOps and security.
Principle I — No divine right of InfoSec primogeniture. Security must not be run in a silo. While security teams play the most critical role in assessing corporate risk and setting policy, there must be leadership and shared responsibility across various IT functions.
Principle II — Orchestrate but remediate. Security must be as responsive to continuous delivery as application creation and scaling. Application developers need cool, agile tools for security, too.
Principle III — Application developers must not put the organization in harm’s way. They must consider security at the beginning of the application development cycle and not simply hand off the responsibilities to others. Moreover, they must have security capabilities well instrumented into application development tools and infrastructure.
Principle IV — Speed should not kill. Lack of speed hurts business. The spread of malware kills business. The speed of application development should not provide a corresponding acceleration in security risk.
Principle V — Reduce the attack surface. Application developers must co-join with security teams to reduce the attack surface available to bad actors. By considering exposure and risk at the front end of the DevOps cycle, fewer issues should arise afterwards.
Principle VI — Security must be built-in, not bolted on. Application and security architectures that can contain the threats are the order of the enterprise. To Principles IV and V, this increases organizational speed and reduces risk.
Principle VII — Equality of the data center and cloud. Information security must be considered and deployed equally for the data center and the cloud. Separate but equal approaches are not the preferred path for IT professionals. The more widely distributed and deployed applications become, the more unified the security approach must be.
Principle VIII — Stream, not batch. Security must deploy as streaming technology, not batch processes. There is no “set it and forget it” approach for security in a DevOps world.
Principle IX — A minute lost finding a breach is unacceptable. Only a minimal amount of time (second, minutes) must pass in finding cyberattacks and breaches. Systems must be engineered for constant visibility and notification of policy violations.
Principle X — Common Contribution. The maintenance of a strong DevOps security approach requires a shared contribution to application and security approaches toward the common good. The day of IT silos is ending.