Daniel: Good morning, everybody. Welcome. You are now engaged in the integrated security approach and enabled by IRM and SecOps hosted by KPMG. My name is Daniel Gardner.
Essa: I'm Essa Farooq.
Daniel: Quick introduction for me. I am a director at KPMG, been with the firm for about eight years now within the cyber defense and cyber practice group, concentrating mostly on security operations, security operation centers, and log-in monitoring, which also includes vulnerability response and voluntarily management.
Essa: My name is Essa Farooq. I'm a director with KPMG. Specifically in our cyber security practice, I have been helping our clients help their overall program and vision and strategy, as it relates to their integrated risk management programs. I do so by putting them in working sessions and dialogs toward helping them define their process and technical designs, leading full-scale implementations, and then essentially the overall learning and adoption of those implementations by their end user.
Essa: So excited to be here and excited to be talking to you guys with our integrated approach to IRM and security operations, as it relates to our clients. So what we're going to be discussing with you today is giving you guys an overall view or overall background of our client. What were the key drivers for their change?
Essa: You know, essentially why they started their transformation journey, why they leverage ServiceNow to drive that change. We're going to talk about the governance and the underlying integrated architecture that was deployed to help them achieve their vision and achieve their implementation. We're going to talk about the charted path that we took on our journey, so the transformation journey that we undertook.
Essa: Talk about the path where we started first, where we landed, and what's on their future roadmap. And then just some key takeaways. You know, as you guys are sitting here in the audience, you know, you guys are leaders and professionals within your organizations. This is a key topic amongst all of you all. So just some key takeaways and considerations for you all as you walk away from this presentation.
Daniel: It's about our clients. So we'll get into the case study. Our client is an energy sector client. We have basically all of the, all the particulars get regarding the client here, relatively large client publicly owned not-for-profit service provider. All of these numbers are basically describing our case study and basically describing the client. But I think the biggest key takeaway is probably the problem area or the problem statement with this org, which is likely the problem, say, with a lot of organizations, which is visibility.
Daniel: The biggest challenge that they had with their, you know, just general visibility is both on the vulnerability side where they had vulnerabilities. They had a vulnerability scanner. They had actually multiple vulnerability scanners, but they didn't really have a good, good view of what the threat was or how the threats compiled upon each other as these vulnerabilities would enumerate.
Daniel: And then same goes for the, you know, for the risk management side. So we're transitioning from one platform to another and then trying to find those blind spots within that transition and then getting over to where it's now much more of a unified situation to where the vulnerabilities and threats have some visibility. And then also with the policies and compliance that that IRM held our holds up to how that's all contained in version two and two together into a much more of a holistic view.
Essa: Anything to add to that, Daniel? Yeah. You mentioned inefficiencies and there's like ops process inefficiencies and not accounting for all the vulnerabilities security incident that they were capturing. You know, to compliment that piece, we learned that there were a lot of manual antiquated processes and spreadsheets and SharePoint sites, you know, things I'm sure you guys can relate to as you're listening to this, where not everything is in a consolidated central space.
Essa: Now your reporting suffers from that, your decision-making suffers from that. So we wanted to help our client consolidate a lot of their key data sources into ServiceNow, such as policy management, such as compliance management, issues management, etc., along with the suck up suite. So consolidating all that vital information, so that they can make key decisions at the leadership level.
Daniel: So let's talk about some of the key drivers that they had along with problem statement that was what was described here.
Essa: Yeah, absolutely. So I mentioned, you know, they were using a lot of legacy tools they had an antiquated GRC system. They wanted to move to service and they were already using it for ITSM, but they wanted to use it now for IRM setups. So firstly, they wanted to improve the efficiencies and standardizing that policy lifecycle management. So taking a policy all the way from draft all the way to published, they had a lot of policies, a lot of PCI policies, vulnerability policies that were sitting in SharePoint.
Essa: They wanted to move those over into a ServiceNow platform and manage those with the proper audit trails behind them, notifications and workflows. They were also doing some components of cyber audit testing. So not necessarily third-line audit, but more so cyber audit testing, such that it gives them an informed information around that. The controls that are in place against their cyber program and having visibility into those similar to their policy program.
Essa: A lot of their controls were sitting in spreadsheets, sitting in different sources where they could not make the best use of that data and make information-based decisions off of those. They also wanted to group their assets so ServiceNow uses that Jersey profiling sort of use case to group assets in the same DB, whether their IT business to be able to then apply your controls and risk frameworks, too.
Essa: That was something that was lacking. So there wasn't a rationalization or common controls library that they had. So they were doing a compliance for the sake of compliance. Right. Redundancy and testing where they couldn't say, you know, based off of testing one control, we're crossing off all these different regulations. So we help them achieve that through the use of an integration with missed RMS indicative.
Essa: In this case, in addition, integrated risk assessments that not only inform what's the IT Risk posture, but also what are the vulnerable items that are coming to the organization and how do they then feed into the risk register from the various risk assessments that are taking place.
Daniel: So with that, we continue on with, you know, it almost gets to a graduated scale, as we get to these numbers here. Now we're getting to wanting to create an end-to-end capability to where not only are they seeing the vulnerabilities from the from the discovery side, but they're also seeing how they handle within, you know, how it works within, you know, remediation, how do we deal with exceptions and how do we do a false positive?
Daniel: Now, a key one here is exceptions. Where that can actually dovetail into compliance policy and compliance reporting and a lot of awareness that has to happen to where something that is not remedial needed at an immediate time or within an SLA. You know, what do we we need to do something about that. There has to be a report that includes and helps with that.
Daniel: So dovetails into consistency with compliance and self-reporting. A lot of the frameworks that were built in to where we talked about in step two, step three, enhancing those two where now it's a workflow, now it's now it's repeatable, now it's consistent. So we have that built and engineered in that as well. And then my favorite, there's always the improvement of the CMDB.
Daniel: So we'll go into another slide where we talk a little bit about the architecture, which is basically my favorite slide. But within the improvement of the CMDB, you have two feeds where the IRM entities and all of the data is coming from, you know, from the GRC side of the house. And then you also you have the discovery side where not only do you talk about vulnerability management, vulnerability scanning, but you also talk about the rest of your security tools when it comes to discovery and monitoring.
Daniel: So a lot of that enhancement helps with the CMDB and getting better, better data and better affiliation to, you know, what you're looking at and what you're defending against. And then finally, the integration which we talked about a little bit, again, we'll go into that within the architecture, view the the VR tools, and then the data relationships that go into IRM to where you have the vulnerability.
Daniel: But, you know, within the enumeration of vulnerabilities or the threats they're in, you know, how does that relay into the risk management profile.
Essa: So when you have a mandate by an organization to transform your integrated risk management program, that cannot begin without first setting a program vision you know, why are we doing this? And as time passes, are we still doing it for the right reasons? Right. So establishing a program vision is key. That program vision has to be supported by proper governance and a set of guiding principles that make sure that as new functional teams onboard the platform, as additional regulatory changes come forth, business needs change.
Essa: As you design and scale the platform and the Integrated Risk Management Program, you're doing so in such a way that it sustainable over time. You know, governance is a key buzzword that gets thrown around a lot of days. But, but what does that actually mean, right? Governance for our client meant that having the right executive sponsorship and meant having the budget and resource allocation prioritized for this initiative.
Essa: And everybody speaking the same language. I think this would resonate with a lot of you in the audience, which is at your organizations, you know, terms like risks, terms like issues can get conflated, right? You can refer to a risk as an issue. An issue as a risk, and that definition isn't clearly known. So you're speaking different languages your skills are off, you're measuring things and perhaps different ways across different functional units.
Essa: And that is key in program governance, right? You have to be able to have the data measured and quantified in a consistent way, so that your reports clearly articulate what your risk posture is, what your compliance posture is, so that you're making the right decisions for your organization. So think of guiding principles, you know, lending itself from the program, vision-guiding principles.
Essa: Think of them as, you know, bumper rails that are bowling alley, right? They protect the organization for kind of coming off course specifically when it comes to setting up an IRM program. So for our client, the key guiding principles were firstly focusing on efficiency what does that mean? Focusing on efficiency for our client meant, you know, leveraging out of the box principals as much as possible or near the box principle as much as possible.
Essa: You want to tailor the platform to some degree for your own requirements, but you don't want to alter the out-of-the-box workflows. ServiceNow is such a great platform. It has such sort of robust workflow capabilities, notification capabilities. We want to make sure that we're adhering and leveraging that as much as possible to avoid customization and preventing ourselves from downstream down the line platform upgrades that come that may prevent us from, you know, reaping the benefits of what ServiceNow brings and things like Tokyo and other future releases.
Essa: So focusing on efficiency, it's then executed by our planning and delivery. So agility in planning and delivery and that means that while there's going to be so much excitement in using a new tool, all these teams are going to be interested in getting all their requirements, and getting essentially stood up from day one, so they can they can perform business as usual activities, agility in planning for our client meant like, hey, let's focus on the minimum viable product. What do we need to get going on day one?
Essa: And then how do we nurture that and enhance that over time? So that means we capture our requirements, but then we prioritize them and groom our product backlog, so that we're agile in our planning and agile on delivery. And that delivery is supported by active participation in change that means for our client keeping an open mind, right? They sought out KPMG as advisers to guide them towards industry leading practices what we, Daniel and myself, have seen over multiple implementations on how to stand up our own programs.
Essa: We guided them like, Hey, let's keep an open mind your processes today. Yeah, they're, they're, they're doing well, but there's some redundancies here. There's some efficiencies that we can gain, and we infused our accelerators and our perspectives from KPMG to guide them towards a newer way of thinking. And kudos to them, right? They kept an open mind. They were proactive in the change that they wanted to see.
Essa: So there was a lot of collaboration amongst the different functionalities from the SEC up size and the GRC side. To make sure that whatever change they were undergoing was perceived as a positive change can oftentimes be threatening or can be seen as a negative. They did a great job in keeping an open mind and being flexible in their thinking.
Daniel: It's a fun thing about this client here is that our meetings tended to get larger and larger and larger within the engagement because of that active participation, because there was, you know, once people started understanding that the requirements were being mapped in, you know, they started getting skin in the game. So you know, when we get into, you know, all of our all of our big zoom calls or just, you know, 20 or so folks.
Daniel: But it's really, you know, we actually also have the kind of tamper downs where it's like, OK, all the tech guys, we'll talk to you later. All of the all the main stakeholders will get back.
Essa: That's, that's a good problem to have, right? Like oftentimes and I'm sure you guys, when you get on your work meetings, there's just you can hear a pin drop. You know, there's not a lot of perspectives, not a lot of viewpoints. And in a program like this, such a change that that's the organizations that are going to have that many people excited and wanting to give their input.
Essa: You know, that's, that's a blessing. It's a good problem to have. So from change, you know, change is much easier to digest when there is intuitiveness and simplicity in whatever you're trying to implement. ServiceNow is great in that it's already intuitive to begin with. So as you implement your workflows, as you implement your processes, you want to make sure that you want to minimize clicks.
Essa: You want to make sure that you're not jumping from screen to screen. So simplicity in your design and intuitiveness in your design is a key driver of that change. If you keep the business user always in mind, like, hey, if they were to walk into service now or or executing a process in ServiceNow, how much guidance would they need?
Essa: An answer should be minimal to none end users should be able to come in, see what work needs to be done, complete the work, and get out. And then lastly, you know, efficiency is great. Agility and planning is great. Change management is great, the simple design is great. But ultimately, none of that matters if you don't have people that are accountable for the work that they're responsible for completing.
Essa: And this was enacted upon by Dan and myself by enhancing there seem to be collecting the key attributes that are necessary to be able to comply risk framework or to assign risk frameworks to design control frameworks to and from a vulnerability side. I'm sure you have a similar story, right?
Daniel: Yeah, items, items and groups and groups to, to well now, now they're remediation towns. Yep. But yeah, no, it gets very real when we start looking at groups and users and roles to where once they start identifying that I'm in this group and this ownership to where, you know, the logical groups that are within the ServiceNow ecosystem now it turns into the real deal to where, yes, you are on the clock to either figure out if this is a false positive or something to remediate within your remediation groups or, you know, within the policy side with the compliance side, you know, who that's assigned to.
Daniel: So it gets really real after step five.
Essa: Yeah. And that's a big thing, right? A lot of there seem to be assets lack ownership. How can you drive accountability if people they don't know that they own something, right? So the first thing we did was like, hey, let's try and get as much ownership behind the key assets, behind the key risks, policies, vulnerable items, et cetera, so that accountability is achieved.
Essa: You're meeting your SLAs, you're meeting your deadlines that you need to meet. So accountability was their last and perhaps most important principle within their hiring program.
Daniel: So we get to my favorite slide. This is usually, again, for the engineers and for the architects. This is where it all kind of comes together, so in regards to the managed architecture, I again, I can boil this down. We can take another 30 minutes to just knock this out as far as this one slide. But we'll keep it very simple on common to where it comes from to it, you know, it can come, it comes from the IRM side to where all of the entities and activities that are done within that, within that those modules and those applications, as well to where it starts enhancing things from the get go.
Daniel: Again, if it starts, you know, from a manual process or from an automated process of bringing in data for that, you know, that's actually a good starting point to where, you know, bringing in that enrichment data from IRM gets you to a good start to where you can start feeling that and seeing that connection between security operations in IRM.
Daniel: Now, on the other side, it's the third-party side. Again, as we mentioned before, the driver within our client was multiple vulnerability scanners, not just one, but multiple scanners, agent, and agent with multiple environments. You know, cloud on prem, all of it. So a lot of that driver to bring in that vulnerability data was mainly from the vulnerability scanners.
Daniel: But again, you know, the the manual incidents, the detection tools that still have all of their vulnerability data and also have asset data, whether it's part of the the CMDB, whether resolved to a CI or if it becomes an unresolved or unmatched CI, that information definitely comes in from the scanner as well with the attributes. IP’s Max, all that good stuff to where you're starting to get a more and more of a build inside of VR to where now you start enumerating the risk.
Daniel: I have X amount of items within VR that grouped into one single item because it's one asset that's involved. Well, what is that you know, you know, what type of compliance is this? Is this asset involved in is this part of an environment, that is, you know, SOX is a part of PCI is what is it? So that's where that connectivity really really starts getting, you know, getting great ingrained into the whole process where you're seeing related items and related records inside of VR and you're seeing that inside of your IRM stating that, well, we might have some issues here, too, where it has to be something that needs to be resolved sooner rather than later because of its, you know, high compliance or high visibility.
Essa: Yeah, I think the word integrated, right? Like for me, I'm a visual learner. I'm sure many of you guys are too. Like when I hear the word integrated and I think of IRMS, Sic Ops, those two worlds colliding into one. Sure, you can explain it to me conceptually and I'll get it. But I think an illustration like this really helps emphasize and visualize what exactly that means.
Essa: So you'll notice that Daniel was speaking to a lot of the sic ops modules in the middle of the screen, but then right over to the right, you've got ServiceNow IRM right. And that speaks to the fact that whatever vulnerable items exist, whatever security incidents exist against particular IT assets, ultimately they're measured against what controls are mapped to IT assets or business assets.
Essa: What risks are present and how they're constantly being assessed and mitigated over time to reduce the overall exposure to organization? So I think something like this really helps bring that integrated message home that oftentimes can get lost just by speaking to it happen. Having a visual like this really, really helps in developing that understanding, yeah.
Daniel: And if we want to get into any more additional details, we have a booth in the Expo Hall, so we can get into that much more in detail.
Essa: So our transformation journey, right, we talked about we helped our client firstly develop overall program vision. We put forth a set of guiding principles we establish their governance model. And then from there we said, All right, let's get to work. And that work began with firstly developing an implementation roadmap and this is essentially an executive summary type view of that implementation roadmap.
Essa: And what that did for our client was help them prioritize the capabilities that are firstly most important. What are the like the minimal viable capabilities? We need to have stood up on day one to complete our most critical business activities. It began with the implementation roadmap. We divided it up across in 18-month flow, 0 to 6 months, 7 to 12, and then 12 onwards.
Essa: Following the implementation roadmap, we then set up policy management and compliance management. So standing up the policy lifecycle, being able to take a, let's say, a vulnerability response policy all the way from draft, all the way to finish publish that on the knowledge base, so that your end user can retrieve it. As I mentioned previously, it was in Excel, it was in Word documents; it was in the SharePoint.
Essa: People weren't even aware what policies existed in the organization or where to get them. It was sort of common knowledge among the second line or the functional teams that were working with. But beyond that, the first line had no sort of larger visibility into where those policies sat. So standing up policy management was step two, along with compliance management, standing up a foundational self-assessment capability against particular controls at the first lines responsible for and then setting up some basic indicators that automate and reduce the manpower that's needed to do that day-to-day testing.
Essa: So quality management, compliance management, followed by risk management and issues management. So standing up a foundational risk assessment lifecycle, taking a risk against that particular asset, taking it all the way from assess to monitor and doing that continuous monitoring, that's essential. And then again, automating and using the ServiceNow platform to reduce a lot of the perhaps inefficiencies or manual work that’s, that is existing today for our clients.
Daniel: Now what stop for it's a, it's good that we have stop for as in where vulnerability response lies mainly because of the dependency within policy and compliance management the connectivity between vulnerabilities that are discovered and then the review and the research of exceptions that's where it becomes very, very important that policy and compliance is installed in tandem with VR.
Daniel: So whenever those exceptions do get reported, there is a straight path, inline path to create that exception, create an exception record and point it directly to policy and compliance for review and for continued monitoring. Now, there is definitely a time cap on those things. So you know that that's where the SLAs and the time sensitivity with each of those record—the exception record and the vulnerability record really comes into play.
Daniel: And again, you know, within the vision. Yeah, that's where all of that activity is built out. So in regards to the dashboards and reports, so again, visibility was the massive problem statement that we had to solve for. So within the enumeration of vulnerabilities from multiple scanners and then all of the reporting that needed to happen in regards to sending them off to the right teams at the right time, and then the SLA is that we're impacted by that activity.
Daniel: That's where those dashboards need to be built on that vulnerability response and right there. So, you know, executive reports when it comes to scheduled reports, you know, anything that needs to be automated and automated at a, at a cadence or any sort of specific timeframes, that's where that was built in along with, you know, kind of the tailwind for the rest of IRM to include the vulnerability data within those report.
Essa: Yeah. I want to come back to step three. And, you know, if you look at it, it's position relative to the roadmap it's right in the middle. It's after policy and compliance management, but before a vulnerability response and security incident response. And the reason we prioritize this this way with the client was because we talked about earlier how risk and issues can be interchangeable or confused within organizations.
Essa: You know, Daniel, you and I, we were, I think, were on a workshop when you asked them like how would you define an issue or how would you define a risk? And there were competing answers where one person was saying, oh, everything is a, everything is a risk versus not having a clear definition of an issue is something that happened.
Essa: Risk is something that could happen. And how you treat both of those things differs risk treatment differs from issues management, sort of closure remediation. And what we did in step three was essentially make those two processes distinct in the organization, which did not exist when we first arrived there. So essentially enabling the treatment of risk through mitigation activities, transferring to an insurance policy, if that exists, risk acceptance, which is different from policy exception, which is necessary as well.
Essa: So, you know, essentially creating the distinction between those two processes and then standing up issues management, so that if something has occurred, a deficiency in your control is present, a event has occurred, how do you remediate or how do you create an exception for it if you don't have the means to fix it at the at the time being?
Essa: So I think that's an important thing to call out just as sort of a middle piece that glues everything together.
Daniel: So as far as six, seven, and eight those are much more on the you know, it straddles that expansion and the operationalization and optimization as well because, you know, within our client they valued, and they prioritize vulnerability management, vulnerability response prior to security, incident response, no wrong answers, you know, the teams can, you know, organizations can prioritize whichever one that they'd like in this, in this case study.
Daniel: However, the exceptions and the risk and the issues that were all consolidated within the reporting, within vulnerability response was prioritized. So within the expansion, SIR would finally have that connective tissue with VR to where instead of having the regular cadence of vulnerability management, you can literally hit a panic button and start on your incident response activity. If the finding was so intense now in regards to the order management, that was another extended portion to where the previous modules and the previous applications were included beforehand.
Essa: Yeah, absolutely. So, you know, audit management is something that they're striving towards. They do some capacity of cyber audit testing. However, it's not pure third line they were using another platform by the time we got there. However, just due to the success of our implementation and the way we charted the path for them, they're strongly considering not only integrating the two platforms, but also a slow transition over into service altogether to have again, all that data in a centralized location.
Daniel: So the resiliency part is definitely much more on the optimization. And we're taking in all of the data from all the applications and all of the modules themselves and building any sort of a business impact and disaster recovery to where now we've got it all standardized with all of the information unified and telling us exactly what we need to know the other additional steps.
Daniel: So as well with the crisis management, again, more of an extension of what happens within seconds, but still dovetails nicely into what we need to report within risk, especially after action and lessons learned within that activity. And then the automation countermeasures, definitely a big feature within seconds too, where we're now automating responses and tasks where we're taking care of the countermeasures from the, from a, you know, a task perspective where that's already being done by tools and platforms that should be doing it anyway.
Daniel: You know, you should be blocking sites that are malicious. You should be, you know, cleaning things up that are low commodity level malware so and then also, you know, that VR component to where, hey, we should be patching this, we're already scheduled to patch this. This vulnerability should be patched, you know, and in that certain cadence.
Essa: Yep. So, you know, what are some key takeaways that Daniel and I can can give you guys as you walk away from our session? You know, firstly, you know, there has to be agreement with your client or even within your organization that what we're about to undertake a transformation journey of our IRM program has to begin with an agreed-upon vision.
Essa: As I mentioned earlier in the session, you know, that vision has to endure time as regulatory changes are presented as business needs change. That program vision should be scalable, so that accommodates all your needs over time. So having that vision in place, having agility and in your planning and your delivery, that's then stood up by a set of guiding principles and the proper governance.
Daniel: And then finally, you know, as we saw within the roadmap and within all of the discussions here, it's going to be a phased approach. There's, you know, Rome cannot be built in a day with these two components. It has to be definitely taken into account prioritization and, you know, what is the more pressing thing and what is the driver for, you know, for your client or for the client that's involved?
Daniel: And then, you know, going through to where there is definitely going to be a first release, a foundational release to where things are stood up and then moving towards operationalization. And then the optimization continues to where you're adding enhancements you're adding more data, you're adding possibly another additional third-party tools and reports. So all of that does definitely compile into, you know, you got to take it step by step.
Essa: So, so on behalf of KPMG, I'm Essa.
Daniel: I'm Daniel.
Essa: If you want, you know, we're going to be at our KPMG booth. We welcome all questions. Love to see you guys as faces come by. Thank you for your time. Thank you for your attention and have a good rest of the day.
