Hi folks, Ed Amoroso here. And in this video, I want to introduce the topic known as Governance, Risk, and Compliance, or GRC. It's a discipline that's well-known in business and government and involves for the most part doing those three activities, governance, risk, and compliance. Let's talk through them. So governance, first of all, involves sort of a high-level oversight of the direction of an organization with respect to security risk, controls, attacks, and so on. So really tends to be an oversight kind of role, often by a group, a board of executives, some senior folks with experience, who can make sure that decisions are being made that will make some sense. So that's the G part in GRC. The middle one, R, risk, is all about whatever needs to be done to reduce the likelihood of cyberattack and to reduce the consequence of attack. And usually we keep track of a lot of different risks and issues where a requirement and maybe some better or intended requirement exists. We refer to that as gap, and I'll get to that in a minute. And then the third, the C, the compliance part really does in fact measure whether or not what you're doing matches some standard or framework that's either been imposed on you or that you've decided is a good idea to use. A lot of times these frameworks will come from governments, or from regulators, or from third party auditors. So governance, risk, compliance is the discipline, and every business now has some sort of a GRC function, probably supported by a platform. I want to give you an idea of how a GRC platform and a set of framework requirements can be used to improve security in a company. Let's say for example, that a corporate security requirements document included a couple of different requirements, one of them saying passwords have to be six characters long. And the second requirement saying managers have to approve critical access requests. Fair enough, and there may be some local definition of critical versus non-critical. Let's say that's the corporate security requirements that are in place. And then for whatever reason a third party imposes on that corporate group a framework set of requirements. Let's say it's framework security requirements, let's call it that. And that embedded in that framework are two different requirements. This first being that passwords have to be eight characters long, and that any type of request, all access request has to be approved by managers. So what would happen is that as part of the GRC process, the security team would go in and take a look at these things and say. Our requirement is that we want passwords to be six characters long, that's good enough, but this new framework coming along saying hey, we've gotta make them eight characters long. That difference is referred to as a gap. The gap means what you are doing is not as strong, not as tight, not as good, as the thing you're being asked to do. If it was the reverse, [LAUGH] If you were doing eight and the requirement was six, you have no gap. Do you follow? It's the strength difference. If you're six and they want eight, eight is stronger, you have a gap. So that's a gap in the first one. The second we said, in our corporate requirements, that managers only approve critical access requests as opposed to non-critical. But now we've got this framework requirement that says managers have to approve all access requests. Stronger requirement, I have a gap. That make sense? That my requirements have a framework that has some stronger requirements, I measure a gap. The GRC tool would help you identify that gap, and would list that. So what do you do? Well, you make the change. You start with six and critical, the requirements are eight and all, what do you do? You change your corporate requirements to eight character passwords and all requests have to be approved by managers. Now look, this is not a simple matter of doing paperwork. As you can imagine, the paperwork implies all sorts of different implications on systems in the enterprise. You have to go system by system, group by group, business unit by business unit. Perhaps individual by individual, device by device, checking to see if there's a requirement or a control that is okay with six characters, now you have to change that to eight. That could be a lot of work, imply expense, time, complexity, on the enterprise. But again, that's the purpose of the framework model. The framework says you have to fix this. Six is too easy to guess, it's to easy to hack. So you go through that. Similarly, the access request, you have to go through all the different workflow activities in a business. Look and see, well right now, non-critical requests for access to whatever. I want access to this database. It's not deemed critical, so I don't have to have managers do any sort of approval. Now with the new framework requirement, I have to change the workflow. There might be automation changes. It might require things to take more time. It introduces bureaucracy, all these negatives, but the positive is it's more secure. Do you follow? So GRC really is about adjusting requirements, making them somewhat more in line with the threat model that makes sense in the environment. And then when you make those changes, think of all the back-end work activities. We tend to say that GRC is best done when it's embedded in business processes, and it has to be. If you're going to comply with these types of changes, you're going to be embedded in password access. You're going to be embedded in management approval of access to resources, and on and on. These are just two examples, there could be thousands of requirements. So think how complicated this really can be for a business to establish compliance to a non-trivial set of requirements. Now the good news is if you pick one, good, solid framework and you do it once, then chances are any subsequent framework that comes along will be met. For example, in the United States, you might be following a big national framework. Let's say you follow the requirements, you do what needs to be done, and then you live in a state, let's say you live in California. And they come along with their own set of requirements. So for example, let's put a second framework here, Framework 2. And Framework 2 comes in and it says passwords just need to be six characters and access just to the critical systems. Well, you would look at that and you'd say, six? We already have eight. Critical, we changed to all, we have no gap here. So you could say you're now compliant with Framework 2 without really having to do much. But you may have some paperwork that would be attended. And ditto, let's say a third framework comes along, and they say passwords have to be seven and that access has to be all. Well I have access all and my password's right again, no gap. Do you see how subsequent framework compliance activities might result in little or no work? Now that's good news, bad news. It's good news because you're probably not going to have a lot of that attendant activity, the back-end activity in the business process and workflow to manage the compliance problem. The bad news? There's all this paper work. So [LAUGH] I just did Framework 2 and 3. I might have to work with an auditor to convince them that everything is already met. I may have to fill out a bunch of forms, attend a bunch of meetings, that takes time. And you could argue that that's time and effort that's wasted because you're not really improving security. The first time I did it, that was great, that rocked. I had requirements that weren't strong enough. And I went in and improved things. These latter two examples we went through? We didn't change anything, all we did was the paperwork and attended the meetings. It's one of the reasons why a lot of cybersecurity experts are critical that compliance has gone too far, that there are too many different frameworks. And really what needs to be done has to be done once and be done properly. So I hope this has been a good example. Now, let's do a little quiz. So the answer is D) All of the above. Those are all true statements with respect to GRC platforms. I think this is an area that has increased in its relevance in cybersecurity in recent years, I think, exponentially, it's become absolutely vital. But what we need is we need policymakers to think through how we can do one good, solid framework once instead of driving so much paperwork for cybersecurity teams that could be better spent doing operational security. So this has been a useful introduction to GRC with our little case study. And I hope this will inspire you to maybe look into GRC as something that you'd do in your own business, thanks.
