EPISODE SUMMARY
Subscribe or listen now: 
Joseph Carson:
Hello everyone. Welcome back to another episode of the 401 Access Denied Podcast. I'm the host of the episode, Joe Carson, Chief Security Scientist and Advisory CISO at Delinea. And it's a pleasure to be here with you, always looking to bring the latest trends, news, information to really provide you the information you need to make the right decisions in your cybersecurity strategy. And this topic is very important. Sometimes it's not always the funnest topic, but it's one of the most important topics and it is starting to get a bit more fun. I do think we're bringing the fun back into this specific area. I have an awesome guest to really bring in a lot of the details and thought leadership and ideas related to this. So Steve, welcome to the episode if you want to give us an introduction of who you are, what you do, and some fun things about yourself.
Steve Ursillo:
Thanks, Joe. Pleasure to be here. I really appreciate being on the show. Yeah, I have to agree that this stuff is definitely getting more and more fun as things evolve. With that, yeah, I'm a partner with Cherry Bekaert in the Risk Accounting and Advisory Service group, and I lead the Information Assurance & Cybersecurity team, so we get responsible for an array of different service offerings. A lot of what we're going to talk about here today predicated on third party risk management, information cybersecurity, privacy risk management, and governance, things along those lines. A lot of the, what we'll call alphabet soup, but the different types of certifications and attestations on third party criteria that's out there. Our team also gets involved in doing a tremendous amount of cyber advisory work, so helping management and key stakeholders identify and execute on their cyber governance and privacy risk management initiatives. And that's all the way down from policy, procedure, design, risk management, execution, to the technical aspects of what we would be helping with as well.
So helping them with their system architectures, helping them with their vulnerability and risk management programs, attack and penetration testing, configuration assessments, secure architecture design and deployments for Cloud services, things along those lines. We also get involved in doing the combination of people, process, and technology to help in a managed capacity. So virtual CISO, helping with their incident response programs, and a lot of other security awareness trainings and other things that go along with the governance programs that we have. We like to say that we're the perform as a center of excellence to support the rest of the firm, so we perform services to provide backup and or support for our accounting teams, our assurance teams, financial assurance teams, transaction advisory teams, our digital transformation teams, so on and so forth. So pretty comprehensive.
A little bit about myself. Started out in the financial reporting space, I am a CPA. Early in my career I identified a passion for cybersecurity and risk, and ultimately that evolved, had a deep penetration, and was active pen tester on the network and web application side, and that passion still exists today, so fundamentally, that was kind of the foundation that drove me to understanding and driving back a lot of the risk that we look at and how to best mitigate and protect against those circumstances. And that's kind of evolved as we're going to talk about here between your cybersecurity program in addition to your cybersecurity compliance initiatives.
Joseph Carson:
Fantastic. And absolutely, for me, I think it's really important, you have those combinations, very few people actually had the knowledge of both the CPA side of things and the cybersecurity and bringing those both together is very, very critical important. One of the things is as we've going down this theme of compliance and regulatory side of things and all of the needs and certifications and audits and so forth, one of the things that as we start off going down that path, what is compliance intent? What is the purpose of compliance? What is it for, typically, and what is it not for, as well. As we go down this, many organizations are always thinking about, "Oh, we need to do it." But what should be the goals? What should be the intentions for doing compliance?
Steve Ursillo:
So I think it's a great point and it's one that often requires some unpacking, and I think as cyber attacks are increasing and they evolve, there's a dynamic risk landscape that we have to navigate and that traverses through the organization. That coupled with the security breaches that are out there, and the media has definitely gained the attraction of a lot of business owners, key stakeholders, regulatory groups, things of that nature, which is downstream forcing a little bit more or a lot more, I should say, transparency in how organizations operate. So what you're finding is that you get this perfect storm of not only the awareness of what's going on, the changing nature of technology, the changing nature of the risks, and the need for these organizations to demonstrate their fiduciary compliance and overall expectations and controls to third parties and their leadership in order to make sure things are safeguarded.
So when we talk about cybersecurity, cybersecurity is broader than cyber compliance, right? It's really something that most organizations are navigating based on their risk tolerance and the overall, again, threat landscape. And they're designing the right adequate controls in order to best mitigate risks to what they feel would be residually acceptable. And those can drive down very technical components. They can go all the way down. And obviously this is comprehensive to compliance as well, but organizations may be looking at the kill chain and the attack frameworks that are out there. They may be looking at the Mitre framework and basically trying to design the best systems to identify, protect, detect, respond, and recover through different elements of that progression. So you're going to see the use of systems that are more mature with organizations that are trying to really evolve and adaptive security program, and you're going to see organizations that are stepping in the right direction, but a little bit slower on the tail in order to get there.
So, typically cybersecurity is something that's more comprehensive across the board. Cyber compliance, while it is part of cybersecurity and follows many of the best practices you'd expect, it's typically driven on regulatory and contractual obligations. So organizations are inherently depending on where they operate, when industries they're operate, they have to adhere to contractual obligations, especially if they're service providers providing these types of services to third parties, Cloud providers, things like that. And then they also obviously have to deal with the regulatory implications depending on where they operate. So if they're utilizing and or processing store process or transmitting certain types of data, then these different regulatory requirements are going to fall upon them, such as obviously PCI, if they're dealing with a cardholder data or they're dealing with health information, Hipaa, so on and so forth. And we'll talk to some of those in a little bit. But I think that's an important differentiator.
In many cases, you don't want to devise your overall cybersecurity program just based on compliance. Compliance is a factor. It's very important to adhere to, but it's probably the minimum baseline that you would want to adhere to in order to meet regulatory and legal obligations. But if you're truly trying to defend against the modern day evolving attacks, you're going to take a more proactive risk management approach entity wide and try to look at things on a broader scale. And keep in mind too that some of these frameworks are very prescriptive and costly, time, energy, effort, human capital, finance, everything. So when it comes down to certain elements of these particular requirements, organizations look to segment and or isolate the different types of data sets in order to control their compliance costs. So once again, there's strategies here that are driven based on the need of the organization.
Joseph Carson:
Fantastic. That's really interesting. For me, it is probably compliance should be part of your overall cybersecurity strategy rather than cybersecurity shouldn't be just there to be part of the compliance portion. It should be basically as part of that broader strategy for the organization. So when you go down this, if I'm an organization, how should I prioritize or what goals should I try to set myself? How would I go around if I did have some type of compliance that I need to do, let's say it was a PCI compliance or a SOC compliance, what would be the prioritization? How should I approach it?
Steve Ursillo:
So I think when you take a step back and you look at the goals for compliance, you're looking at a few things, right? You're really looking at one, what are the legal and regulatory requirements that you need to adhere to? So identifying just like cybersecurity initiatives where you're identifying your assets, you're understanding the type of data you have, the systems you have, how you interact with third party, so on and so forth. And you need to know the legal requirements as far as how you're dealing with the supply chain system and all how you're dealing with third parties, contractual obligations that you have on vendors and customers. And of course the type of data that you have is going to really prescribe the nature and way in which you have to handle that data in certain elements of the business. Then you're going to design, basically you're going to look at the data protection mechanisms that you're going to find in order to best safeguard that you're going to establish your risk management program.
You're really looking to make sure that you're taking into account all your inherent risk factors, but you're looking into other elements in your risk assessment process to define the right controls, make sure that they're complete based on the criteria or the regulatory requirements. And then you're designing the controls and the execution of the controls in order to best mitigate, to get to a residual risk level that you can tolerate and that's acceptable. And this is an ongoing process. So that part of the program, very similar to cybersecurity, you're going to drive your risk assessment process that's going to drive how you're going to act and how much you're going to spend in the way of resources.
You're really looking at doing this to gain consumer trust, protect your reputation, protect your brand. But because it's so inclusive, and it's in many cases, depending on the organization and who they provide services to, it can be very time consuming and establishing the right mechanisms for the efficiency patterns that you may have, both internally as well as externally in how you're dealing with your auditors becomes very important and conceive an organization a lot of time, energy, and effort, really focus their efforts.
So making sure you have a good clear path, making sure you develop and design systems that you can operationalize very effectively and efficiently across these requirements. And these are dynamically changing. If your organization is obviously a global organization, making sure that you design the program scalable, that you can deal with any data sovereignty issues or any type of segmentation that's needed in order to protect data in different geographical areas. I think that's really important. So in other words, this is a moving target. It's not set and forget you have to have the strategy, but you got to bring back everything you need in order to properly execute on that program.
Joseph Carson:
Sounds more like it's a cyber quality assurance that your organization is showing that you've set a certain level of standard.
Steve Ursillo:
Yeah, I think to your point, it's really important from not only a legal obligation perspective, but it can potentially drive competitive advantage. Most organizations are going to have ethical and fiduciary requirements to safeguard and protect that data. So obviously it's going to keep you in line with what you need to do to continue to have the reputation you want to have in the services that you deliver.
Joseph Carson:
Fantastic. And there's so many out there, there's lots of different compliances. What are some of the most common that organizations would tend to have to meet and maybe what are some of the slight differences between them? I think when you see, as you mentioned, there's lot of spaghetti soup out there, there's a lot of acronyms, a lot of buzzwords, but what's some of the most common that you tend to cross?
Steve Ursillo:
I got to think there's literally hundreds of these globally, right? So yeah, I think we spend a lot of time in certain ones, but obviously if you are dealing with multiple industries and you're dealing with service delivery across geographic borders, there's going to be more and more of that aligned to you. But some of the common ones where we spend a lot of time, obviously we do a lot of SOC reporting, so it's System Organization Control reporting, those are typically geared, and we'll talk to a little bit, we'll talk to more of those later on. I know during our podcast here. But those are typically driven on for a SOC one controls over financial reporting and for a SOC two operations and compliance related to certain criteria such as security, availability, processing integrity, confidentiality, and privacy. And it really gives back for SOC two on the organization's service level commitment.
So once again, it's really what services are you providing the coverage for and what are your commitments to your third parties or your customers around what you're going to do to safeguard the data, the systems and the assets, and how you're actually communicating that and providing that level of transparency. Another one that you typically see that's global in nature, it's agnostic, is ISO 27001. It's a program designed around your ISM's, your Information Security Management program, and it's really driven on making sure you have the right governance policies, procedures, risk assessment procedures, so on and so forth.
Like I said, internationally accepted. We see a lot of organizations that are adopting that as a foundation and a framework for what they need in order to tie back to their cyber governance programs. You see others that are predicated on data security, for example, GDPR on EU citizens, and making sure that any data that you're handling on behalf of EU citizens, regardless of where you are, is protected and safeguarded, and you have the right elements of that for purposes of the data subject rights and whether or not they can actually be the right to be forgotten and making sure that that's safeguarded and protected and the consumers have an ability to keep that updated.
And honestly, when you start to see these global requirements come up, what happens is you start to see a relay effect that cascades down to, for example, at the state levels here in the US where California has adopted the California Consumer Consumer Privacy Act, CCPA, which follows a lot of the very similar characteristics to GDPR. If you're dealing with health information, PHI, we have here in the states, Hipaa, which is a regulatory requirement around the safeguarding of information related to an individual's health information, the confidentiality, the integrity of that, and there's certain rights and implications to that that includes obviously the legal requirements as well as best practice controls for the administrative technical, physical safeguards for that information.
If you're operating in the payment space, even globally, PCI has prescriptive standards on what you need to do in order to safeguard that information. So if you have a card data environment that's stored processing or transmitting cardholder data, or even if your environment connects to an environment that does that, there's elements of PCI that are required in order to best safeguard and demonstrate that. There's other types of agnostic ones that we have here in the states that are uniformly adapted globally, but there's also obviously global considerations that have their own standards as well. But something like the NIST cybersecurity framework, which is an agnostic framework that's utilize for many organizations in assessing their maturity, they take a look at their current maturity, they look at an established or a target profile, and they measure up to see where they stand there and what potential additional technologies, people processing technologies they want to put in, in order to achieve their target compliance based on their appetite.
NIST also has other foundations, right? So we have 853, which is predominantly driving FSMA around government systems and FedRAMP for government Cloud systems and an authority to operate for those Cloud systems for government entities. You have NIST 800-171 for government contractors. This one's interesting. This has been around for a bit around government contractors, both for the primes and the subs. But what's happened in the recent years is they've come up with the cybersecurity maturity model certification, which is a independent certification depending on the level of maturity and how much CUI or Controlled Unclassified Information that you have.
So depending on how you are using data in that supply chain process, there's different levels. So if you're dealing with federal contract information, it's level one. If you're dealing again with CUI, then that's level two, and then level three is a more prescriptive adaptive requirement there or level that you would have as you mature through that process. Level two is really predicated on this 800-171 that's been the basis in the foundation for several years now. There's others, so when you think about Sarbanes-Oxley, that's really geared on basic general controls around financial reporting. So making sure the accuracy and the completeness of transactions is where it needs to be for public stakeholders that are investing in companies. So that's really important, and what you're starting to see is more attention even in the cyberspace around SOCs. So the SEC just recently put out, was a proposed rule.
It's a final rule now on making sure that organizations disclose a certain level of their cybersecurity governance program, their risk management program, who's accountable for it, and they're requiring more stringent breach notifications on their annual forms depending on the nature of that. And then obviously there's other ones for GLBA, there's just so many of them that the hard part there is again, understanding when they're applicable, when they're not, and the nuances of applying each one and how to best strategize within an organization so that you're not overburdening your compliance and security teams.
Joseph Carson:
Yeah, absolutely. And one of the things I found is that especially when you get into the disclosure notification side of things, they're very different. When you look at things like GDPR, it's about the disclosure of undue delay. I remember being involved in the very early revisions and it was set as 14 days, but it was not based on the type of data, it was just if you had a breach, you had 14 days, but then they changed it to undue delay because then it was more applicable to what data was impacted. So it was more a risk-based approach. But when you get into those breach notifications, it's really get into for two to four days. Sometimes you don't even know what's happening. Many organizations are still trying to understand. So it's interesting to see and absolutely, I think organizations really need to get into the planning and preparation and simulating many of those to be prepared.
Steve Ursillo:
I think the real interesting part is by prescribing that kind of a timeline, that aggressive timeline, it's inherently forcing a maturity on organizations that clearly many of them are just not there. So, when you think about the need in order to respond for a material breach on any type of dataset, depending on your requirements within a prescribed timeline, you have to have the right instant response programs. You have to have everything orchestrated. I tell organizations all the time, I mean, professional football teams don't go out and just play, right? They practice, they rehearse. So if you haven't done that, if you haven't assigned that accountability, if you don't know your positions and you have not rehearsed doing what you need to do, you're going to have a very difficult time. In addition, the need for the EDR, the XDR, the SOER types of threat and analytics and reporting are really important in order for organizations to really stay on top of the emerging threats and make sure that they're staying one step ahead. And again, they're able to respond accordingly within those timelines.
Joseph Carson:
Absolutely. I'll say when I get pulled into incidents, I'll say that the first 24 hours of the instance is going to be one of the most important 24 hours of a businesses response in life, because how you respond in that 24 hours is critical and it can really redefine the outcomes for sure.
Steve Ursillo:
I agree.
Joseph Carson:
So getting into, we touched on a little bit about some of the most common, we met at a conference earlier this year, which was fantastic, and I really enjoyed, one of the things you went through was, what's some of the differences? For example, when you hear, I hear a lot about SOC one and SOC two, what's some of the primary differences between the two and is there some overlaps as well with others, other compliances as well?
Steve Ursillo:
Yeah, love this question. So there's sometimes a common misconception of what SOC is and what it's not. SOC is not a typical prescribed framework like you'd see for NIST 853 or ISO 27001. It's really a reporting framework that's driven based on providing transparency to third parties around the service offerings that you have. So when you think about a SOC one, it's typically used by an organization to give to their customers when they're trying to provide, again, the depth and transparency around controls over financial reporting. So it's auditor to auditor communication. It's communication around the proper controls to meet financial statement assertion so that if I'm a customer using this particular Cloud offering or technology provider, that I know that the control objectives that have been defined, completeness and accuracy of transactions, access control, logical access to things, change management and the SDLC requirements, things like that, are all handled based on expectations.
So I can properly evaluate my financial risk in using that. And then there's controls and things that I would expect on the client side in order to do to make sure that that transaction cycle is complete and accurate. So SOC one, when you think SOC one, think financial reporting, that's really what you're gearing it on. SOC two is different, that's operations and compliance, and there's also a SOC three, which is a general use report on the same criteria, but the SOC two is really an engine that's devised to provide transparency around certain criteria related to security, confidentiality, availability, processing integrity or privacy. It's predicated on what we would call points of focus, which last year I was actually on the committee that serve to help make sure that we update those points of focus. So there's a mapping to much of the third party criteria that we spoke to earlier to make sure that it's complete.
But those points of focus are considerations that the auditor, the service auditor, the folks doing the SOC two audit and management of the service organization need to evaluate to say, "Hey, is this something that's relevant for my service level commitment? If it is, then I need to take into consideration the proper risk and the proper controls in order to best protect against that." So what that does is it allows for a reporting framework like SOC two to take something like security and all those points of focus and map those to other criteria. So you could do a SOC two, but your controls could map to the points of focus, but also to ISO, they could also map to the NIST cybersecurity framework. The list is endless, just depending on what those commitments are. And if the service organization has commitments on that reference in this cybersecurity framework, if it mentions commitments because they're operating in the healthcare space on Hipaa, then it should include the controls that are designed to do that.
There are additional elements there with a SOC two where you can do what's called a SOC two plus. So the auditor can opine or give assurance on not only the criteria that's in there, the reporting criteria such as security, but they can also bring in third party criteria like the ones that we mentioned and give an opinion on the design and the operating effectiveness of those controls and the accuracy of the system description that you're presenting. So when you think SOC one, ICFR Controls of Financial Reporting, when you think SOC two, operations and compliance around data security, around service level commitments for that. And then of course you have the type one and the type two. A type one in both reports is a design-based report. So it's going to be the accuracy and completeness of the description. It's going to be the design of the controls, making sure that they're meeting the overall objectives and or criteria.
And then in a type two, you're getting all of that same thing, but you're getting the operating effectiveness over a period of time, which is extremely important for organizations that are trying to measure the full maturity of a control to establish what their residual risk is, right? So you've got to know what that operating effectiveness factor is. So that's why you're seeing most of the requests, if not all the requests may initially say a type one, but they all go to that type two and they typically don't like to see gaps in coverage there. So it's a little bit about the two of them. Be happy to get into some trends when we talk a little bit later.
Joseph Carson:
Absolutely. No, that clears up a lot. I think the audience is really going to get really a good in my overview, and for me it's really SOC one is about getting the visibility and the outcomes, and SOC two seems to be more about how you run your business, so your operational side. So one is getting the visibility and the transparency and the reporting, so really getting to the outcomes about what you're really trying to achieve and then ultimately how you're running it from an operational perspective. So that's fantastic to get that clarity, which is great.
What are some of the trends that you're seeing in the industry? Are you seeing a lot of things like artificial intelligence and generative AI getting into compliance and the regulatory side of things, either to regulate it or actually contributing to audits? What are some of the trends that you're seeing in the industry?
Steve Ursillo:
Yeah, definitely. I mean, part of any compliance initiative is really understanding the assets and the systems that you're dealing with. And what we typically find is that any type of, whether it's blockchain or AI or as organizations attempt to move towards more of a zero trust model, there's going to be changes in the way in which you have to design your risks and your programs in order to fulfill what your obligations are and what your overall objectives are. So, we've already been obviously in situations where we're talking to customers about their reporting initiatives or compliance initiatives, and they're coming back and they're talking about how they're connecting with generative AI models or other AI models, and what's some of the things that they need to consider in order to holistically manage that risk.
And we get into obviously talking about the whole risk assessment process, understanding the nature of the system, the data that it's using, the training, the systems that they've designed to make sure that it's fair and ethical, I mean, so on and so forth. There's just a number of different things that you look at there, but also making sure that obviously the controls and the output are going to provide the assurance that they need. So, each element of technology as it evolves, there's a risk assessment process and sometimes the traditional risk go away, but typically overall risk just shifts. Now you have other factors that you have to look at as that technology becomes more transparent.
So years ago when people were talking about blockchain, eliminating the need for certain types of audits, once again, there's certain risks that are going to go away because of the inherent nature of blockchain, but now you have elements of the whole design process, the integrity of the transactions, the controls of how the systems operate and how they operate within the blockchain itself. So all of those things become critical factors. Those are all trends. I think as you start to step into some of the things that we're also seeing, there's been an explosion of automation, not only incident response automation, but even in the compliance space for GRC systems. So you got organizations that are putting in GRC systems that are certainly aiding in the efficiencies internally within their own walls and in their systems, making sure that they're able to operationalize use data and really become streamlined in how they're operating across different types of regulatory requirements.
I think some of the common misconceptions is that by putting in a tool like that, you're alleviating and or reducing the audit effort. And I think that what you'll find is that while there are efficiencies internally in how organizations operate with these tools, there's also efficiencies in how they collaborate with the auditors. But once again, the auditors have standards that they have to adhere to, and the risk, again, shifts, right? These GRC systems are really what we'd call IPE, Information Provided by the Entity. It's collecting information, it's tied in, the API's are tied in back into Cloud systems. They're gathering information from, whether it's Jira tickets or something like that through a SaaS provider. And from an auditor perspective, not only do we have to look at the GRC provider if it's a SaaS solution, to make sure that that's tight, looking at their SOC reports and other types of third party risk management reports, but we also have to look at how it's configured.
We have to test to make sure the system's connecting to the right data sets, that it's hitting the right access control objects that we're doing the access control reviews on. It's pulling the right populations in, it's grabbing the right data. So there's a number of different types of tests that you would have to do when using those products in addition to looking at the data itself and making sure that all your parameters are where they need to be to meet standards. So I think that's an important concept. It doesn't necessarily alleviate the audit, but it certainly helps inefficiencies through the audit process, but auditors still have to do what they need to do. That's another one that I would say, supply chain management is obviously something that's over the last several years has been on the radar for many folks.
Just making sure that software that you utilize and the different types of technologies that are brought in the third party risk management, the vendor management programs are mature. Knowing that just because you don't house that data, you're still primarily responsible for the processing of that data. So maturing those environments I think is really key.
I think the regulatory challenges staying up on that, and GRC tools are a great way to do that. Just making sure that you're able to bring in all these different requirements to map control that you already have, understanding these different security threats that are out there, the increased privacy regulations that are out there. I mean, we know that AI, the EU is actually putting out something right now as it pertains to AI.
Joseph Carson:
AI.
Steve Ursillo:
Yeah, the AI regulatory requirements there. So it's a moving target, and I think what you're going to find is that organizations just have to stay on top of what those contractual legal requirements are, regulatory requirements, the type of data, and then massage that in with all the changes in technology that they have and know that the auditors still have to do their best in maintaining the standards of due process there to make sure that they're giving viable reports and output for certifications or attestations that are going to continue to feed the trust and transparency needed by all third parties and customers alike.
Joseph Carson:
So for me, it sounds like when we talked about, I was actually participating a lot of the subject matter expert for the EU AI Act, and a big portion of that was explainability. It sounds like the same applies to GRC solutions is that you still have to get into, "Okay, I'm now still collecting a lot of the data to help me with the audit. However, I need to go through the explainability about how I got that data, getting into the configuration, making sure it's configured correctly, making sure you've got the right scope of what you're really looking to do." So I think we're really looking at it is making sure that yes, you still have the audit, the solution controls itself rather than actually just the result of what it's actually gathering. So it's really important for organizations to realize that.
Steve Ursillo:
Yeah, it's a great point. I mean, you take an example. If an organization's designed some level of an exception report going through the Jira stack or whatnot or the Jira tickets, they may have some type of exception reporting technology built in. And in order to may look at that and see all the different exceptions that are produced a hundred percent across that logic. But if you don't know the accuracy of that logic and whether or not that's tying back to the risk and the controls, then you could inherently be looking at something that's not necessarily appropriate.
So understanding how that's operating, it goes back to the system integration testing right from years back, that's still applicable now is just making sure you're able to identify the requirements, understand the control, understand the risk, test it as it's meant to be, and then look at the output and make sure that that lines up with what those expectations are and it clearly stays within the expectations of what you're reporting on.
Joseph Carson:
Absolutely. It always reminds me, because back to one of my earlier times in asset management side where I remember a really large transportation organization was definitive. They were like, "We have 120,000 licenses and no more. That's all we have." We're going, "Are you sure? Let's do a proper audit and discovery." And they're like, "No, look, our spreadsheet shows 120,000 machines, servers and so forth." And we're like, "No, do the audit."
So we get in, we actually did the discovery and we found 140,000 machines, 20,000. And I mean that's a large enterprise in its own within this organization and what it was going through the process. What we ended up finding was that their de-provisioning process was not working. People were basically getting new laptops, new devices, new desktops, new servers, but the old one was simply just be moved aside under the desk. And for old versions, maybe they needed to go and an application was no longer working in this newer device. They had to go and basically run it in that old device to do the report and do the spreadsheet, you'd do the activity, and it ended up being licenses, malware, unprotected machines.
When we actually did the calculation, the energy saving alone paid for the deprovisioning process to clean it up. Just the energy saving.
Steve Ursillo:
Energy saving.
Joseph Carson:
Not even calculating unlicensed machines and the threat of those devices as well, just the energy costs of running those 20,000 extra machines was so absolutely. It's really important to make sure that you have that transparency and visibility into making sure that you don't have a mistake in the process.
Steve Ursillo:
That's a great example. I think scoping is such an important part of any type of cyber compliance or privacy risk management compliance initiative. You could spend so much time, energy, and effort solidifying a certain element, and if it's only a fraction of how you operate in a fraction of the overall footprint, because you didn't identify properly, that's a huge risk. So auditors spend a lot of time and they should be spending a lot of time asking the right questions, understanding the technology and the inter operating of the technology both in their systems and with third parties so that they clearly understand where it's going so they understand what that risk profile looks like. So that's a great example. I appreciate you bringing that up.
Joseph Carson:
No problem. And that brings me in the next side of things is if I'm an organization, I'm going down this path, let's say just realize, "Okay, yes, we want to do a certification in let's say soccer. We want to do ISO." What would be the best place to get started? What resources would I need? It sounds to me having that really good foundation and scoping would probably be a good place to start, but if you're an organization, what would you recommend the best place and resources to go down this path?
Steve Ursillo:
Okay, yeah. So I think, so a couple things, right? The first thing is obviously identifying key stakeholders in the organization that are going to be responsible for the efforts. And with that, you're going to be identifying the right people that have the subject matter expertise over an array of different areas that are going to be required in order to facilitate an effective program. Obviously, like anything else, are going to need key stakeholder and leadership, buy-in. If you're not going to get that, then you're going to have a very difficult time succeeding. It's definitely a costly effort. It's got to be weighed up against obviously the value of the protection of the data, contractual and regulatory requirements that you have. So getting that buy-in and that direction, getting that strategy outlined as I think is paramount for a starting position. Then identify the experts, identify the people, whether they're internal, external consultants, anything that you're going to need or a team of folks that you're going to need in order to execute, I think becomes really important.
Identifying the right applicable regulatory expectations and contractual expectations. So now you're getting into your procurement teams, you're getting into your legal teams, you're getting into folks to help you truly understand your data privacy officers, so on and so forth. To truly understand the types of data you have, the requirements you have or more mature organizations that have a contract management system, this might be a little bit easier than ones that have a little bit less of a mature process for that, but that's really important, understanding that so you know what you're up against, what criteria you have to set. Then you're going to build out your risk assessments, making sure that you've established the right risk assessment against meeting those requirements. Then you're going to be looking at obviously identifying the objectives and scope the boundaries of the systems. What systems do we need to take into place based on, for example, PCI or Hipaa? Are we using ISO in NIST 853 as the overall arching factors there? What other types of factors do we have to bring into the scope?
And then you'll really establish what the framework is that you're going to use or frameworks or criteria that you're going to use in order to measure up against. So now you have kind this risk-based approach. You're looking at the completeness with the frameworks that you're using, you're designing and you're evaluating and you're setting up ongoing measures for monitoring those controls. You're going to develop the policies and procedures. This is something we typically see organizations struggle with, the level of documentation needed in order to substantiate how they operate overall as a practice, as a governance program, but also from a procedural perspective, not necessarily run books in every area, but enough that if you gave it to somebody with the knowledge to operate, they could articulate how to execute within the organization on a particular procedure.
So documentation becomes really important. Having the right folks to understand, articulate the processes and then be able to transcribe that. Good technical writers is always a good part of that. Making sure the controls are implemented, they're monitored, they're tested. Your incident response program is up to date. We talked about that earlier when we talked about not coming to the game with no practice, just making sure you've done those rehearsing and you've done that. Training and awareness continues to be a significant factor. Just making sure people know their responsibilities, they know how to operate, they know how to call a follow when they need to.
They understand the risks and threat landscape. And like cybersecurity, it's a holistic approach to ensuring success. Then have those regular audits, whether it's internal audit, periodic audits, external audits, assessments. It's okay to have internal teams doing that depending on your maturity and the competencies, but it's great to have externals come in, be able to report independently to folks and make sure that there's a clear eye and an overall objective look at the programs, and then ultimately just making sure that you're staying on top your risk assessments and everything.
This is a continuous process. It's not set and forget. You got to make sure that you institutionalize this program to gain success over time, otherwise become stale, outdated, and you'll lack the achievement and the success that you want.
Joseph Carson:
Absolutely.
Steve Ursillo:
As far as external resources, a lot of that really depends on what your initiatives are. I mean, there's a significant amount of resources out there. Obviously, ISACA, AI CPA has a lot related to SOC. ISACA has a lot related to COBIT and other frameworks that are out there. ISO is going to have a lot of information predicated on how to implement a program like that. If you're up against PCI, PCI has well-versed documentation on how to execute in certain areas of their programs. CMMC is also coming up with its information. We didn't talk much about HITRUST, but that's another one that's out there that's pretty prescriptive. That gives a lot of information on what you would need to do in order to fulfill any HITRUST obligations.
HITRUST is, it's designed to be agnostic, but it really started in the healthcare industry space and it's probably the most popular in that space, but they get a lot of information there. And of course there's other sans. I mean there's a number of industry groups out there that can help you achieve success and deal with some of the nuances of all these different types of compliance programs.
Joseph Carson:
Absolutely, they have a lot of great resources and also even certifications and trainings, they really help you make sure that you've got the right knowledge. I think one of the things I can't emphasize more about documentation definitely is the ability to make sure that you get consistency and repeatable. It prevents people from making mistakes where a lot of breaches and a lot of incidents come from. It's just configuration and mistakes that we do because we don't have the information in order to make sure we're doing consistently with the right security approach. I think one of the things a couple of you mentioned really resonated with me is making sure you get the right people, the resources and the people and the scope of those people as well within the organization. Getting buy-in from the executive team as well because they're really going to be your sponsors to make sure you're able to fulfill and complete.
And then an interesting one is what the contracts as well as you mentioned, that's probably really good places to understand about how much effort it's going to take. If your contracts are actually well basically documented, maintained up to date and using a proper system, a solution can really help you automate and speed a lot of those up. If it's manual and very human process, within hidden and within documents and data, that's going to be a very difficult place to get started. So absolutely. For an organization, you mentioned a bit about internal and external resources.
One of the things I always say is, should organizations try to do this alone or should they really try to make sure that they get the right help? My view is always about making sure. When I do things myself, if I'm not really expert in that area, what I try to do is get the right person who will help me do it because they'll do it a hundred times faster than me and much better than I will. If I try to do something that I'm not an expert in or skilled in, I might have to do it four or five times repeatable in order to get it to a certain amount of quality that would be acceptable. Is that the same process here? Would you apply the same approach? Is it better to get outside help and resources to help you go, or some organizations really placed to do this by themselves?
Steve Ursillo:
I think I'll take a step back. I think the real question is, identifying the right resources on such a large scale of subject matter expert areas. And we talked about legal, we talked about data privacy and security. We talked about controls of a financial reporting. I mean, there's all these different, you've got HR elements, you've got your technology and operations team. There are so many different folks that are part of this program in one way, shape, or form. So, I think understanding the right expertise based on those requirements is key. Now to your point, if an organization has nobody or a few folks that have expertise in some areas, then they can leverage that and then maybe augment that with some professionals that are in the space that are consultants that provide these services. So I think it's a careful combination, but you don't know what you don't know.
So in certain cases, you do have somebody who may think, "Okay, I'm pretty vast on this. I've done X." But perhaps what you need to do is just make sure that that person is comfortable with everything that, again, they know. They know what they know, but they don't know what they don't know. So, making sure that they're on the right path based on all of that information, I think becomes important. When you have folks that have a larger team that specialize in the industries that you operate in, that specialize in the regulatory requirements, that know the idiosyncrasies, they do it day in and day out for a magnitude of organizations and know how to navigate a lot of that, there's obviously benefit to that, right? So it's not necessarily something I'd say you have to go external, but if you have those teams internal, that's spectacular, utilize those resources, bring those teams in to do what they need to do and have them augment where they need to, where they find themselves short.
But again, you always have the ability to find external consulting groups that operate in the space day after day and can typically navigate this stuff. And what you're bringing to them is probably not the first time they've seen it or navigated it and have a well-executed plan in order to help you facilitate a successful result as a part of that. I think another thing too is when you do all of this, and I might've failed to mention it earlier, but it's incredibly important. Getting key stakeholder and executive leadership support is paramount, but also continuously reporting back to your leadership teams is really important. So they understand their investment, they understand the risk, the strategies and where you're heading and making sure the board of directors and everybody's up to date on that becomes important.
So again, making sure you even have those folks that are properly aligned and the right skillset to deliver the message and not make a mountain out of a mole hill, but at the same token, provide a true element of transparency as to what their risk is, I think is really important as well.
Joseph Carson:
Absolutely. I think that's important because one of the things is that a lot of these requirements and requests come from the board in the first place sometimes because they want to ultimately reduce the risk and also increase the quality assurance for themselves. And that's one of the things is that when they're representing, they want to make sure that it's both directions. So really important. This has been fantastic. It's been, for me, speaking with you is always educational. I always learn a lot and it's fantastic.
Do you have any final kind of summaries or key takeaways that we'd like to lead the audience that would really maybe a resource, maybe a place to go or recommendation you would've?
Steve Ursillo:
Well, I want to thank you once again, Joe, and I also want to say the feeling's mutual. Every time I have a conversation with you, I'm learning something new as well, so I appreciate that for sure. Yeah, I think overall, understanding the difference between your cyber compliance and cybersecurity needs is really important. And not necessarily thinking that just because you're driving one element of cyber compliance, that you're looking at cybersecurity holistically. I think that's important. We talked about the nature of the resources, the completeness of what you need to do to facilitate an effective program, how to get those resources, making sure they're the right resources, how to communicate your efforts, making sure that you're mitigating and dealing with what you need for all of the different types of contractual and regulatory requirements out there.
Understanding how to mitigate the threat landscape, identify the proper assets and the scope and the environment that you're looking at, making sure you're not leaving anything out, like in your use case of the systems that were left out. Making sure that you're designing and you're operationalizing all of the controls that you need and you're monitoring that as you mature the program. You're documenting that. Those are all real important factors, and obviously it's a journey, right? And it's going to continue to evolve. It's not set and forget.
Have a strategy, make sure you've got the right team to back you up and you're in a position to navigate those threats and those things that go wrong or go sideways or things that happen that are not within your control but affect you. I think I'm going to tie this all back to your opening statement. Have fun. This is fun stuff, right?
Joseph Carson:
Absolutely. That's one of the things is that when I attended the conference, I met so many awesome people that was from the auditing side of things that I'd never thought about, never seen that. It was such exciting, and really to see how people view the compliance and auditing side of things. And for me, it was very educational and already eyeopening, but absolutely we had to make sure that this was fun and enjoy it as much as possible because ultimately that's what makes the big difference, for sure.
Steve Ursillo:
Absolutely.
Joseph Carson:
So it's been fantastic having you on. I've really enjoyed the session today and definitely for the audience, I think this is really going to give them a really good amount of resources and knowledge to really help them approach compliance and security with a much more broader perspective and make sure they understand it, whether taking it from a much more readiness. And also think about that this is a journey. It's not something you do once and you've done. You have to do it continuously, and the risks change and the risks evolve, and we have to keep evolving and also making sure we simulate and practice because ultimately that's what makes the difference. So Steve, fantastic having you on. Really appreciate it.
For the audience, if they have any questions, is it okay for them to reach out to you on social media or any ways?
Steve Ursillo:
Absolutely.
Joseph Carson:
Fantastic.
Steve Ursillo:
And I'm sure you'll have contact information that they can.
Joseph Carson:
We'll do. We will make sure it's available in the show notes. Again, thank you very much for the audience. Tune in every two weeks for the 401 Access Denied Podcast. We're always trying to bring information. It really helps you make your journey a successful one and make sure that you're able to make the world a safer place. So thanks Steve for joining me today. For the audience, I'll see you on a future episode. Take care, and all the best.
Steve Ursillo:
Thanks again, Joe.
