GRC for DevOps

With recent rapid growth in enterprise security compliance demands, automated data collection and workflow tools have emerged to ease the administrative burden of dealing with auditors. The term for this type of computing support is Governance, Compliance, and Audit or GRC, and CISOs leading security teams of varying size and scope rely on such capability every day. It’s become standard in enterprise security.

A tenet of successful GRC deployment is that data must be collected, and corresponding actions taken, in the embedded context of business units. This implies that compliance should be examined and enforced from within the day-to-day workloads of an organization, rather than adjacent to, or outside, such activity. Embedding GRC into the business ensures accuracy of data collection and relevance of associated mitigation.

A common blind spot in GRC deployment, however, involves the software development lifecycle (SDLC) – which, of course, implies DevOps. Since DevOps was invented to deal with customers who (justifiably) cannot wait months or years from concept to delivery, it is reasonable to expect that the typical DevOps program will not have security focus as a primary concern. The result is a lot of scrum-born vulnerable code.

To understand this problem more clearly, I logged some time this week with Rohit Sethi, COO of Security Compass, a Canadian cyber security firm that provides products and services based on its SD Elements platform. Rohit explained how the Security Compass solution deals with the security and compliance gap in the typical DevOps SDLC – and it struck me as fresh and creative. Here is what I learned:

First off, Rohit said that Gartner is now marketing an acronym called ASRTM, which decodes to Application Security Risk Threat Management. While I dislike the acronym, I agree with the idea it represents, namely that security risk and threat management activities should pervade software application development. My advice is that in place of the stilted Gartner term, let’s call this what it is: GRC for DevOps.

The concept is that GRC collection, compliance, training, and management hooks are embedded in the most popular SDLC frameworks such as JIRA, Microsoft TFS, and IBM Rational. “The overall methodology supporting the Security Compass approach,” Rohit explained, "involves starting with identification of the SDLC processes and artifacts, and ending with meaningful action to improve the software.”

The identification of artifacts is done on the Security Compass platform through an interactive questionnaire that creates a model of the tools, languages, and other relevant decisions made by the SDLC developers and managers. The resulting design serves as a basis for subsequent security controls assessment of the DevOps process using applicable frameworks such as GDPR and NIST.

As outlined above, this framework assessment is performed directly in the context of the commercial SDLC framework chosen by the DevOps team. “Such embedded application into the most common development platforms allows for bug tracking, vulnerability management, and other security activities to be integrated directly into the DevOps activities,” Sethi explained.

Security Compass supports software validation and testing, which are perhaps the most familiar activities performed in modern SDLC environments to reduce security risk, by importing data, results, and input from common software security and quality tools for scanning, review, and audit. This includes popular offerings from companies such as WhiteHat, Checkmarx, Veracode, and HP (Webinspect and Fortify).

I guess it is somewhat of an open question whether most software developers will immediately want to embrace the inclusion of GRC hooks in their SDLC. My guess, however, is that once they understand the relatively minor impact that GRC will have on their day-to-day DevOps tasks, they will not only support the approach, but will appreciate the time it saves for painful and tedious compliance work.

If you are part of a modern software development team creating products in a DevOps environment, then perhaps you should set up some time with Security Compass to learn more about how they might save you considerable effort in your SDLC compliance work. I think it will be time well spent.

(And if you happen to run into someone from Gartner, perhaps you might express your displeasure at their annoying acronyms: They clutter our field.)