Software development may be a faster process thanks to the rise of Agile, DevOps, and continuous delivery, but governance, risk and compliance (GRC) management are slowing things down.
There are many manual and lengthy checks that go into GRC to make sure the software is secure, adheres to laws and regulations, and is on track with the company’s business goals. However, in today’s modern software development world there are new methods being applied to speed up the process, according to Rebecca Parsons, CTO of ThoughtWorks.
There is currently a trend to automate more parts of the software development life cycle, and while automation is typically associated with software testing, ThoughtWorks’ recent Technology Radar, a guide to technology trends, found a move to apply automation to governance, risk and compliance.
“We see a natural evolution in the software development ecosystem of increasing automation: continuous integration with automated testing, continuous delivery, infrastructure as code, and now automated governance. Building automation around cloud cost, dependency management, architectural structure and other former manual processes shows a natural evolution; we’re learning how we can automate all important aspects of software delivery,” the Technology Radar stated.
Some examples of automated governance from the Technology Radar included:
- Dependency drift fitness function: Tracks technical dependencies in software to see if it needs improvements or if any potential issues get worse.
- Security policy as code: Security policies put rules and procedures in place to protect systems from threats. Treating policies as code enables them to be automatically validated, deployed and monitored.
- Run cost as architecture fitness function: “This means that our teams can observe the cost of running services against the value delivered; when they see deviations from what was expected or acceptable, they’ll discuss whether it’s time to evolve the architecture. The observation and calculation of the run cost is implemented as an automated function,” the Technology Radar stated.
“You don’t have to spend time doing something that a computer can do,” said Parsons. “It really ties into the broader narrative around continuous delivery where you try to ensure that you can, in an unimpeded way, get to production from checking in code.”
According to Service Now, automating GRC can improve visibility, save time, reduce risks, prevent problems and enable businesses to respond quickly to changes. In a white paper, Service Now provided eight tips to automating the GRC process:
- Defining business rules: Do this upfront and include them in an implementation plan. Things that will need to be defined include controls, control owners, control tests, risks, and critical vendors.
- Rationalizing controls: Some questions you need to ask yourself include: How does this control support my business objectives? Is this control actually preventing or detecting risks? And is there a different control I can put in place that better protects my business?
- Consolidating controls: There are common, repeated controls across the multiple regulatory authorities and frameworks. Consolidating these removes any redundant tests and repetitive activities.
- Defining what’s important: To avoid massive amounts of unnecessary work, define what matters.
- Identifying risks: Include the impact they will have and the likelihood of those risks occurring.
- Starting small: Adding automated GRC functionality incrementally can help minimize business disruption.
- Building toward continuous monitoring: By being able to identify and control deficiencies when they happen, you can catch problems when they are small and prevent them from getting out of hand.
- Picking low-hanging fruit: A good start can be with administrative overhead or processes related to current audit findings.
The number one tip or prerequisite Parsons had for automating GRC is to be able to define it in an unambiguous way. “You can’t automate something if you don’t actually know what it means,” she said.
Parsons noted that the reason there isn’t one single way or more tools available to apply automation to GRC is because technology stacks are complex and often times it is too hard to figure out how to define certain aspects, and different organizations are going to be exposed to different kinds of risks.
She went on to explain that some things will be easier to automate than others such as code analysis metrics or declaratively stating a policy in a tool to do a checking for you, but if you are clever about it there are some ways you can automated GRC work.
For instance, Parsons has seen an organization that was worried about open-source license changes take a hash of the license file and include a check in the build for it. The hash then would compare the license to the check, and if the license was different, it would notify necessary parties. “The only effort that is required is every time the license changes, you have to go back and change the automated check to compare to the new license after the lawyer says he is happy with the new license,” she said.
Parsons does acknowledge that not everything should be automated, and it really comes down to what is being checked. There will be some instances where you still want a person in the loop, but she added that it also doesn’t mean they have to do all the work. Parts of GRC can be automated and then manually checked by a real person.
“When you turn over that responsibility to an automated process, you do lose a level of control because you are no longer making that decision,” Parsons said. “On the other hand, if you are the person that is specifying what it is being looked at by the automated process, you still have that same level of assurance as long as you are confident in the check.”
Additionally, the way automation is applied to GPR has to evolve over time as technology and techniques evolve. “Hackers are constantly thinking of new ways of breaking into systems, and you can’t say you automated all your security checks and no longer have to think about security because hackers are going to come up with a new way of getting in,” said Parsons. “These things are not one and done, they have to continually be evaluated that they are still checking for the right things.”Some areas that might not be a good place to start are things that tend to take up a lot of time in the manual governance process because that probably means there are a lot of nuances involved. “You want to start with things that are well understood so you can start to see quick wins and then spend your time trying to [break down] some of those things that are more ambiguous,” said Parsons.
