Bridging the priority gap between IT and security in DevOps

Let’s start with a test. Suppose that you manage a corporate network gateway across which a critical programmed transaction is scheduled to occur in exactly one hour. Suppose further that the firewall protecting this gateway is functionally misbehaving and will almost certainly block any programmed activity with your transaction partner. This is a serious concern because your boss has reinforced to you several times the importance of this planned transaction.

Your team continues to work the technical problem, but it is now 15 minutes before the transaction is scheduled – and it is still not working (and your boss is unreachable). Your team explains that the firewall rules management function has failed, and that by disabling the entire firewall, the transaction can be made to proceed. You are told that such action, however brief, will leave the corporation open to inbound attacks, a blatant violation of security policy.

So, what do you do? If you decide that firewall disablement, which you rationalize as really nothing more than just a brief administrative change, is clearly the lesser of two evils, then your tendency matches that of many IT professionals. If, however, you decide that exposing the corporation to inbound attacks could produce negative results far worse than missing some scheduled transaction, then your tendency is more in line with that of security professionals.

Setting aside any justifiable quibbles you might have with stereotyping individuals working in IT and security, most observers would agree that some priority gaps do exist in the motivation, emphasis, and objectives associated with each of these important roles in an organization. Executives who do not acknowledge these priority differences should expect occasional, perhaps even frequent, operational challenges in projects involving both IT and security.

One area where priority collisions emerge between the two groups is DevOps, which is the preferred modern lifecycle model for developing software in most environments. IT and development teams will typically view DevOps in terms of its advertised benefits: Faster cycle times for new features, higher satisfaction rates for programmers, greater levels of agility for ever-changing user requirements, and on and on. These are truly positive benefits.

Security professionals, however, will often raise reasonable protection concerns regarding the DevOps process. The core of their common argument is that going faster in any lifecycle can lead to errors, which might then lead to exploitable vulnerabilities. Security pros will tend to remind DevOps teams that despite the need to introduce software features in a more agile manner, attention to basic security controls still cannot be ignored during the process.

This challenging priority gap existing between IT and security in the DevOps lifecycle might be addressed in different ways. For example, it can be arbitrated or even adjudicated by managers who keep an ear to the ground in all compliance and governance disputes, and who try to maintain order amongst teams regarding risks. While such efforts are always advised, larger DevOps environments will require more methodical controls than just diligent management.

Instead, IT and security teams are beginning to recognize an important area where they can not only agree, but where the DevOps process can advance the goals and agenda for both groups. This area is automation – and the various options for introducing automated support, especially for cyber risk and compliance, have grown in recent years to include many attractive vendor offerings that are rooted in practical, empirical experience.

For DevOps teams to address this priority gap between IT and security teams during DevOps, the best strategy involves optimizing automated solutions to support the governance, risk, and compliance activities that are now considered essential to any modern software process. Such automated approaches are consistent with industry models such as the Gartner Application Security Risk Threat Management (ASTRM) model.

The good news is that DevOps teams have excellent commercial options to address this growing security risk.

The result of DevOps enhancement via cyber risk and compliance automation is many-fold: First, it introduces important GRC controls to reduce risk and improve compliance support for DevOps. Second, it helps security controls keep up with the agile pace of modern software processes. And third – perhaps most importantly, it effectively supports the goal of reducing the priority gap that exists between IT and security teams working DevOps.