Cloud Security Today
The Cloud Security Today podcast features expert commentary and personal stories on the “how” side of cloud security. This is not a news program but rather a podcast that focuses on the practical side of launching a cloud security program, implementing DevSecOps, and understanding the threats most impacting the cloud today.
Cloud Security Today
The New SEC Rule
Episode Summary
In this episode, Special Advisor for Cyber Risk at the NACD, Christopher Hetner, returns to the show to discuss the new SEC cybersecurity rules. Chris has over 25 years of experience in cybersecurity, helping protect industries, infrastructures, and economies, serving in roles including as SVP of Information Security at Citi, Senior Cybersecurity Advisor to the Chairman of the US SEC, Executive Member of IANS, the National Board Director of the Society of Hispanic Professional Engineers, Senior Advisor for the Chertoff Group, Senior Advisor to the CEO of Stuart Levine & Associates, and Co-Chair of Nasdaq Cybersecurity and Privacy.
Today, Chris talks about the developments since January 2023, the timeframe requirements in practice, and normalizing cybersecurity incidents as business-as-usual. What is Inline XBRL? Learn how startups could prepare themselves for these changes, the scope of disclosure, and how risk management strategies might evolve to address Cloud-specific threats.
Timestamp Segments
· [02:36] What has changed since January?
· [06:49] Why things changed.
· [08:51] Was it a good move?
· [12:27] Determining the materiality of cybersecurity incidents “without unreasonable delay.”
· [17:49] Is 4 days enough?
· [22:19] The scope of disclosure.
· [24:09] Normalizing cybersecurity incidents.
· [26:24] Moving toward real-time monitoring.
· [28:52] Is insurance becoming a forcing function?
· [32:18] Evolving risk management strategies.
· [36:05] Third-party disclosure requirements
· [39:51] How do startups prepare?
· [41:52] What is Inline XBRL?
· [42:54] Inline XBRL to 8-k.
· [43:30] How the tagging requirement impact the disclosure process.
Notable Quotes
· “The magnitude of these events is the percentage of the event relative to revenue.”
· “We’re going to see market forces drive these safety standards within our enterprises.”
Relevant Links
LinkedIn: Christopher Hetner
Resources:
https://www.sec.gov/news/press-release/2023-139.
The future of cloud security.Simplify cloud security with Prisma Cloud, the Code to Cloud platform powered by Precision AI.
Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.
[00:00] Intro: This is the Cloud Security Today podcast, where leaders learn how to get Cloud security done. And now, your host, Matt Chiodi.
[00:13] Matt Chiodi: On December 15 of 2023, the new cybersecurity rules from the US Securities and Exchange Commission, otherwise known as the SEC, will take effect. On today's show, I have probably the best person that I can think of, Chris Hetner, to talk about what's changed. Now, some of you may recall, back in January, I had Chris on to talk about what was then the proposed cybersecurity rule. Well, a lot has changed since we spoke in January, and I could think of no one better than Chris to come back on and to educate both me and the whole audience on what has changed, and specifically, what are the impacts for your Cloud infrastructures? For those of you who don't remember, Chris Hetner is the former SEC chair, he was the senior cybersecurity adviser, he's super well-versed in this area, he is also currently the Special Advisor for Cyber Risk for the National Association of Corporate Directors. You can check him out on LinkedIn. But I think you're going to enjoy this episode, because what I pulled away from it was that this new SEC Rule is going to up-level cybersecurity. So much of what we think about in cyber today is about the bits and the bytes, or what Chris would call the rivets, so this is going to cause our community to up-level and really focus more on the risk and more on the business itself, and to think in terms of how is cyber taking down business risk? It's going to force us to look at investments differently in cybersecurity. So, get ready, get your notepad ready, and take some notes.
Chris, thanks for joining us.
[02:01] Christopher Hetner: Fantastic. Good to see you, Matt.
[02:03] Matt: Yeah, this is great. So, I was saying before we started recording, you are I think maybe only the second guests that I've had on twice. So, that means that what you're going to talk about is both interesting, and it's also really important. So, thanks for coming back on.
[02:16] Chris: Anytime. I'll make sure to not be overly repetitive.
[02:20] Matt: Well, the reason I wanted to have you back on is because obviously the new cybersecurity rules from the US Securities and Exchange Commission, otherwise known as the SEC, are set to take effect on December 15, ‘23. Just, high-level, what's changed since the last time we spoke, which was January of ‘23?
[02:43] Chris: Wow, it feels like a lifetime ago. In January, early this year, the SEC had enforceable interpretive guidance that was issued in 2018, and interpretive guidance is a premise based on commission vote. It originated from the Division of Corporate Finance, which had additionally set forth guidance. This had a bit more leverage and teeth because it was voted for and approved by the entirety of the commission, but it was still “guidance.” In reality, the guidance in 2018 is still an enforceable matter. So, the principles and the enforcement of leverage that the SEC has was still in place. Fast forward to today, we have now an approved rule. So, this would become more of a SEC securities regulated type of rule that's more enforceable, it'll open up the class action, directors and officers, accountability. It's got a bit more teeth, more broadly in the investor community and the legal community, and the main difference here is, number one, they've established this threshold for a four-day reporting requirement, once the incident is determined, “material,” and that we can unpackage that material is based on how cyber threats and the incident introduce business operational financial harm to the company.
One of the proposed mandates within the role that they actually walked back from is mandating to disclose whether you have cyber experts on your board of directors. So, that's been removed. Instead, they're more interested in how cyber oversight is executed at the board level, from a substantive standpoint, as well as the type of expertise and competency you have in the management ranks on cyber. So, they're emphasizing build out your cyber organization within the management ranks, but more importantly, ensure that it's integrated into enterprise risk management. So, it's not solely the chief information security officer, or the chief technology officer, or the IT function. This is an enterprise level responsibility that requires teaming, and actually, this will benefit the CISO because now it's placing more accountability across the finance function, legal, compliance, communication, the Board of Directors, the CEOs now are being called out as being further accountable, so that's one upside, and then the other material component is distinguishing between a cyber event or an incident. Once the incident occurs, then that's a disclosable matter, and unaddressed cyber risk.
So, if you have vulnerabilities that are just ripe for the exploitation, that haven't been addressed, and you're sitting on top of these vulnerabilities, and they could potentially represent a material exposure in the future, you have to disclose how those risks are being addressed and treated, not to the detail as to provide a roadmap for the adversary, but just realize that, “hey, we've got technology that needs to be addressed, we've expressed this to our board of directors, and we're going to go through this journey on uplifting our cyber infrastructure,” whatever that may be. So, those are some of the brstroke differences, in terms of what we see now for the hard, fast rule, that's going to create more accountability at, I'll call it more of the C-Suite, the executive team, and the board level.
[06:49] Matt: What was the thinking behind, or at least as far as you understand it, what was the thinking behind walking back that requirement for the cybersecurity experience on the board of directors itself? Because I remember, we talked about this in January, I know there were a lot of cybersecurity professionals thinking, “oh, this is my opportunity to get on board.” What happened?
[07:09] Chris: I still don't believe that this excludes the CISO or cybersecurity community from becoming a board member. I think that represents an incredible path and opportunity for cyber professionals, particularly those professionals that are in the 25-plus year ranks, that have a wealth of experience beyond just the technical play, that understand and appreciate the dynamics of how a business operates. I think that represents an incredible opportunity for a CISO or technologist to become a board member, but the recognition that there aren't enough cybersecurity professionals were underserved in the management ranks, and the number of cybersecurity professionals at current state that can be an effective board member is very slim. Instead, let's double down on cyber competency and capability within the manager ranks, but the rule also underscores the importance of the substance, the frequency, the content, and the engagement between management and the CISO on the board. So, it doesn't necessarily walk back cyber security responsibility at the board level. It's certainly going to be a point of emphasis, but there's a recognition that there's a bit more maturity, and I would say, this is a living breathing rule. There could be an update within the next few years that doubles down on cyber and technology competency in the board rank.
[08:49] Matt: From my perspective, it sounds like they did something that was wise, actually, given what we've been talking about for the last decade, which was this talent shortage, etc. And, like you said, if you look at people who have done, not just deep in the weeds cyber for 25 years, but people who have been involved with this, let's call it the business of cyber true risk management. That's a very small number of people. So, it sounds like this was actually a good move.
[09:19] Chris: Yeah, look, I'll put on my National Association of Corporate Directors hat on. As an advisor to that community, we took the position that this represents an opportunity for the boardroom to take accountability for cyber, but through the lens of how cyber introduces legal, operational, business exposure, financial exposure into the board, and what I've witnessed, and others have witnessed, when you place that cyber expert in the boardroom, it typically becomes a one-to-one discussion between the CISO or the cyber expert, and that particular board member, and then invariably what happens is the entirety of the board checks out. So, instead, we've taken a position that this needs to be contextualized to business operational financial outcomes, so that the entirety of the board is engaged around this matter, and when management is requesting for additional budget, additional resources, that there is an understanding how that budget and resources are applied to business reducing principles.
We've seen over the last, we'll call a decade or so, a burgeoning cybersecurity industry. 10s of 1000s of companies that have just popped up, from startups to mid-level, and now we're seeing the highly fragmented market becoming contracted. The access to capital is more expensive. So, the venture capital community is being squeezed, and we're seeing further centralization. So, it's really about the productive application of resources and investment to reduce that exposure that represent and align to business reducing measures, operational resilience, and strategy, versus having that deep technical discussion around how effective are we deploying multi-factor authentication or how we configured our full suite of Cloud capability from a security standpoint within our stack? You can have those deeper dive discussions and subcommittees. In fact, we encourage subcommittees, such as risk committees, to have those deeper dive discussions. This also represents an opportunity for outside experts to come in, in a retain capacity. One could argue that having that external, outside, independent expert is bit more productive than having that dedicated person on the board. So, that bringing in a fresh perspective, as long as they can bring business context to the conversation. So, I think that gives you a rounded-out view as to where we stand now, but not to say that in the next two, three years, that might not be an update to the role where we have more capacity to fill the board with cyber and technologists that could be more rounded.
[12:27] Matt: Let's dig a little bit more into the rule. So, my understanding is that the SEC is going to require, I guess, starting on the 15th, companies to determine the materiality of a cybersecurity incident “without unreasonable delay.” How does this requirement intersect with the typical timeframe within which Cloud security incidents are identified, assessed, and reported within public companies? I'll come back to that public companies piece here in a bit, but how does that requirement intersect with that typical timeframe?
[12:58] Chris: Well, for Cloud environment, the assumption is that your core assets, your applications and your core business processes, reside in some type of Cloud environment. I would encourage the security organization to ensure that they are reflecting their budget, their return on investment for Cloud migration, to incorporate those additional security features, because as you know, security is not inherently embedded within the Cloud instance. It requires either an upgrade in feature set or enablement of certain features that perhaps are native but haven't been established or enabled as part of the process. So, number one, I would ensure that that security stack within the Cloud is reflective of your risk tolerance levels in your security policies and standards across the enterprise, but then, secondly, how do we monitor for security events through the security operation center, through managed detection response instances across our enterprise? Let's pretend that this is all within the Cloud. That still needs to be eyes on screen, hands on keyboard that are monitoring for these events that are occurring. So, this new rule with the 4 day requirement applied to materiality tied to the security event is going to require a shift in the cybersecurity ecosystem.
I actually wrote an article about this a couple of weeks ago. Our SOC and our MDR platforms require now enhanced business intelligence, the ability to contextualize an event emanating from, let's call it your Sim platform, tied to an asset that might have been compromised, to now representing what's the impact to my business based on this event? So, if I had data extraction tied to a particular database instance, that has been flagged as highly sensitive data, the SOCs should automatically have a bright red alert saying, “this is a potentially material event.” So, now let's start the process to escalate this to the CISO. To our general counsel, to our Chief Risk Officer, Chief Financial Officer, put together a team to converge around this to determine the potential business impact and magnitude. So, it's going to drive increased business intelligence incorporation into our SOC and VR platforms, as it pertains to our Cloud instances, and that's going to be, I believe, a step forward towards meeting these new requirements, because now the SOC, and your Manage Detection Response Teams should have that data set incorporated to reflect “we have an event. It's an anomalous type of activity across our network. What does it mean to our business?” Bringing that business intelligence informed based on enterprise risk management principles, defined as part of your job security operation center risk management practice, is a process that needs to really escalate right now, in order to prepare for these disclosure requirements. So that now, the timeframe we call meantime to detect, need time to respond. Now, it's the meantime to determine, so what? Okay, so I have a data extraction of 1000 files. Is that important? Is it contained personal identifiable information? Is it tied to intellectual property, tied to my company's secrets? Or is this just some random files of leaked that are publicly available? So, bringing that context, in terms of how important these events are from a business impact standpoint, is going to be the future, as we see this moving forward.
[17:49] Matt: Some critics argue that, that four-day timeframe, it's not enough time to confirm a breach, understand its impact, coordinate notifications, and you and I’ve discussed this before the show, but I saw this newsletter came out, and it said “Mr. Cooper, which is one of America's largest non-bank mortgage loan services, suffered a cyberattack last week that temporarily disrupted customer transactions.” They went ahead, they filed the form 8-K, said they took immediate steps to lock down its systems, but this is what I thought was interesting. The company noted, “it's still trying to determine if any customer data had been compromised.” So, I guess the question for you is, something like that, as an example, is four days enough?
[18:33] Chris: Yeah, look, it's a fairly tight timeframe. I would agree, but the four-day requirement is really triggered based on the materiality determination, and the determination around materiality. That could take days, weeks, months, potentially, and there's also a provision within the rule that allows some leniency if it's a national security investigation, so the company would request a bit of a reprieve from the Department of Justice, ensure that your local FBI field office is part of your incident response plan, but that's why understanding the business context up front and putting that into your incident response planning processes is super critical, because, again, determining materiality, it is the threshold to then figure out where the items are from a reporting standpoint, and how that flows through your disclosure statements. Now, early on, given the focus on enforcement actions against public entities that haven't disclosed yet, we could see a potential over-disclosure, that these incidents really aren't material.
One of the metrics that we use, across the National Association of Corporate Directors, when we're expressing through our reporting platform to the board, the magnitude of these events is the percentage of the event relative to revenue. So, zero to 1%, one to 2%, two to 3%. Typically, anything over three, three and a half percent of top line revenue starts to bleed into that materiality threshold, in terms of how it impacts your financials, your operational exposure, your business impact, your ability to maintain some level of continuity for your customers, in terms of servicing them, but the complexity there, when you're in the proverbial knife fight, determining how these adversaries got in, remove them from the network, it's hard to determine the long-term costs, or the tail costs, and this is where you get some iterative disclosures, because the reality is that many of the class action suits are regulatory fines that potentially surface as a result of a cyber event that could take six months to two years to potentially surface, and these can be extremely costly, in the hundreds of millions of dollars, into potentially billions of dollars of cost to the organization. So, the disclosure requirements decided to be iterative over time.
I already see outside securities lawyers that are going to be retained to help determine how important these are and assist with the determination of materiality, so I think we're going to see, over time, an evolving process, and my hope is some level of normalization in the future that establishes clearly and concisely to the investor community how impactful these events are from a business standpoint, but not necessarily disclosing the means by which the adversary compromised your network or the vulnerabilities that are exploited, because that's not the attention here.
[22:18] Matt: So, that might be then what we're talking about when we talk about the scope of disclosure. Is that where that comes in? Because I know, I've seen some discussions where people are concerned, because you're like, “hey, if we have to disclose within four days, we may not even know necessarily where this started. We don't want to give an adversary a leg up.” Where does scope of disclosure come in?
[22:42] Chris: Yeah, the scope is really based on, and the SEC, through the 2018 interpretive guidance, laid out a fairly concise enumeration of business impacts, such as loss of revenue, depreciation of stock, the potential knock-on effect, in terms of upgrading systems, replacing systems, particularly if it was a destructive type of malware event. There's other facets such as counterparty risk, legal risk. So, the scope of the disclosure, it's not necessarily based on the narrow security event itself. It's based on how it stressed your balance sheet, and that's why it's super critical for the CISO function, including it, to engage enterprise risk management now as part of this process to determine where the potential annual expected loss is going to be realized as a result of not addressing the cyber risk, so that when an event occurs, you know if it's a 48 hour event, it's called a ransomware event, and it results in a business outage, exactly where those costs and impacts are going to be, so that those predefined impact scenarios are already embedded within your incident response process.
[24:09] Matt: It seems almost like part of this action is normalizing cybersecurity incidents as part of business-as-usual. Is that fair?
[24:20] Chris: There's a degree of that, and actually, since I left the SEC four years ago, I've been working very closely with the risk transfer market. So, the cyber insurance industry. It's fascinating because the insurance industry is shifting more towards a level of normalization, to your point, around security events or incidents, and there's established loss parallel categories, such as data breach, ransomware, misappropriation of funds, misappropriation of data, loss of intellectual property, business interruption. So, these are clearly defined impacts that potential insurable, and that depends on the level of policy that you write, but at the end of the day, the way we view cyber risk management is the insurance markets are ultimately going to serve as the arbiter for cyber risk management, and defining where those impact zones are going to be realized across your balance sheet, across your operational resiliency exposure, and then more importantly, what safety measures should you be deploying in order to mitigate that exposure? No different than how the insurance markets have informed automobile safety measures, such as crash avoidance systems.
So, think of it as almost an annual roll up, in terms of what events had been realized, what impacts have we seen within work, in terms of mitigate the exposure, and then pushing forward safety standards into our technology infrastructure, into our enterprise, in order to mitigate that risk? So, I would advise following very closely how advanced insurance companies using data analytics, artificial intelligence, loss experiences, are going to be moving the needle forward, in terms of establishing safety measures, in terms of our technology estate.
[26:23] Matt: I've had a couple of conversations with CISOs on that very topic around cyber insurance, and with a couple of carriers as well. What is your take on, for a long time, and I think for still the vast majority of companies, when they're going out and doing their vendor risk management, a lot of times, it comes down to questionnaires. It's point in time questionnaires, answer these couple 100 questions. You can pretty much put whatever you want on there. The companies do that, they're not always 100% forthcoming. Where is it from a risk transfer process for an insurance company? Is there a movement towards more real-time monitoring?
[27:06] Chris: Yeah, it's a great question. I'm in the process of working with various carriers and brokers on this approach, and we're seeing the carriers taking more of an audit assessment type of position, where they're going to ask a series of questions, they're going to inquire about the company's security posture. So, that's an approach that is being taken. The advancements in security monitoring, using advanced analytics, to determine how cyber threats are going to materially impact your business posture is an area of emergence. So, we're starting to see that capability, I would fall short of stating that a company is going to have a network device plugged in to sense whether activity’s occurring. I don't think that's going to occur, but the insurance markets is going to become more proficient in determining based on your company's risk profile. Again, a healthcare company is going to look different than a bank, it's going to look different than a manufacturer, where those potential events are going to be realized, in terms of business impact, and then, more importantly, how are we deploying investments and reducing that exposure so that when you go back through the renewal process, the insurance broker and/or the carrier is going to ask very specific questions. “Okay, so do you have these baseline controls?” And if not, you're expected to either see a heightened premium, or this becomes an uninsurable policy.
[28:51] Matt: It sounds like insurance is almost becoming a forcing function for a minimum criteria of security, in terms of I would assume that multi-factor authentication, these are things that companies are looking for companies to have almost as a minimum. Now, do you see that becoming that forcing function?
[29:12] Chris: It is. Again, I keep coming back to the arbiter for cyber risk mitigation and resiliency controls. Use the analogy with other insurable activities or risk domains, such as crash avoidance systems, or flooding, or fire suppression. It's using that actuarial approach, those risk mitigation measures, and the actual losses that have been realized as a result of cyber to inform where those measures are, and they combine that with the regulatory regimes, whether it be healthcare or financial services, driving those basic requirements as a measure to ensure that, number one, you're insurable, but number two, you're taking the right level of measures, you're establishing that baseline foundational set of controls, and then, if you think about the insurance industry and how we bring more capacity, in terms of the ability to sell more insurance or to create more expanded coverage within our insurance products, we're seeing a formation of the ILS markets, the insurance linked securities markets, where you package a portfolio of insurance policies, and you sell to the capital markets through some type of securitization, or some type of bond, and if I'm able to offload, let's say $100 million in cyber coverage to the capital markets, then I could sell more insurance, and that'll bleed down into the small-midsize businesses that might create more coverage limits for, let's say, a ransomware event. The average ransomware coverage is somewhere between eight and 10%, but if I could sell more insurance than that becomes more coverage limits, however, with offsetting some of that exposure into, we'll call it the capital markets, now, it becomes the investor community driving further requirements on the insurers to drive standardization. So, we're going to see market forces drive these safety standards within our enterprises.
[31:37] Matt: I hadn't even thought about that. So, is that happening today? Are those things becoming securitized? Because it sets my mind down a whole path with how Fitch and how all those companies are writing those bonds.
[31:50] Chris: It's fascinating. The first catastrophic bond for cyber was issued, I believe it was January this year, so there's already been a few trial balloons in the 10s of millions of dollars. So, there's going to be an increased push towards the ILS markets, and I would just keep a close eye on that.
[32:17] Matt: So, let's getting back to the actual rule itself. This has been super interesting, but the final rule requires a description of a company's processes for managing cybersecurity threats. With that in mind, how might a company's risk management strategies evolve to address Cloud specific threats? And maybe what might the disclosure of such processes look like?
[32:41] Chris: So, we've taken a position through the National Association of Corporate Directors, and we're agnostic to whether it's on premises or Cloud. We view this as a set of security exposures, a set of controls. Those controls manifest within on-premises versus the Cloud, but really, it starts with, how do you develop an understanding of the overall business financial exposure to cyber risks and cyberattacks? Defining those risk scenarios within your enterprise risk management process, there should be a view as to those cyber threats that are most likely to cause business interruption, legal exposure, financial losses to the company. There should be an insight, as you perform this assessment into those cyber controls and investments and defenses that most effectively mitigate those losses and those financial exposures, and then there should be a discussion around how much of this risk can we offset using a risk transfer strategy or an insurance policy, including stress testing?
And then there's the ultimately roll up to the board of directors to, whether it be the audit committee or the risk committee of the board, going beyond what we see as traditional maturity and compliance scores, to a comprehensive report that gives business financial operational context, from cyber risk, and something that resonates with the board so that they can start making some decisions around, how much of this exposure are we willing to accept? How much of this can we transfer? And then ultimately, if we think about the capital investments we make towards Cloud security, how do we deploy that in such a way that materially affects business reduction, aligns with our business strategy, and then ultimately maintains resiliency? That's a much different conversation that we typically have now, when the management team or the CISO and the cyber security function enters into the board, where it tends to be very deep, technical, it tends to be talking about what I call the rivets of the organization.
We shouldn't be talking about incursion deployments or multi-factor authentication deployments or the fact that zero trust has been deployed in 30% of the company. We should be talking about how these investments should be made in order to find out our risk exposure in the language that resonates to the board, and if they need to know, “okay, so where are we deploying this investment? Where's the capital being deployed? Here's where we need to ensure that our investments are made.” Here's the product selection, and you can dive deep into the technology stack, but it needs to be much more comprehensive and much more business oriented going forward, and that's exactly what the SEC is going to want to see, and the investor community, quite frankly, wants to see as a result of these disclosures.
[36:04] Matt: So, obviously, companies are engaging third-party Cloud service providers. How might the disclosure requirements around these third-party engagements in cybersecurity risk management processes impact the relationship between companies and their Cloud service providers, and oftentimes, when we think of a CSP, we're thinking of the big three. They're all publicly traded, but a lot of times, they're dealing with a SaaS provider that is not publicly traded. So, I guess, two parts of this question is, how might the disclosure requirements with those-third parties change? And then the second part is, right now, my understanding is that this rule is aimed at public companies. Where do private companies come in? So, it's two questions in one.
[36:53] Chris: For supply chain exposure, that's absolutely a requirement, and I don't think that's appreciated in some of the content that I've seen surrounding the SEC Rule. So, to the extent that you're reliant on your suppliers, and those suppliers introduce material risks and exposures through a potential cyber event, that becomes a disclosable requirement through the new SEC cybersecurity risk governance rules. So, to your point, if you have a SaaS provider, it's very specific to an application, very specific to a business process, ensuring that SAS provider is aligned to your incident response planning. What we're seeing, in terms of emerging and advanced preparedness, is bringing in your third-parties that potentially or Cloud service providers into your incident response planning and into your tabletop exercises. So, that's an area that I see emerging, and obviously, that's all based on prioritization based on risk. You might have a dozen Cloud service providers, but three of them are really core to your business. So, some level of prioritization based on risk, bring them into the tent when you conduct a tabletop exercise, and ensure that those incident response procedures are tested. Now, from a disclosure standpoint, if that CSP is compromised, and it impacts your data, that becomes a disclosable event through you as an enterprise, but you might have duplicated its exposures there. You might have the third-party provider that's also publicly traded having to disclose in addition to you as company. Now, for private companies, this role is specific to publicly listed companies, within the SEC is about 10,000 companies, on average, so the private entities, I would say, that are impacted by this rule will likely be pulled through that third-party relationship or that counterparty relationship. So, if you're a publicly listed company and you're reliant on a private entity, then that private entity is going to be pulled in, potentially, to that disclosure, to the extent that you're reliant on that entity, that entity is high risk to your business and some type of event occurs where it's a business interruption event or a data leakage event, that becomes disclosable as well through you as the public entity.
[39:51] Matt: So, I'm thinking about, in the cybersecurity industry and the vendor community, there is a ton of startups that are almost all now delivering their service from the Cloud. These are companies that are maybe 500 or less, 250 or less employees, but that doesn't mean that they don't have dozens to hundreds of customers that are publicly traded companies using their platform. Like you said, there could be pull through there. Let's talk about the startup community. How do they get ready for this? Because it sounds like they are going to get pulled through in some of these cases.
[40:29] Chris: Yeah, no, totally. I mean, we see it in the defense community as well, through CMMC, and through these other certifications. If you want to participate in government contracting and some type of service in the government, you need to undergo specific certifications. Not to insinuate that a publicly listed company would require a private company to go through CMMC, or some type of certification, but it represents a critical service to the business, and if that potential service is disrupted somehow, and could represent a material exposure to that company, then I would suspect, the private entity is going to undergo increased scrutiny around their cybersecurity program through third party risk assessment processes or some type of audit, they may require SOC1/SOC2 type of assessments that, let's face it, could introduce expense on these private entities, particularly if they're in startup mode, and they're already being pressed, in terms of capital constraints. So, I would expect further knock-on effect to these smaller entities as it pertains to the site and regulatory requirements.
[41:51] Matt: One of the thing that caught my attention in the rule, and I'm sure there's 1000 other things, but one that caught my attention was the new requirement for tagging disclosures in Inline XBRL. First of all, before I get to the rest of question, what is inline XBRL?
[42:05] Chris: Essentially, the format by which you would intake specific disclosure requirements. So, think of it as, HTML has a language, in terms of pulling content and data represented to the browser. The Inline XBRL has specific fields that needs to be completed in order to populate the disclosure system within the SEC, and there are emerging entities, we call filing agents, that run these filings on behalf of companies, and then follow that through the SEC. So, it streamlines the codification of the disclosure process.
[42:54] Matt: That tagging disclosure in Inline XBRL, how does that relate to the 8-k itself?8
[43:00] Chris: That then funnels down into the form 8-k. So, think of it as coding language files through the filing agent, and then that gets populated within the 8-K. The K tends to be what we call more of a description-oriented type of approach. So, it could be a few paragraphs that describes the nature of the risk, the incident. So, it's designed to be more of a narrative type of disclosure.
[43:29] Matt: Alright, so given that required for tagging in that, how does this tactical requirement impact a company's disclosure processes? And again, on the context, especially those with complex Cloud infrastructures and operations, how does it impact that disclosure process?
[43:46] Chris: It's still emerging. If I look at futures here, I would suspect that, again, talking about business intelligence, pulling in a process by which, if you have a Cloud instance, you've tagged specific business processes, tied to specific data, tied to specific Cloud instances, and if you have those predefined threat scenarios that may be introduced, you can create an automated process to create an XBRL form, and then populate that, have it reviewed by your internal security team, your general counsel, your outside counsel, and then it can create more of an automated process. I think we're going to see more automation in this place, but we're very early stage in this process.
[44:39] Matt: All right. So, this is the end of my questions, but is there anything else that you would like to add? Is there anything I missed asking you about, you think would be relevant to our audience?
[44:48] Chris: No, I think you've hit the salient points here. Just realize that this is an iterative process. It's a rule that's really bringing forward further accountability for the board of directors, for the executive suite, including risk management, the financial function, the CEO, the General Counsel, to bring more of a holistic view as to how cyber threats can manifest across the company through the lens of business, operational resiliency, and financial exposure, and while the CISO community might feel exposed, and for good reason, this is an opportunity for you to be ultra-transparent, in terms of where those exposures are, where those vulnerabilities are potentially going to be realized and exploited, and bring in the whole of the team through a comprehensive Enterprise Risk Management construct creates more accountability at the whole level, versus at the individual level.
[46:01] Matt: Chris, this has been super interesting. Thanks for coming back on the show.
[46:06] Chris: Thanks for having me.
Thank you for joining us for today's episode. To find out more, please visit us at Cloudsecuritytoday.com.