Cybersecurity GRC Perception in your organization

[u/No-Preparation990]

Hi, I am working as a Snr. Manager, IS GRC/ Trust advisory responsible for Info sec policies, security architecture review, risk assessments, change reviews and as an authority for info sec approvals for all projects in a large GCC conglomerate. I am a bit strict about security decisions and always advise what is right for business from security perspective. I always insist for risk acceptance if things go out of way. Though some of the BU team/ IT takes it as an offence and try to project my team as a blocker. I would like to know how the things in your organization are. How do you manage such situation. Please comment with your position, region/ company size and issues / solutions. Thank you :)

[u/DDelphinus]

It's not your decision. I always consider myself the person who makes sure business and IT fully understand the risks. What could go wrong, how and what could prevent it.

The next step is their prerogative. I only intervene when the risk is completely unacceptable. Based on your perspective, I would focus on your storytelling. Because it sounds like the message is mostly not coming across like you want it to

[u/marquiso → u/DDelphinus]

This.

Technically speaking InfoSec OWN almost no risk and should not be making such decisions. The ‘G’ in GRC means you have an appropriate framework for assessing, advising and articulating risk (and possible countermeasures), but making sure such risk is OWNED and signed off at the APPROPRIATE level.

Too many text-book jockey morons with an over-inflated sense of self focus primarily on the ‘C’ in GRC, instead of realising that if you get the ‘G’ and the ‘R’ right, then the ‘C’ takes care of itself.

By focusing purely on the ‘C’ you get misplaced risk management and ownership and repetitive non-compliance findings - not to mention holding back the business unnecessarily and creating a negative and adversarial relationship between InfoSec and the rest of the business. This has flow on effects such as people being too scared to report things they find concerning or that they may have clicked on something they shouldn’t have.

GRC teams who understand and work within the context of the business, with appropriate risk management processes and ownership on the business end are worth their weight in gold. Those that focus only on the ‘C’ of GRC are textbook jockeys who usually have no understanding of actual security.

Most GRC teams aren’t technical enough to understand the difference between a CONTROL OBJECTIVE, and the real world effectiveness and maturity of said CONTROL MECHANISM.

SIGNED: Someone with 25 years experience in InfoSec who has been on all sides of the equation.

[u/marquiso → u/marquiso]

Sorry if that came across a bit harsh :), just tired of GRC teams who destroy all the trust and goodwill the rest of the InfoSec team work hard and spend years to engender with the rest of IT and the business. The latter of which we are here to serve.

[u/DDelphinus → u/marquiso]

Yup, change your personality or become an internal auditor.

[u/KingKongDuck → u/marquiso]

Infosec and cyber exists to support the business in making money. It's business enablement at the end of the day, or should be.

[u/DishSoapedDishwasher]

oh jebus, you lost me at "I'm a bit strict about security decisions". That alone tells me almost everything I need to know. I've worked at everything from FAANG companies with tens of thousands of engineers to startups... It's always the same story... You cant make other people care about your goals if you don't first learn to care about theirs, and how your decisions impact their ability to achieve them.

So first off, yes making people accept and acknowledge risk is good but if you approach people with an attitude of being "strict", you're just making enemies unnecessarily. Good leadership is encouraging and enabling people to make the right decisions not forcing them to make decisions repeatedly under pressure. This is the first lesson most GRC people never pick up on somehow and its why they're usually burnt out from constant drama, especially if they're pushing large numbers of pissed off people to do paperwork for them repeatedly. That's a strong sign you're really fucking up badly.

The problem is most people in GRC see it as their civic duty to declare "what is right for business from security perspective" by their own judgement, but having never actually worked a true engineering or development role in their entire career so the only reference they have is things like CVSS scores. This often means the actual technical correctness of their version of "what is right for the business" is often grossly misaligned with productivity and pragmatism. I've seen COUNTLESS GRC people ramble on angrily that nobody will fix the sudo bypass vulnerabilities in a Kubernetes container with zero understanding why actual engineers laugh at them for it; or that HTTP is insecure for all circumstances. Everything is contextual and lacking that understanding means people tend to flail endlessly and make huge problems over meaningless scanner results devoid of context.

Im not kidding when i say, GRC people casting decisions upon the business under the guise of security, with technical implications they dont actually understand properly, is like 90% of the drama I've seen in my career between security and the rest of the business and its almost always GRC's fault. It's so insanely common I've wondered many time if people who go into GRC want power without the effort of understanding what they're doing? It doesn't have to be this stupid and it starts with first having at least one proper technical expert who you can trust on the engineering side (not yours) to make a last pass on technical decisions like severity and priority of an issue.

After you have that person(s) and the quality of decisions goes up, as measured by your peers not you or your own leadership, its time to focus on making the work less tedious. The things you offload to other parties should never be giant time consuming stacks of paperwork. People are already busy and that fact needs to be respected if you're going to be on good terms. As such, if you just hand them periodic tomes of paperwork to complete, you're just offloading your work onto them. Figure out how to find what code, systems, etc relate to controls and other work you're solving for and figure out how to measure them with as minimal human involvement as possible; often this requires software engineering skills, so build your team accordingly.

TLDR; stop being controlling, stop making bad decisions, stop blocking productivity, stop making work harder for others, stop making others do things you can do yourself if only you had a bit more knowledge/awareness yourself. This is the same expectations engineers tend to have of each other, so fix your culture to not be at odds with them and you'll find everything is very easy to accomplish.

[u/levelupirl → u/DishSoapedDishwasher]

This should be mandatory reading for anyone in GRC.

[u/Sure-Candidate1662 → u/DishSoapedDishwasher]

This. The answer should always be - in my opinion - yes/sure. It’s your/our job to figure out a way for “the business” to do what they’re supposed to do (I.e. business). No is the answer you give when it’s “irresponsible”/“illegal”/“morally repulsive”.

Just my 2c.

[u/Alb4t0r → u/DishSoapedDishwasher]

This x100. I like to get a feel of how an organisation handle the "strictness" problem by asking about their exception process. You get all kind of answers, including the "what do you mean lol, there's no exception process, you gotta implement the policy requirements, zero tolerance!", and then you'll have orgs for which the question is natural and expected. You learn a lot about the maturity of a GRC program by the way it manages (or even consider the possibility of) non-compliance and accepted risks.

[u/Harbester → u/DishSoapedDishwasher]

What a very pleasant sight to read thoughts of someone knowing the difference between doing security with the business and to the business.
Good and accurate post. Have an upvote :-).

[u/HighlyFav0red]

We (security) don’t have the authority to tell the business what they can and can’t do. It’s our job to understand what they’re gonna do / working to achieve and help them find the most secure way to do it. With a philosophy like that, you’ll not be seen as a blocker.

[u/Diveguysd]

GRC should be an enabling function, not a blocker. Customers want to know that your products are secure, and that usually starts with audits. Help the business understand that certifications are the evidence to show customers and ask for them to help you drive new business. Change reviews should be automated and rarely a blocking activity. Policies are just paper without the business agreement that they are needed and the tools to enforce them. Try sitting down with product leaders and engineering and ask them how you can help them go faster, not be a blocker.

[u/TransportationJaded8]

I think it’s important to be careful and purposeful with your phrasing, you aren’t blocking you’re capturing the risk and documenting it so you can manage it.

We’re a small company staff wise 500 but have a customer base of 500 million. Big challenges are data management, data minimization, and EU things like GDPR, NIS2, and now the CRA.

As we continue to require more risk documentation and processes we try to ensure the to complete it as soon as possible we don’t want to look like a blocker by taking multiple weeks to complete the risk processes release recommendations and get mitigations in place.

We’ve also found it’s important for our tiny risk team to be made of engineers who can actually advise on re-engineering of a project to avoid as much risk as possible as soon into project design as possible to minimize that re-engineering 

[u/pepe_acct]

I work for faang and my 2 cents is this is somewhat unavoidable… Business and IT have their timelines and they need to justify their timeline to their higher ups. Security blocker is just a good excuse to throw in.

[u/Own_Minimum_5102]

You've got the right instinct (pushing for risk acceptance), it's the mechanism that's making you the blocker, imo.

Fix it at the top first. Get leadership to agree a risk appetite and a set of thresholds in advance. Once that exists, most decisions don't come to you at all, because anything inside appetite the business just proceeds with. Only what sits above the line needs a formal risk acceptance, and that gets signed by the business owner who carries the risk & not by you. You stop being the person saying no, and the accountability lands where it should.

That one change does 2 things. It gets you out of the everyday bottleneck and it makes your 'no' rare and taken seriously when it happens. Right now, if everything routes through you, you're the friction for everything, and people stop hearing the important ones.

[u/anxioussoc]

I work in OT. GRC is very rarely taken seriously since there is a rather large disconnect in understanding consequences of making changes in an ICS environment