Similar to the human brain, the two hemispheres—the right side within DevOps and the ultra-left with security and compliance—are separated by a groove or chasm. Humans have the longitudinal fissure, which is really just space that demarks the two sides. Given their important charters, security and DevOps groups are relatively autonomous and often have little daily interaction with each other. Reporting structures are vastly different, and both groups are given carte blanche to pursue their missions. It is of little wonder why the two sides are at odds.
The separateness and divisiveness, however, are problematic and not sustainable. It is inefficient and cumbersome to sequentially develop an app and hand it over to security for review. Even worse is the practice of developing and deploying an app and then having it flagged for problems and shut down—or, worse still—missing problems entirely and allowing an under-secured application into production (POS systems, industrial IoT, connected cars, to name a few well-publicized failures).
It is too time-consuming to tack a security review to the end of a development program. The security team has to play catch-up with unfamiliar code and architectural plans. Changes imposed by security may be larger at the end of the process, imposing a great impact on the access, functionality, and performance. It could be a massive issue, requiring long, expensive, complex operations and potentially presenting a risk to the life of the project.
Waiting until the end of the development process to address security issues makes no sense—the compromises will be larger and addressing them may involve much more deliberation and work between teams. Aspirations of great utility and ease-of-use may suffer far more when the security review is at the end of the process. Leaving security to the end results in longer release delays, greater expense and resource involvement, and bigger compromises to both sides.
The forward-thinking enterprise realizes that having two separate hemispheres is no longer viable. The right and left sides must work together from the very beginning—just the way we have the application development teams working daily with operations. Security needs to be brought in to collaborate on the app design or at least to apply security controls earlier in the deployment phase without invoking the development team is the right path forward.
Achieving a more integrated process that brings security, application development, and operations together from the beginning, to form SecDevOps, involves some substantial changes … or does it?
One of the first necessary changes is charter and accountability. Security and DevOps must both understand and participate in goal setting for the business. The business owners must acknowledge and include risk mitigation as a key business goal. This can start with an analysis as to whether the desired application may create a significant risk to the organization—usually determined by whether the application is touching or is generating critical production data. If yes, there is great risk, and, if not, then it ?is minimal.
The decision about what level of risk the enterprise is willing to take on in order to accommodate important business initiatives should be set at the board of directors level. While this may not seem to be a typical board of directors or senior corporate management standing agenda item, it is becoming one. Security studies from Kaspersky Labs, as well as the Ponemon Institute have found that significant data breaches have not only cost organizations millions of dollars but, in about 25% of the time, prompted the dismissal of senior corporate executives. The new reality is that regulatory compliance changes are driving board decisions, as well as cyber-risk assessment especially as the realization grows that breaches do substantial long-term injury to businesses.