John Elliott on aligning GRC and pentesting for security assurance

Beyond writing policies and procedures, what exactly do governance, risk, and compliance (GRC) teams do all day, and what does it have to do with security? Those are just some of the questions that Pluralsight author and lead pentester, Peter Mosmans posed to author and GRC consultant John Elliott. The two explore everything from the different types of compliances to where collaboration fits into building a more effective and robust security culture in this video.

• Breaking down the tension between GRC and operational security teams
• Penetration testing: Not a one-size-fits-all answer for security
• The impact of contributory factor  analysis with regular penetration testing
• Security culture and collaboration
• Get more of Elliott’s takes on why to pentest (and often)

There tends to be a natural tension between GRC and operational security teams. As John puts it, security teams may think GRC just writes nice-looking documents, while GRC teams have a tendency to think security teams just look for vulnerabilities. In actuality, the two teams are dependent on each other to maintain compliance and protect an organization’s assets. 

John explains the purpose of GRC further, saying, “The reason we write nice documents is to make sure that as an organization, we understand what security we want to do. And that we're committed to doing it. We don't all have limitless budgets for security. We need to work out how much money we've got and determine what's the best use of that money.”

It’s also important to remember that penetration testing is not a pass/fail matter. It’s a way of discovering vulnerabilities in your environment. Nothing is ever perfect in security or compliance; instead, it’s more of a point-in-time exercise, and finding vulnerabilities is the goal and to be expected.

On the topic of penetration testing as an assurance activity, John further explains that it is not a way to prioritize security for your organization. Similarly, neither is compliance: you can be compliant with a standard but not necessarily secure. Organizations may be compliant with standards written years ago, which doesn’t lead to them being secure.

Within GRC, there are two different types of compliance. There’s compliance with what organizations have said they want to do and risks they’ve identified—that’s internal compliance—and then there’s compliance with external obligations. 

“That's our internal security policy. That's based on two things, what risks we see out there, and secondly, what obligations we have to the outside world,” explains John. Obligations may include contracts with other organizations or those governed by laws and regulations in the environments organizations operate in. 

Organizations also have different levels of risk. Some systems have more sensitive information than others, and some are public-facing with a greater attack surface to the outside world. 

John gives the example of the airline industry to highlight the importance of contributory factor analysis. “Would you be happy flying with an airline that only tested airworthiness by relying on the FAA coming in once every few weeks and having a look at the airplane?” Hardly anyone would be okay with this scenario because the risk of an airplane falling out of the sky is too great to leave up to irregular review and testing. In airline safety, it’s the processes and management that are assessed because we know that’s what leads to safe outcomes.

John urges organizations to prioritize regular penetration testing and contributory factor analysis. Often security is thought of as compliance-based, where you go and test the control rather than working out how this organization does security well, how it tests its third parties, and how controls are working (or not working) on a regular basis. 

Going back to our example of aviation, when things don’t work in aviation, people do contributory factor analysis to find out the reasons why something failed and what you can learn from it. “That’s one of the things I love about penetration tests is that when I get results, I’m not just thinking I’m going to fix that vulnerability,” says John. “Instead, GRC asks, ‘Should that vulnerability have existed in my organization? How did it end up here, and why didn’t we catch it earlier?’”

By performing contributory factor analysis, you can improve your processes to make your organization more secure. It comes down to finding the vulnerability, assessing and fixing the vulnerability according to the prioritized scale, and determining if the enterprise would have expected to find that vulnerability or whether it should have been found by a previous control or process because what’s important is that you fix that process. Otherwise, similar vulnerabilities will ​​occur in the future.

Peter notes that companies that ask for more penetration tests are generally more secure and have a culture where everyone is involved in security. Building a security culture based on collaboration starts with saying we’re all in this together. John recommends remembering we will have tests and we will find vulnerabilities just as audit assessments will uncover room for improvement in the GRC world. 

“We’ve all been trained from age three or four that tests are things you have to pass. There’s naturally bad language there. And a lot of penetration testers actually start the exercise by using pejorative language about how easily we broke into your organization,” explains John. 

This type of approach to security only reinforces finger-pointing and playing the blame game. This is where contributory factor analysis comes in. It’s not so much looking at a person who made a mistake that caused a security risk but identifying the reasons why the mistake or risk occurred in the first place. 

John has two recommendations for building a security culture and improving collaboration. The first is considering the language around penetration testing as security operation teams engage with the enterprise. Specifically, it’s ideal to engage from the perspective of pentesting serving as an assurance function and a means of discovery—and eliminate a sense of “pass or fail."

Next, it is important that penetration testers understand risk and prioritization. “Not every vulnerability is actually a risky vulnerability to the organization. Not every organization can patch all the things all the time,” elaborates John. “Sometimes you have to make a decision that you’re going to do segmentation or blast radius reduction because you only have so much bandwidth and budget. You have to prioritize.”

Overall, John emphasizes the importance of alignment between operational security and GRC teams. Instead of seeing each other as opponents, the two departments should work together in a partnership to better the enterprise’s cybersecurity stance. You can dive deeper into his insights in the full video.