← GRC & Me
GRC & Me
Mastering Continuous Assurance and Automation
00:24:20
In this episode, Google Continuous Assurance Engineering Director, Vikram Khare, and Senior Software Engineering Manager, Eric Zhang, discuss implementing continuous assurance, with tips for getting started and real-world examples through the lines...
Loading summary
Transcript32 lines
- [00:00]
A
Foreign.
- [00:09]
B
Welcome to this episode of GRC and Me Logic 8's podcast focusing on the latest trends in GRC and cybersecurity. I'm Megan Manifold and joining me today is Eric Tseng and Vikram Carr from Google. I'm really excited to have you both here today as we dive deep into continuous assurance and automation. Welcome. Welcome. We're going to start with our myths and misconceptions section. And I'm going to start with you, Vikram. So let's talk about continuous oversight. So continuous oversight is perfect for the first line of defense, but auditors don't need to know about it, right?
- [00:46]
A
Yeah, that's something that's often said. We hear this a lot when we're talking about the need for containers, continuous monitoring, and introducing more automation. I think that statement somehow sandboxes and it takes compliance away from other IT disciplines. It somehow makes it so that compliance can't be automated. And oftentimes when you look in like the way organizations run, compliance organizations can be placed at a cyber security area. They could be standalone, there's different things like that. But I believe that, you know, anything should be open to continuous monitoring, testing and auditing. It's basically just introducing automation into the space. And in order to do that, you need to have standardization. So in terms of like, other lines of defense and potentially third parties benefiting from it, I do think that generally there's a lack of standardization in terms of like, how can we actually communicate what's needed for a particular compliance requirement or privacy requirement, and how do we share that between say, a cloud provider, a customer, a third party auditor, a regulator, different things like that. And there are proposed standards that are in place for that. But there's no reason why right now a second line of defense, third line of defense, a customer who has to audit, a SaaS provider, a cloud provider, or even a third party auditor can't look at evidence that's been automatically collected, evidence that has been generated in a more automated manner. And there's no reason why internal, you know, internal to us. Again, the second and third lines of defense can't benefit from reviewing data that's collected in an automated manner. I think probably the most important aspect of continuous assurance, monitoring, testing, auditing, is that it really forces you to understand how a control operates. Because when you start thinking about how to automate something, you have to make sure that you have a comprehensive understanding of what the business drivers and requirements are. So this is a very basic software engineering principle. You know, you, you need to have requirements, otherwise you don't know what you're really doing. And you know, the really important aspect of continuous assurance is that it's a forcing function for an IT organization. It forces you to go through an exercise where you look at a control, a very high level statement around your compliance and you break it down into how it's implemented. And each of those implementations have to be mapped to like specific assets in your IT environment. So if you're telling me that you have a vulnerability management program and you are doing vulnerability remediation, you have to understand the exact specific assets that those vulnerabilities could impact and how you're remediating them and that any auditor, regulator should care about it. Because without any sort of continuous testing approach, you're basically just operating on the concept of trust. I trust the evidence you collected is valid. So you know, I think that everyone can benefit from it. The challenge we face is that this forcing function requires a lot more effort on everyone's part up front. So we can do the proper data collection, data analysis, asset inventory mapping work, which IT organizations can really struggle with. But once you have that in place, it really can reduce a lot of toil down the road.
- [04:23]
B
I love that I think you've debunked that myth. But I'm going to hone in on what you just said about integration and bringing all that data into one place. And I'm actually going to pivot to Eric on this one. So is it better to have all of your data in one place so that you can use AI to capture those insights then or better to try to have it in a bunch of different places in different systems? I think we might know where we're going with this one.
- [04:49]
C
Well, if you can have all your data in one place and you can afford the cost, then I think it will make a lot of a training process much easier. But the reality is there are so much data on Internet is nearly impossible to get all data placed in one place. Right. So a very common approach is people call distributed access. That means data only flow into your training model when the data is needed, Right. Once data is used then we don't need to store that data anywhere. Another project I see is because sometimes people want to train large network model on the private data, right? Yeah. In some case, especially GRC policy data contracts or regulation, maybe the data size is manageable for that case I think they can centralize private data in centralized location. But still if they need get data from Internet like the lawyer attorneys memo or some online discussion, they'll just Feed the data when is needed. So I would say it's very good to have all data in one place, but not necessary.
- [06:00]
B
Not necessary. There you go. And probably like you mentioned, very expensive, very cumbersome. So yeah, always a good rule of thumb to only keep the data as long as you need it. Right. No longer than that. Awesome. Well, thank you both for debunking some of these myths. We always like to start that way, going through some of that stuff. But let's, let's dig in a little bit more. So Vikram, I'm going to come back to you for this one. You know, obviously Google, huge company, right. So you're probably not a one man show like some folks are. I know when I started in infosec it was me and like a couple of interns. Right. So can you go back in time and tell me a little bit about how your team got started down the path of continuous assurance and how you're approaching your automation there?
- [06:44]
A
Yeah, so I mean Google has always been a company that's very good at innovating in the field of it. Continuous assurance and continuous controls monitoring was actually in place at Google probably before I was even here, before Eric and I showed up. Probably the first efforts at continuous controls monitoring that happen in the industry occur in socks, for finance, for ERP based systems and things like that. There has been continuous controls monitoring and financial services. Google, a lot of I'm sure public companies are doing that. There were different efforts. Eric and I have been focused on doing this for cloud. Basically the internal responsibilities that cloud has to our customers. We are focused on the most critical areas and instrumenting continuous controls monitoring. We partner with a lot of really sophisticated engineering teams that are building testing platforms, data aggregation platforms, telemetry systems, and also partnering with us on different AI efforts. Again, our focus though is to handle continuous controls monitoring for gcp, the most important controls that our customers care about, that our regulators and auditors care about.
- [08:04]
B
Yeah, a lot of people rely on those controls too. So I think many of us are very happy that you're monitoring those so closely. But I want to go back then to kind of the first question we were talking about with the three lines of defense. So carrying on a little bit, can you walk me through an example of what continuous assurance might look like throughout those three lines of defense?
- [08:23]
A
Sure. I think a good example of this could be in an area even where some people feel you can't do continuous assurance. For example, you take an example like business continuity planning, that's typically a paper exercise that People think somebody has to write a Word document for get it signed off on, and then it's a manual review. We can look at it differently. We can look at it as perhaps this is a set of questions that are being posed to compliance stakeholders and control owners throughout the company anyway, for a variety of different reasons. And we collect all of that data into a centralized store through workflow automation. And then based on the data collected, we can generate a business continuity plan that's templated and it references more specific customizable recovery steps. Aspects of it are, you know, repeatable and generalized. And it allows you to have more specific details on a case by case basis, really an application by application basis. So you can have an automated workflow that basically generates your business continuity plan. And that workflow can then make sure that it's getting the right reviews on a biannual basis or annual basis, whatever your compliance requirements are. Now, what that does is it goes back to what we said earlier about understanding the coverage of a control. This process would mean that every system that requires a business continuity plan and every BCP plan owner has to be contacted within Google Cloud. You can imagine that is dozens upon dozens upon dozens of different product managers, general managers that have to do this. Now how does that work for a second line of defense or third line of defense, or even an auditor if you have the evidence generated in an automated manner? They don't know. They just know that you have a collection of business continuity plans. And if you tell them this was done in an automated manner, they may like that, they may not care. Just depends on their level of sophistication. But part of it is to make it seamless. You know, there's a part of continuous monitoring and assurance which is very much focused on the metrics, the control metrics and measuring metrics. And I think that's an area where auditors and regulators, obviously we don't have a standardized way of communicating the metrics, but we do have somewhat of an agreed upon way of sharing evidence and what kind of evidence is needed. And so you can make that automation work and you can just make it seamless to your second, third or external auditors and reviewers. So that's how we go about doing it.
- [11:07]
B
I like that they don't need to know how you got it as long as you have it right. Yeah, that's great there. And a great example, I think that a lot of people can relate to and I know kind of going back in time, thinking about how we used to approach BCP and things like that to now all of the advancements that you can do there. So thank you for that. And I'm going to pivot here to Eric for a moment because Vikram just talked about some of those controls and continuous monitoring. But with controls and risks and everything, everything changing so rapidly, I'm curious how you and the team have kept up and maybe if you've ever gone through the process of going through automating a control only to learn that it changed, right. Or now there's a new regulation, you have to go back and fix it. So can you tell me a little bit about that?
- [11:51]
C
Absolutely. I think manual control is still the foundation because you have to know how to do manually that you can automate. Right. To really pace with the sheer volume and speed of change. I think automation may have to be the go to master to do that because people have used that as efficiency booster. Then your second question is about what about I make a change and next day and notice any change Again, I think that require engineers to design system more modular, configurable and easily update to be able to accommodate new change. Some common technologies like API driven integration, microservice, you know, allow users allow suites to be able to do rapid adjustment when control change.
- [12:39]
B
Yeah, yeah, that's so key having that rapid adjustment and even you know, I, I kind if you think back too of, of technical controls, but even you know, some of your more administrative controls, policy changes, right. Being able to automate some of that and identify that stuff holistically is, is definitely going to be key. And I like the, the speed there. You got to remain agile.
- [13:00]
C
I can give an example as well.
- [13:01]
B
Yeah, please.
- [13:02]
C
We have some automation. We can monitor our policy change because policy is even worse. Right. Then we probably can scan every day to compare the delta. If the change is significant, we can trigger some alerts. In that way our developers or control owner know there's some change they need to pay attention to.
- [13:21]
B
Yeah, that's a really great example too. And I think even if we boil it down a little bit simpler, maybe you don't have, you know, smaller companies don't have the ability to scan every day. Right. But even just maybe it's monthly or you know, maybe once a month you review a policy so that by the end of the year, you know, you've kind of taken a look at all of them, but setting those reminders, setting those workflows so you don't, you know, forget and all of a sudden it's been two years and we haven't updated our acceptable use Policy or you know, something like that. So that's a really great point too and kind of carrying on from there. I'm interested in what maybe some of those best practices are then for maintaining that integrations. Right. Or some of that automation. And Vikram, you want to maybe touch on this a little bit on maintaining.
- [14:03]
A
Absolutely. So I mean, you know, to expand a little bit on what we said earlier, I mean the way, the way to think about continuous assurance is maybe a nice way to summarize it. It's controls as code. You're basically making sure that aspects of your code be your control. The assurance activity, the testing capabilities, the monitoring are amenable to automation. So I think what you really need to think through is a controls lifecycle process in your company. Part of that is developing SLAs and SLOs for control uptimes. I mean oftentimes we have compliance failures of control breaks. People are just running around in an organization going, oh, we have a compliance violation. Whereas server crash. That isn't what happens. There's a call, there is a triage team, there is a root cause analysis that's done. So taking some of those principles and applying them to controls, developing SLAs and SLOs and SLAs for control uptime, and even looking at how those controls are mapped to data sources and the pipelines that are needed to run data into those stores that Eric is talking about, you may need to develop internal SLOs for that. The last thing is that the control has to be again treated as code, which means you have to bring it into your normal IT processes and lifecycle, your change management, any sort of like software development life cycle processes can be applied to these controls. So there is a way to continually re reviews. An example, the earlier thing we were talking about, business continuity planning, the regulatory oversight. Right now maybe we just need to do this once per year. Now with DORA and increasing regulatory oversight coming in, that may change to do it every quarter, do it twice a year. At that point you have to now change your engineering requirements for how that control as code works. It has to run the review process more. You'll never catch that without having this control lifecycle process in place. Integrating controls into your SDLC process, basically if you can do that, then you can have continuous assurance. If you don't do that, you have the capability of continuous assurance, but you don't have the people driving the machinery.
- [16:28]
B
Interesting. I've actually never heard that explained in that way. But it makes a lot of sense if you think about it. The control Is, for lack of a better word, a system. It's a process that it's doing something and being able to maintain it, running through change management, making those adjustments. Even thinking about, you know, that was a great example. But even thinking about like password requirements. Right. At some point, you know, you probably hard coded in your system that passwords had to be 10 characters. Well, maybe tomorrow they have to be 12. How do you go back and adjust that?
- [17:01]
A
No humans should be accessing the systems.
- [17:05]
B
Exactly.
- [17:06]
A
Agents or automation and you know, different ways of like pushing changes that don't require. Yeah, yeah.
- [17:13]
B
And I think. Yeah, absolutely. And you know, I think it's just very interesting too, that really taking that CICD approach of that iterative nature to it, because they're never really going to be perfect and then treating them as almost like an incident. Right. A control failure is something that should be acted upon and treated in that way and assessed and lessons learned. And yeah, really applying those negative.
- [17:35]
A
Think about it. A compliance failure can get you blocked out of an entire regulatory market. And it could be a simple process breakdown.
- [17:43]
B
Yeah.
- [17:43]
A
Oh, yeah. That is something that, you know, like, it could be. It could be a lack of notification and communication to the regulator. Why can't that be codified as an internal SLA for the company to adhere to? And why can't that be treated as code? It's a matter of distributing notifications. Plenty of technology just to do that. So. Yeah.
- [18:03]
B
Oh, yeah, absolutely. Yeah. And then the flip side of that. Right. Is then using even that, like regulatory compliance almost as a revenue generator too, because that's what it is as well. Like you unlocked a whole new market by maintaining that. What you're saying, you know, flip side is you now blocked yourself from accessing that entire market by not, you know, complying and having your controls in line. That's a really, really great perspective. Thank you, Vikram, for sharing and elaborating there. I like that pivoting back to you, Eric, though, because previously you were talking, you know, you seem very comfortable obviously talking about using the AI and automation. Certainly not the case with many. You know, you two have had really great perspectives there. So how can, you know, the folks at home, you know, our auditors, other GRC folks, you know, how can they get a little more comfortable using it? Any quick wins or ways that you can see people getting involved?
- [18:55]
C
Yeah, I work with a lot of GRC folks and also business people. I noticed they're very comfortable with their own process. But when they start to use AI tools, they probably, I would say first they may have some doubts whether the tool can solve the problem. Right. I would say always start small, try very small use case. For example, upload your regulation into some AI agents, let them do some text summarization, ask some questions to figure out some insights and then start to build your confidence of using this tool. Because those tool can give you way more quicker feedback compared to people doing the work. Right. Like for a person to read a 500 page PDF I don't know, it would take days. But a machine take like 10 seconds. That doesn't mean machine can always do a better job than human beings. Because all this is already singular from AI is really help people to be able allow them focus on harder problems. So I would start small and gain confidence will be my advice. Another thing is I think nowadays we have so many AI agents you can use, right? Like Google ChatGPT maybe try some of the tool to solve a step in the process. Don't think about I need to overhaul my entire process using AI first because it could be very expensive. Right. Or there are many steps in the process, but maybe just one or two have the highest value. So focus on those high profile step in the process. Try AI and then to see what they get.
- [20:37]
B
Nice, nice. Yeah. Baby steps, right? And I think that's where a lot of folks end up failing when they go, whether it's AI or emerging technology is, you know, they try to take too big of a bite out of it, they try to make too big of it. And so I like what you said there, breaking it down into those smaller chunks, tackling things in that manner, definitely a lot more, more feasible for folks. So. Well. Awesome. Well that brings us to the end of our episode today. So as we wrap up we want to talk about some strategies for success. So we'll start with you Eric and then I'll turn to you Vikram. What is your best advice for companies that are trying to manage their control automation at different levels across the lines of defense, maybe different department, things like that.
- [21:24]
C
Yeah, I would say the best advice is the one probably many people have regressed on is because when we design all this control monitoring system, we need to design this in a very early manner. We need to ship to the right most if we can. Otherwise once you already have existing system in place in the play, it's pretty hard to really have a unified framework, ensure everything down correctly. So that will be my advice.
- [21:52]
B
Nice. So it's like automation by design, right? Like you have to start from the first hey place and have that baked in I like that, Vikram.
- [22:01]
A
Yeah, I would build on the automation by design concept. It's controls as code. You know, think about how you can treat your controls as actual software. Don't let the fact that some of them may be process or governance related slow you down from thinking that way. Workflows are easy to automate and I think it's also important to step back and look at that control life cycle. You can build these capabilities and you can have a GRC system. Logic 8 has a wonderful GRC system. The companies that know how to implement it and really get the right data in there are the ones who are going to benefit the most for it. I think it's about treating this like it's a very serious software development program. Treat those controls as code and think about the overall lifecycle and how to plug those controls into them. Because if you have a really robust process, we certainly run into problems at Google where it's the scale of what we're doing, but I don't think there is a high level of technical complexity in solving some of these problems. I think it's a matter of bringing things that have normally been orphaned from normal IT processes and software development principles and just bringing it in house to that.
- [23:12]
B
Yeah, that's great advice, great advice. And I'm going to build on top of that. Take what you guys said and I'm just going to remind everyone, my advice would be make sure you have all the right stakeholders at the table, making sure that the right people are involved in having these conversations. Because the worst thing would be to go down this path, automate that control and then find out, like you said, it's the wrong piece of the puzzle or there's a bigger picture happening and now you have to go back and change that. So keeping everybody involved, talking to the right people, transpar is definitely key here. So you've heard what we've had to say. Now we want to hear what your comments are. So in the comments below, tell us what is your best advice for companies managing control automation at the various levels. Thanks everyone. Thank everyone for listening and thank you Vikram and Eric for joining me. From controls as code to security by design, automation is in everyone's future. Thanks for joining us and see you next time on GRC and me.