By Shauli Rozen, CEO of Cyber Armor
Continuous integration (CI), continuous delivery (CD) and agile development quickly delivering minimum viable products (MVPs) have become the norm, replacing waterfall development with minor quarterly updates and major yearly or semiyearly releases.
Everything is being built and tested earlier and earlier in the process by tighter teams to ensure even the MVPs go to market with as few defects and security vulnerabilities as possible.
These new processes are creating growing pains for well-established organizations and causing them to be playing catchup with agile startups who have had the opportunity to build these processes from the ground up.
Issues have also arisen in the face of accelerated development – where does security go? When applications were monoliths, most of the security depended on the infrastructure. Now, with the age of microservices and containers, security has become a more critical consideration during the development process. This results in companies facing cultural challenges in adopting or implementing security within the development cycle, and the introduction of a new role / paradigm – the DevSecOps.
The mere concept of DevSecOps means that security is embedded into the development and deployment processes (Continuous Development / Continuous Integration or CI/CD). That simple definition points to the main cultural shift that needs to happen in organizations embracing DevSecOps – security is an inherent part of software development; it’s technical, it’s driven by the developers, and it needs to be embedded in their processes, if it isn’t already.
It also means that the scope of enterprise security is starting to get divided into two different disciplines, requiring very different skills and roles: “IT security” – which is responsible for policies, email protection, document protection, and the general security of the operational environment of the organization. And “Production security” – which is responsible for the solutions deployed by the organization in is data center and in the cloud, this discipline is very technical in its nature and involves the actual production environment of the company.
While CISOs still have overall responsibility for the organization’s security posture, a new breed of security personnel is emerging — the “development-minded” security architect who works closely with the development and DevOps teams on the company production environment.
For example, one security project we are currently running is led by the R&D security architect. He is “R&D born” and went into security as part of his role. During our first meeting, he said, “I am in charge of solution security, but please do not call me CISO. CISOs create policies; I build environments.” That says everything about the shift that is happening.
Creating the Right Environment
To successfully initiate a DevSecOps shift, security responsibility needs to be pushed “left and down” in the stack. First “left” – into the engineering team, where R&D leaders and CTOs take more of that responsibility into their groups. Then “down” – from the executive level to developer level.
DevSecOps is a practical role, not academic. It needs to be built into the development teams, adding tools that will enable them to easily deploy secured solutions as well as reduce the amount of overhead it creates.
The challenge is that for developers, functionality will always take first priority — as it should, and that’s why tools that enable them to seamlessly add security best practices to their code and products are extremely important as part of driving the DevSecOps shift.
A practical first step would be to appoint security architects who actively participate in the design process of every solution and work hand in hand with cloud architects and system engineers. These security architects can have a dual reporting line – to the engineering leader and the security officer.
The shift is happening whether organizations are ready or not. They need to step in and take control to ensure that the next big data breach isn’t because of weaknesses in their architectures and applications.