Once it is acknowledged that risk mitigation is a driving business requirement, it is easy to change reporting structure. Proximity also has a positive effect on communication, cooperation, and understanding. Giving security a vested interest in the success of a secure digital initiative and the business it represents ensures better integration and more attractive results.
Another important change is to move the process from being sequential to one that is more parallel. Get the security experts involved with incorporating security values and features early in the application development process. Security experts can assess third-party libraries and code for vulnerabilities—ensuring that the latest versions and patches are applied even before they are added to the next iteration of code base. Incorporating security early in the process eliminates the substantial standstill that results when security reviews an app after its creation and has to review and analyze unfamiliar code and designs. Catch-up can be eradicated with security participating in the development process from the start. Decisions about trade-offs between risk and functionality can be made fluidly along the way. Most DevOps works around a model of continuous development and integration to enable better apps with less delay. Security should also be seamlessly worked into that model to prevent a right brain-left brain clash with unfortunate results.
While security needs to work alongside development, within the continuous development and integration context, having vetted code libraries and registries proves productive in providing security functions that can be incorporated by developers. Many DevOps teams favor utilizing available code to avoid wheel reinvention in order to achieve challenging sprint deadlines. Incorporating security routines fits nicely with this model and likely results in better production software. Often, right-brain software developers lack left-brain security expertise, particularly with cryptography and authentication processes.
Unfortunately, such off-the-shelf security code generally does not exist. It’s time to create repositories to share such code. Capabilities such as these still have to be integrated within the applications and can have a negative impact on performance if underlying compute is not available to handle CPU-intensive tasks typically required by the proper application of cryptography on a per-application or per-access identity basis. The work requires decisions around the necessary security capabilities required to minimize risk. For example, if stolen drives are the only risk, a single crypto-operation can be run across all operations that need to store data on a disk. However, most organizations realize that attackers landing on a device would likely get access to all such data if any users’ credentials were compromised. Best-practice approaches known as security-in-depth—would limit the amount of data at risk by providing unique-keyed encryption on a per-application basis, or limit further if deployed on a per user or even on a per-transaction basis. Ideally, developers would have to make no such decisions but merely connect in the proper security code that would allow the InfoSec team to set the appropriate level of protection within the application at the time of deployment. Done once, the process can be automated so that the application can be properly initialized and have its security settings configured on an automated basis.
It’s time for the right and left hemispheres of the brain to come together. The demands on DevOps and InfoSec continue to grow and the risks also tend to escalate as the applications become more important to the organization. Putting these teams together is a no-brainer. Yet it’s critical we give them the proper mandate and tool sets that allow them to be effective in achieving all business requirements, including security, while also meeting important business deadlines on budget.