#regulation – 370 Security Blog

Security Considerations For M&A and Divestitures

I’ve been speaking to security startups over the last few weeks and some of the discussions made me think about the non-technical aspects of security that CISOs need to worry about. Specifically, things like mergers, acquisitions and divestitures and the different risks you will run into when executing these activities. There are a number of security issues that can materialize when combining businesses or separating businesses and in this post I’ll share some of the things you need to think about from a security perspective that may not be obvious at first glance.

What’s Going On Here?

There are a number of reasons for mergers & acquisitions (M&A) or divestitures. For the past two decades, the tech industry has used M&A to acquire smaller startup companies as a way to collect intellectual property, acquire specific talent or gain a competitive advantage. Divestitures may be the result of changing business priorities, separating business functions for regulatory reasons, eliminating redundancies or a way to sell a part of the business to cover costs. Mergers, acquisitions and divestitures are similar because you will want to review the same things from a security perspective, but it is probably easiest to think of divestitures as the reverse of an M&A – you are separating a business instead of combining a business. Divestitures are definitely less common than M&A in the tech space, but they aren’t unheard of. There are also differences in terms of the security risks you need to think about depending on if you are acquiring a business or separating a business. My best advice is to work with the legal and finance teams performing the due diligence and have a set process (that you have contributed to) so you don’t forget anything. With that, let’s dive into a few different areas.

Physical Security

Physical security is something you will need to think about for both M&A and divestitures. For M&A you will want to perform a physical security assessment on the facilities you are acquiring to make sure they meet or exceed your standards. Reviewing physical security controls like badging systems, fencing, bollards, cameras, fire suppression, emergency lighting, tempest controls (if required), safes and door locks will all help make sure your new facilities are up to standard. If you aren’t sure how to perform this, hire a company that specializes in physical security assessments or physical red teaming.

While physical security for M&A may seems straight forward, there are a few gotchas when performing divestitures. The biggest gotcha is understanding and reviewing the existing access of the people that are part of the divestiture because you will now need to consider them outsiders. All of your standard off-boarding processes will apply here such as terminating accesses to make sure someone doesn’t retain access to a system they are no longer authorized to access (like HR, Finance, etc.).

Things can get complicated if parts of the business are divesting, but not fully. Some examples of this are when the business divests a smaller part, but allows the smaller part to co-locate in their existing facilities. This may complicate physical security requirements such as how to schedule or access common areas, how to schedule conference rooms, how to separate wifi and network access, etc. In the above example, the larger company may act like a service provider to the divested part of the business, but there still needs to be effective security controls in place between the two parts.

Personnel Security

I touched on this a bit already, but personnel security is something to consider when performing M&A or divestitures. With M&A the biggest issue will be how to smash the two IAM systems and HR systems together without punching huge holes in your network. Typically what happens is the two parts operate separately for a while and then consolidate to a single system and the employees of the acquired business get new accounts and access.

For divestitures, particularly if they don’t result in a clean split, you will need to focus heavily on access control and insider threats. Think about how you will separate access to things like source code, financial systems, HR systems, etc. If the smaller company has physical access to your space then you need to build in proper physical and logical controls to limit what each business can do, particularly for confidentiality and competitive reasons.

What’s an example of where this can go wrong? Let’s say business A is going to divest a small part of its business (business B). The complete divestiture is going to take a while to finalize so company A agrees to allow company B to continue to access their existing office space, including conference rooms. However, the legal team didn’t realize the conference rooms are tied to company A’s SSO and calendaring system so company B has no way to schedule the conference rooms without retaining access to company A’s IAM system creating a major security risk. Whoops!

The biggest gotcha is understanding and reviewing the existing access of the people that are part of the divestiture because you will now need to consider them outsiders.

Contracts

Contracts may not seem like a typical security issue, but they should be part of your review, particularly when performing M&A. Why? You are acquiring a business that is worth something and that business will have existing contracts with customers. The contractual terms with those customers may not match the contractual terms of the acquiring company, which can cause a risk if there is a significant difference in contract terms. Smaller companies are more agile, but they also usually have less negotiating power compared to large companies and as a result are more likely to agree to non-standard contract terms. What are some terms you need to think about?

Vulnerability Remediation Times – How quickly did the new company promise to fix vulnerabilities for their customers?
Incident & Breach Disclosure Time Frames – How quickly did the new company promise to notify customers of a breach or incident? I have seen very small time frames suggested in contracts, which are impossible to meet, so I definitely recommend reviewing these.
Disclosure of Security Postures – Does the new company have contractual terms promising to provide SBOMs or other security posture assessments to their customers on a regular basis?
Compliance Requirements – Has the new company agreed to be contractually obligated to maintain compliance certifications such as PCI-DSS, SOC 2, ISO27001, etc.
Penetration Testing & Audits – Has the new company contractually agreed to have their products or services penetration tested or have their security program audited? Have they agreed to provide these reports to their customers on a regular basis?
Privacy & Data Governance Terms – Is the new company required to comply with privacy regulations such as allowing customers have their data deleted, or mandating certain data governance requirements like DLP, encryption, data deletion, etc?
BCP/DR and SLAs – Are there contractual uptime SLAs or response times and does the existing BCP/DR plan support these SLAs?

My advice is to set a timeline post acquisition to review and standardize all of your contracts to a single set of standard clauses covering the above topics. This is usually part of a security addendum that the legal team can help you create. The biggest challenge with contracts will be to “re-paper” all of your customers to hopefully get them on the same standardized contract terms so your security program doesn’t have a bunch of different requirements they have to try to meet.

Accuracy Of M&A’s

One of the biggest risk of performing M&A’s is trying to get an accurate picture of the existing security posture of the company being acquired. Why is this so difficult? The company being acquired is trying to look as good as possible so they get top dollar. They can’t hide things, but they aren’t going to tell you where all the skeletons are buried either. The acquiring company usually doesn’t get a full picture of the existing security posture until after the deal is done and you start trying to integrate the two parts of the business. If you have a chance to interview the existing security team before the M&A closes definitely ask to see their latest audit reports, compliance certifications, penetration testing reports, etc. Consider working with legal to set conditions for how old these reports can be (e.g. no older than 6 months) to hopefully give you a more accurate picture or require the acquired company to update them before the deal closes. Interview key members of the staff to ask how processes work, what are their biggest pain points, etc. Consider hiring an outside company to perform an assessment, or you can even consider talking to one of their largest customers to get their external view point (if possible).

Wrapping Up

M&A and divestitures can be exiting and stressful at the same time. It is important for the security team to be integrated into both processes and to have documented steps to make sure risks are being assessed and addressed. I’ve listed a few key focus areas above, but most importantly standardizing your M&A security review can help avoid “buyers remorse” or creating unnecessary risk to the acquiring business. Finally, having a documented divestiture process and reviewing the divestiture with legal can help avoid security risks after the fact.

Are We Peak CISO?

Let’s be honest…the CISO role is weird right now. It is going through a transformative phase and the industry is at an inflection point similar to what other C-Level roles (like the CFO) have gone through in the past. What makes the role weird? The CISO community and any company that has a CISO is facing unprecedented regulatory pressure, the economy and interest rates have people on edge, layoffs in the tech sector have shaken employee confidence (to the applause of investors) and technology innovation via AI is causing additional disruption and risk across all sectors.

In additional to these external pressures the past few years have seen the proliferation of CISO title sprawl and confusion from companies about how to best employ and utilize a CISO (hint, we aren’t your scapegoats). Despite all of this turmoil, change is also a time for opportunity and there are a few things I think will help clarify and mature the CISO role.

CISO Title Sprawl

I’ve been tracking job titles and job postings on LinkedIn for the past year or so and I’ve noticed a phenomenon I’ll call title sprawl. A quick search for titles shows there are vCISOs, Advisory CISOs, Fractional CISOs, CISOs In Residence and Field CISOs. On top of this, add in Chief Security Officers, Chief Trust Officers and Heads of Security. Do we need all of these titles? Maybe, but I think this title sprawl is more indicative of three things 1) People with CISO titles are in high demand and people want to retain the title once they get it and 2) Companies are still uncertain about how to title and employ someone to lead their security function. 3) Title sprawl is a result of the political power struggle occurring between the CISO role and other C-Level roles (more on that below).

From the titles above there are really only four functions for a current or former CISO – board member (in some capacity), executive management (officer of the company), consultant and sales. There is similar title sprawl and variance with CTO titles, but not to the extent of the CISO title (yet). Time will tell if other C-Level roles start to follow suit, but for now, let’s break down the functional CISO role buckets.

Board Member – These are current or former CISOs who sit on a board either as a technical advisor, business advisor or some combination thereof.

Executive Management – Individuals employed by a company to lead the information security program. May also manage other parts of IT such as identity, privacy, data, etc. Titles may be CISO, CSO, CISO in Residence (for Venture Capital), Chief Trust Officer and Head of Security.

Consultant – These are individuals who are providing their expertise as a current or former CISO to other companies to help them establish, transition or manage a security program. Often the companies employing these individuals claim they can’t afford a full time CISO, but they seem to be able to afford other full time C-Suite titles (hmm…)? Titles may include Virtual CISO (vCISO), Fractional CISO, CISO in Residence and Consulting CISO. (CISO in Residence again because they can “consult” to their VC holding companies about the state of their security programs).

Sales – These are people who are experts in the field of security, may hold one or more certifications and may be past CISOs. Their job is to help the company they work for drive sales. Typically the title they use is Field CISO or Advisory CISO.

Standardize The Reporting Structure

Moving on from title sprawl, companies are also confused about where the CISO title should sit. Some companies advertise it as a Director level role reporting into the VP of some function. Other’s title it as a VP level role reporting into a Senior VP or some other executive. Still other companies have the CISO reporting to the CEO, CIO, CTO or General Counsel. It is even possible this person is an individual contributor. Companies are clearly confused about whether the CISO is a technologist, regulatory compliance specialist or true C-Suite executive. While reporting structure may be a direct reflection on company culture, it is also a public example of the battle for equivalency that is playing out between the CISO and other C-Level roles. Often, CISOs are hired by other C-Levels (not the CEO) and until it becomes more common for CISOs to report to the CEO as an accepted peer to other C-Levels, this confusion and variance will persist. That being said, if you are considering a CISO title and the company isn’t willing to add you to the D&O liability policy then you may be better off taking a lower level title to eliminate personal risk.

Bolster Security Management Certifications

Security certifications from popular organizations talk a lot about regulations, risk and different security concepts (technical or not), but few, if any, offer a comprehensive certification on what it truly takes to be a CISO. Any CISO level certification should include potential career paths that lead to the CISO role, career paths post CISO role, difference in the CISO role based on company size, exposure to business topics in addition to security topics, SEC reporting, interfacing with law enforcement and lastly discussion of how to maximize success based on where the role sits – e.g. reporting to the CEO, CTO or CIO and how that may change your lens as a CISO. This begs the question if there should be a true professional level CISO certification similar to a professional engineer, accountant or lawyer, but let’s save that discussion for a future blog post.

Embrace Increased Regulation

Given the recent increase in regulation, particularly from the SEC, bolstering CISO certifications to include more business acumen may soon be table stakes instead of a nice to have. Recent regulations forcing companies to disclose material cybersecurity events in their 8k filings are starting to accelerate the maturity of the CISO role at publicly traded companies. Companies can no longer fail to invest in security or report breaches (unless they want steep penalties). In particular, this is forcing the CISO role into the board room or at least on par with other C-Level roles because they have to help these companies navigate the decision to report material events in their filings. Existing and future CISOs can embrace this increase in regulation to backstop their authority at companies who are struggling to fully embrace the CISO role as a C-Level executive. While it may not elevate the current role with a promotion, it should at least open the door to the board room and provide a seat at the table for discussion.

While CISO reporting structure may be a direct reflection on company culture, it is also a public example of the battle for equivalency that is playing out between the CISO and other C-Level roles.

The last point I’ll make about regulation is – while the SEC watered down the requirements for cybersecurity expertise on boards, I predict this expertise will still be required and in demand as companies start to navigate the new SEC reporting requirements. In particular, companies may be penalized and eventually required to demonstrate cybersecurity board expertise (via experience or certifications) if they are found to have a material security breach and can’t demonstrate appropriate security governance at the board level.

What’s The End Result?

It is clear the security industry and the CISO role are in a state of confusion as a result of the tight job market, uncertain economy, increased regulation and pace of technology innovation. The net effect of title sprawl and the struggle for equivalency is – it confuses customers, investors, partners, recruiters and job candidates. Title sprawl artificially increases competition for jobs and causes a wide variance in how the CISO role is employed. However, I think this state of confusion is a good thing because it is forcing conversations and causing people to stop and think. The CISO role is the newest member of the C-Suite and it is growing up and trading in the hoodie for a collared shirt. We are starting to claim our seat at the board level and are able to hold our own or make other C-Level roles redundant. As the CISO role evolves from a “nice to have” to a “must have” in the C-Suite, we will see this confusion fade away and the CISO role will truly reach its peak.

Security Theater Is The Worst

We have all been there…we’ve had moments in our life where we have had to “comply” or “just do it” to meet a security requirement that doesn’t make sense. We see this throughout our lives when we travel, in our communities and in our every day jobs. While some people may think security theater has merit because it “checks a box” or provides a deterrent, in my opinion security theater does more harm than good and should be eradicated from security programs.

What Is Security Theater?

Security theater was first coined by Bruce Schneier and refers to the practice of implementing security measures in the form of people, processes or technologies that give the illusion of improved security. In practical terms, this means there is something happening, but what that something is and how it actually provides any protection is questionable at best.

Examples Of Security Theater

Real life examples of security theater can be seen all over the place, particularly when we travel. The biggest travel security theater is related to liquids. TSA has a requirement that you can’t bring liquids through security unless they are 3 ounces or smaller. However, you can bring a bottle of water through if it is fully frozen…what? Why does being frozen matter? What happens if I bring 100, 3 ounce shampoo bottles through security? I still end up with the same volume of liquid and security has done nothing to prevent me from bringing the liquid through. As for water, the only thing that makes sense for why they haven’t relaxed this requirements is to prop up the businesses in the terminal that want to sell overpriced bottles of water to passengers. Complete theater.

“Security theater is the practice of implementing security measures that give the illusion of improved security.”

Corporate security programs also have examples of security theater. This can come up if you have an auditor that is evaluating your security program against an audit requirement and they don’t understand the purpose of the requirement. For example, and auditor may insist you install antivirus on your systems to prevent viruses and malware, when your business model is to provide Software as a Service (SaaS). With SaaS your users are consuming software in a way that nothing is installed on their end user workstations and so there is little to no risk of malware spreading from your SaaS product to their workstations. Complete theater.

Another example of security theater is asking for attestation a team is meeting a security requirement instead of designing a process or security control that actually achieves the desired outcome. In this example, the attestation is nothing more than a facade designed to pass accountability from the security team, that should be designing and implementing effective controls, to the business team. It is masking ineffective process and technologies. Complete theater.

Lastly, a classic example of security theater is security by obscurity. Otherwise known as hiding in plain sight. If your security program is relying on the hope that attackers won’t find something in your environment then prepare to be disappointed. Reconnaissance tools are highly effective and with enough time threat actors will find anything you are trying to hide. Hope is not a strategy. Complete theater.

What Is The Impact Of Security Theater?

Tangible And Intangible Costs

Everything we do in life has a cost and this is certainly true with security theater. In the examples above there is a real cost in terms of time and money. People who travel are advised to get to the airport at least two hours early. This cost results in lost productivity, lost time with family and decreased self care.

In addition to tangible costs like those above, there are also intangible costs. If people don’t understand the “why” for your security control, they won’t be philosophically aligned to support it. The end result is security theater will erode confidence and trust in your organization, which will undermine your authority. This is never a place you want to be as a CISO.

Some people may argue that security theater is a deterrent because the show of doing “security things” will deter bad people from doing bad things. This sounds more like a hope than reality. People are smart. They understand when things make sense and if you are implementing controls that don’t make sense they will find ways around them or worse, ignore you when something important comes up.

With any effective security program the cost of a security control should never outweigh the cost of the risk, but security theater does exactly that.

Real Risks

The biggest problem with security theater is it can give a false sense of security to the organization that implements it. The mere act of doing “all the things” can make the security team think they are mitigating a risk when in reality they are creating the perfect scenario for a false negative.

How To Avoid Security Theater?

The easiest way to avoid security theater is to have security controls that are grounded in sound requirements and establish metrics to evaluate their effectiveness. Part of your evaluation should evaluate the cost of the control versus the cost of the risk. If your control costs more than the risk then it doesn’t make sense and you shouldn’t do it.

The other way to avoid security theater is to exercise integrity. Don’t just “check the box” and don’t ask the business you support to check the box either. Take the time to understand requirements from laws, regulations and auditors to determine what the real risk is. Figure out what an effective control will be to manage that risk and document your reasoning and decision.

The biggest way to avoid security theater is to explain the “why” behind a particular security control. If you can’t link it back to a risk or business objective and explain it in a way people will understand then it is security theater.

Can we stop with all the theater?

What’s The Relationship Between Security Governance and Organizational Maturity?

Organizational and security governance is touted as a key component of any successful security program. However, I’ve been thinking about governance lately and how it relates to the overall maturity of an organization. This has prompted some questions such as: what happens if you have too much governance? and What’s the relationship between security governance and organizational maturity?

What Is Governance?

First, let’s talk about what governance is.

Governance is the process by which an organization defines, implements and controls the business.

Let’s unpack what this means for a security organization. The process of defining security for the business is done through policies, standards and guidelines. Security policies are requirements the business must meet based on laws, regulations or best practices adopted by the business. These policies align to business objectives. Implementation is done through security controls that are put in place to meet a specific policy or to manage a risk. Lastly, controlling the business is done via audits and compliance checks. The security org follows up on how well the business is following policies, implementing controls and managing risk. Control can also include enforcement, which can involve gating processes, such as requiring approval for business critical and high risk activities, or recommending additional security requirements for the business to manage a risk.

Why Do We Need Governance At All?

In an ideal world we wouldn’t. Imagine a business that is created entirely of clones of yourself. There would be implicit and explicit trust between you and your other selves to do what is best for the business. Communication would be simple and you would already be aligned. In this case you don’t need a lot (or any) governance because you can trust yourself to do the things. However, unless you are Michael Keaton in Multiplicity, this just isn’t a reality.

Governance achieves a few things for a business. First, it communicates what is required of its employees and aligns those employees to common objectives. Second, it helps employees prioritize activities. None of this would be needed if human’s weren’t so complex with diverse backgrounds, experiences, perspectives, education, etc. In an ideal world we wouldn’t need any governance at all. The reality is, we do need governance, but it needs to be balanced so it doesn’t unnecessarily impede the business.

How Does This Relate To Organizational Maturity?

Organizational maturity refers to how your employees are able to execute their tasks to achieve the objectives of the business. This relates to things like the quality of code, how quickly teams resolve operational issues or how efficiently they perform a series of tasks. It can be loosely thought of as efficiency, but I actually think it combines efficiency with professionalism and integrity. Maturity is knowing what good is and being able to execute efficiently to get there. There is a fantastic book about this topic called Accelerate: The Science of Lean Software and DevOps: Building High Performing Technology Organizations by Nicole Forsgren PhD.

Which brings us to the relationship of governance and maturity…

There is an inverse relationship between organizational maturity and organizational governance. In simple terms:

The less mature an organization, the more governance is needed.

For example, if your organization struggles to apply patches in a timely manner, continually introduces new code vulnerabilities into production or repeatedly demonstrates behavior that places the business at risk, then your organizational maturity is low. When organizational maturity is low, the business needs to put processes and controls in place to align employees and direct behavior to achieve the desired outcomes. In the examples above, increased governance is an attempt to manage risk because your employees are behaving in a way that lacks maturity and is placing the business at risk.

What causes low organizational maturity?

Organizational maturity is a reflection of employee behavior, skillset, knowledge, education and alignment. In other words, organizational maturity is a reflection of your organizational culture. In practical terms your employees may simply not know how to do something. They may not have experience with working for your type of business or in the industry you operate in. Perhaps they had a really bad boss at a past job and learned bad behavior. Whatever the reason, low organizational maturity is linked to lots of sub-optimal outcomes in business.

How To Improve Organizational Maturity?

If governance and maturity are inversely linked, the question becomes how can we increase organizational maturity so we need less governance? There are a lot of ways to increase organizational maturity. One that is fairly obvious is to start with a mature organization and maintain it over time. However, this is easier said than done and is why some organizations are fanatical about culture. This relates to everything from hiring to talent management and requires strong leadership at all levels of the company.

“The less mature an organization,
the more governance is needed.”

Other ways to improve organizational maturity are through training and education. This is why security awareness and training programs are so critical to a successful security program. Security awareness and training programs are literally attempting to improve organizational maturity through education.

One last way to improve maturity is via process. The security organization can establish a new process that all teams must follow. As teams go through this process you can educate them and reward teams that exhibit the ideal behavior by relaxing the process for them. You can also help teams educate themselves by publishing the requirements and making the process transparent. The challenge with imposing a new process is having the discipline to modify or remove the process when needed, which comes back to governance.

What’s the right level of governance?

The optimal level of governance is going to be based on your organizational maturity and desired business outcomes. In order to determine if you have too much or too little governance you need to measure organizational maturity and the effectiveness of existing organizational governance. There are industry standard processes for measuring organizational maturity, like the Capability Maturity Model Integration (CMMI) and Six Sigma, or you can create your own metrics. Some ways to measure governance effectiveness are:

Ask For Feedback On Security Processes – Are the processes effective? Do teams view them as an impediment or are they viewed favorably? Are the processes easy to navigate and objective or are they opaque and subjective?
Measure Effectiveness Of Security Controls – Are your security controls effective? If you ask a team to do work to implement a security control you should have clear metrics that determine if that control is effective. If you implement a control, but that control hasn’t changed the outcome, then the control is ineffective. This can indicate your governance is ineffective or your organizational maturity needs to improve.
Assess and Update Policy – Security policies should be living documents. They shouldn’t be set in stone. Security policies need to map back to laws and regulations they support and the business requirements needed to be successful. Laws, regulations and business requirements all change over time and so should your security policies. By having up to date and relevant security policies you can ensure your organizational governance matches the maturity of the business.

What Are Typical Scenarios For Governance And Maturity?

There are four scenarios related to governance and maturity:

A mature organization with too much governance – your organization is mature, but you are overly controlling with process and requirements. The net effect will be to slow down and impede the business unnecessarily. You are effectively lowering the organizational maturity due to too much governance.

An immature organization with too little governance – this is a recipe for disaster. If your organization is immature and you fail to govern the organization you will open the business up to unnecessary risk. You will get out maneuvered by your competitors, you will miss opportunities, you will fail to comply with laws and regulations and generally will have a lot of activity without any result. Your employees will lack coordination and as a result your business will suffer.

A mature organization with too little governance – This isn’t a bad scenario to be in. A mature organization implies they are doing the right things and don’t need a lot of guidance. A laissez faire attitude may be the right thing to allow employees flexibility and freedom, but it does come with inherent risk of not being compliant with laws and regulations. It may also mean there is duplication of effort or multiple ways of doing things, which could be optimized.

Governance and maturity are balanced – obviously this is the ideal scenario where your organizational governance is balanced to the level of maturity of the organization. Easy to think about in practice, difficult to achieve in reality.

Wrapping Up

Organizational governance and maturity are inversely related and need to be balanced in order for the business to operate effectively. There are ways to measure organizational maturity and governance effectiveness and by having a continual feedback loop you can optimally align both for success.

Chief Incident Scapegoat Officer (CISO)?

Last week the SEC filed a complaint in the Southern District of New York charging SolarWinds and specifically its CISO, Timothy Brown, with fraud. According to the compliant, the SEC alleges the company and Brown made false statements about its security posture to investors. Along with the Uber CISO, Joseph Sullivan, this is the second CISO in the past year to be specifically charged for failing to do their job. In my opinion, these court cases are going to negatively impact the CISO role and make security less transparent to investors. Let’s dive in.

What About The Other C-Levels?

Both cases are unique, however the first thing that stands out to me is only the CISOs are being named and charged. I find this odd because in an ideal organization the CISO still has to partner closely with the other C-Level execs to achieve security objectives. Things like external messaging to customers, SEC filings, etc. all require the coordination and knowledge of other C-Level execs like the CFO, Legal, Marketing and even the CEO. Why aren’t these individuals being named and charged for also contributing to the fraud?

In the worst case scenario, a CISO is poorly supported and struggles to get any of their security objectives funded or implemented. Is the CISO to blame in this scenario? What about the CEO and CFO who withheld funding? How about the Engineering leader who failed to prioritize the security recommendations of the CISO? The point is, I have never found a situation where a CISO is able to operate in a vacuum and so the other C-Level execs also have a responsibility to make sure the company is making true statements and not perpetrating fraud. They should all be held equally accountable.

Responsibility Without Authority

The CISO role has had a lot of press and a surge in visibility over the past few years, but the role still has a long way to go to be on par with other C-Level roles. It is common for the CISO role to report to the CTO, CIO or Chief Legal Counsel. It is uncommon for the CISO role to have a direct reporting line to the CEO. We can discuss who the CISO should report to, but in my opinion, the CISO role still needs to mature compared to the other legacy C-Level roles. The position is currently not on the same level as a CTO or CIO role and this impacts the scope and authority of the role.

Additionally, most CISOs don’t actually own the things they are trying to improve the security posture of. There is always a business or engineering owner that is actually responsible for building and operating the systems that make the company money. As a result, the CISO role typically ends of with all of the responsibility for security, but none of the authority. If the CISO makes a recommendation to fix something and the engineering leader rejects it, who is held accountable for that decision?

Chilling Effect On Open Discussion

My biggest concern with the SEC complaint is the reference to emails that are pointing out the known security issues with the Orion system. Matt Levine wrote a great article in Bloomberg questioning the SEC’s logic and I agree with his assessments. I have never read an SEC filing or investment statement expecting the company to highlight their massive security investments. In fact, I would question if a company should disclose that in a filing at all (unless it is material) because you may inadvertently provide information to attackers that could be used to hack the company.

Additionally, most security teams openly discuss security issues via chat or email. I find these discussions are almost always expressing frustration with current situations with the goal of gaining support for investment to remedy the issue. However, discussions via chat and email also happen to be legally discoverable forms of communication. This means every single email about how much your security sucks will be taken out of context by lawyers and used against you. The obvious solution is to never put your current security failings in writing, which means you can never create a presentation to convince the company to invest in improving security. Or alternatively, if you do place things in writing you frame them in a way that they are asking for legal advice so they can be protected by legal privilege.

Predictions For the CISO Role

I wrote a blog post after the Uber verdict, but both the Uber and SolarWinds cases have caused significant anxiety within the CISO community, which I think will impact the CISO in the following ways going forward:

New CISOs hiring into a role will require companies to list them on their Directors and Officers (D&O) Liability Policy. Also, based on this Bloomberg Law Article about FTX, I recommend making sure the D&O policy specifies how much you will get if all the executives are trying to use the policy at the same time for legal fees.
It will become standard for companies to cover the costs for legal counsel specified by the CISO, should they be individually named in a lawsuit.
As these cases become more common, CISOs will demand higher compensation and protect themselves contractually to minimize their personal risk.
Companies will (hopefully) prioritize security investments to minimize the risk of lawsuits, regulatory actions or security incidents.
Costs for companies to employ and retain a CISO will go up over time.
In extreme cases, the CISO role may shift from a salaried employee to a consultant (I-9) to offload the accountability for security to the company and protect themselves.

Final Thoughts

I can’t recall the last time I saw a CTO or CIO charged with investor fraud for making false statements about their products or enterprise environment. Yet, the CISO role has been getting a lot of scrutiny from regulators recently. I’m all for holding people accountable, but the CISO role doesn’t seem to carry the same weight as the CTO or CIO. The role still struggles with gaining support and funding to place security first. If a company culture is weak or the other executives minimize security, then the CISO will fail to make any meaningful progress. In my opinion, if the CISO of the company is named, then all the officers should be named to drive home the message that they are all accountable for the security of the company.

Compliance Corner Series: Compliance Landscape 2023

This blog post is part of the Compliance Corner Series developed in partnership with Milan Patel. This series will include a variety of discussion topics around the intersection of security and compliance. The series will include blog posts, live web streams (with Q&A) and video blogs.

“How has globalization, increasing regulatory requirements from governments and industries change how Security and Compliance must operate internally”

Growing Regulatory Requirements – Impact To The Whole Company vs Single Business Unit

Lee – From a security perspective, it is difficult to standardize security controls and baselines across the whole company vs. a single business. Business lines have different requirements, customers and industries, which are unique to their product lines and customer base. Mandating the entire company meet a global regulatory requirement (like PCI-DSS, FedRAMP or HIPAA) can be costly for those lines of businesses that don’t have customers in those industries where these regulations apply. While the security program may be effectively managing risk for their particular line of business, the difference in regulatory requirements can lead to gaps in customer expectations across product lines or lines of business. It can also be costly to maintain compliance programs since you typically have to audit and produce evidence for each product. This puts a burden on development teams and can take time away from improving the security of their products, vs. generating sufficient evidence to pass audits. For smaller lines of businesses this can be difficult to justify the cost to keep up with global regulations, certify audits and maintain levels on par with the rest of the company.

It is possible to centralize compliance activities across the company, but it also requires every part of the company to standardize their security controls, risk management practices and reporting principles. This may work well for small to medium sized companies that have grown organically or who have done a good job of homogenizing their organization. For larger organizations that have grown via acquisition and have dozens of lines of businesses and product lines, centralizing compliance and security activities may be impossible.

Milan – For compliance, the issue is that many of these new requirements have no “corporate” baseline expectations. They have not been translated (and sometimes agreed to), by individual lines of business. Without a standard “bar” to execute against, it’s very difficult for individual compliance teams to attest that it’s being met. In many cases, these items have no tests, or have not even been implemented. It becomes a real issue at scale, as these are yet another new compliance item that engineering will have to meet, which will continue to compete with their feature development time requirements.

My experience is that it’s challenging for many of the central compliance/legal teams (that try to set these requirements for engineering teams), from both a positional authority, as well as a credibility perspective. There are few engineers on these central compliance teams that are experienced with translating these regulations to actual engineering practices. Also, there is a lack of organizational authority to enforce it uniformly across all business groups. This just increases the challenge as it adds more time to negotiate and drive priority, especially with the speed of these incoming regulations.

2. Security and Compliance Practices – What Has Changed?

Lee – For security, there has been an increasing trend in transparency as well as a reduction in time to fix security vulnerabilities and report security incidents. Often these regulations or new compliance practices have good intent, but will be so costly to implement that they are impractical or are technologically impossible. These problems are further compounded by modern software development practices like DevOps that move incredibly quickly and can amplify deployment of internet scale products across cloud providers. Software supply chain security and reporting for compliance reasons is particularly challenging due to the complexity of modern software libraries that have multiple interlinking dependencies. Third party libraries and open source software is even more difficult because you don’t always know if you can trust the source code of that library. Providing an accurate software bill of materials (SBOM) can be a significant burden on the business to develop and maintain for compliance reporting purposes. Additionally, the priority of the business can sometimes take precedence over other activities like solving tech debt or modernizing technology stacks. Technical debt can not only hold back the business from optimizing and becoming more efficient, but can also make security and compliance activities challenging.

Milan – I’ve been doing this for a long time, on the engineering side with a large multi-billion dollar software product, and more recently on the compliance side across many products. What I can say is that while engineering has changed… DevSecOps, updating features/software monthly, instead of yearly… or even every 5 years when hardware went “end of life” (yes, I’m totally aging myself here), compliance practices basically have not changed internally.

Even major companies are still trying to “throw money” at the problem. The internal compliance teams know that the SLT has to pay for compliance… but I believe the days of the compliance “bat” and “blank checkbook” are gone. It doesn’t scale. I will never get more bodies to manually collect and review evidence for large amounts of controls and services (and not regulatory requirements) that we will have to test and account for. Spreadsheets and email won’t work anymore. Compliance needs to change, and be run more like a business. Even the third party auditors didn’t have incentive to be more efficient… remember, they mostly bill hours… So the more inefficient and longer it takes for a company to do an audit, the more money they make. We’ve changed that quite a bit at Oracle, but it’s still early in the journey.

3. Looking Ahead: How Must Security and Compliance Practices Change?

Lee – For security, teams need to shift to a continuous compliance model. Instead of periodically assessing the business once a year (or some other interval) teams need to implement security controls and reporting mechanisms that can automate and continuously evaluate how the security controls meet the various regulatory requirements required for the business. By moving to a continuous compliance model it will force the business to modernize their Software Development Life Cycle (SDLC), modernize their technology stacks and resolve technical debt, which will ultimately benefit security programs. A continuous compliance program will allow security teams to tackle security at multiple points across the technology stack. First, it will evaluate, report and control how software is written. Second, it will evaluate, report and control how infrastructure is deployed and third, it will evaluate, report and control how security posture changes over time so teams can react to security drift.

Security and compliance practices must also change by holding the rest of the business accountable for their decisions. It is impossible for a security or compliance team to be successful without support from the rest of the business because the security and compliance teams don’t “own” the infrastructure and products the business uses to make money. Therefore, there needs to be support at the highest levels of executive leadership to hold the lines of business accountable and tie performance and incentives to how these businesses satisfy their security and compliance requirements.

Milan – Well, I think it must happen on two levels. First level is central oversight and governance.

Without a strong central compliance function that can translate, and negotiate requirements, enforce and govern equally with the engineering leaders, it won’t scale effectively. The main challenge now is that the “fox is guarding the hen house” so to speak. When the engineering team compliance is solely under engineering leaders in the product group, there is the ability (or even just the appearance) that decisions are made without compliance “equality” of decision making. If a compliance item isn’t resolved, who questions whether that amount of risk is acceptable to the senior product leader? Even if accepting the risk is “OK”, any external party can question whether the right level of compliance leadership made that decision, and not just an engineering leader who may prioritize compliance lower than say… a feature request.

This mostly only becomes an issue after the fact. A compliance issue happens, then the questions of “Who made that decision… why was that compliance issue not escalated… etc? Escalate to who? While it’s a great idea that a compliance leader (buried usually multiple levels down in an organization), will be “politically unencumbered” and rise up and strongly disagree with an issue with their senior leader (who by the way signs their checks). My experience is that it can be difficult, as being seen as an antagonist is not great for one’s career in this space. I’ve noticed that compliance positions that have high turnover, this has been one of the main indicators of how effective the compliance leader is in the organization feels they are. If they feel they cannot speak up, or they do and are dismissed “for higher priorities”, they feel they are not effective, or will become the scapegoat if there is an issue.

The second level is that compliance needs to change their success metrics, and run like a business.

Most senior leaders I know, including myself, put everything into three buckets… You’re making money… saving money… or costing money… Compliance has always been seen as “overhead” and costing money. Even today, I’ve had to battle that, until we made some major changes in how we operate, and what metrics we track for success. So the question is, if I’m always seen as “costing money”, how do I change that, and what do I change it to? I realized that while compliance does “make money” (new frameworks open new markets), I don’t really get to claim that. I’m not out there hustling deals… So I realized years ago I could “save money”, but not in the traditional sense. I had to change my compliance principles and metrics. First, everyone accepts that compliance is important, but why did they hate it so much? As an engineer doing this on a large project, the compliance team never understood that my metric was “completing the audit” or “collecting XXX number of evidence pieces”.

My engineering metric of success was TIME.

As a development operations, release manager, and development compliance owner for the large project, I only had so many engineering hours, so I needed to minimize time I spent on each engineering function, including compliance.

So in compliance, I changed the success metric to First Time Resolution (FTR) for audit evidence. Everyone knows you have to collect at least one, but we had so many “kickbacks” for many reasons.. Either the engineering team didn’t provide what was asked for, or the evidence instructions were incomplete or unclear (remember what I said earlier for “billable hours” from the auditors)? I put at least 30 min per kickback. I used to own 1000 pieces of evidence, sometimes I could resolve them in 5 min, sometimes it took days. By raising the FTR up to a goal of 95% (makes it through the first time), I can show, on paper… how much money I’m saving the engineering team (in time). I was able to show this year, saving millions of dollars in audit costs (by going with an efficient auditor, that didn’t bill me for all those hours), and saving Tens of Thousands of engineering hours by eliminating the “unplanned work” of kickbacks.

By changing the metrics to what the engineers care about, it built trust and transparency, and increased the overall value of compliance, plus their willingness to look for more efficiencies.

Needless to say there are a lot more details to talk about for the journey to get here, but the engineering leaders saw, with hard metrics, that compliance “saved money” (via time) for them to use on other features, bug fixing, etc. And more importantly, it built trust with them that the compliance team was a good steward of their currency, which is time.

4. Where do we go from here?

Lee – Milan, it’s been great discussing how we evolved to this state, and some great ideas and positions on what has to change in our respective security and compliance areas. There is so much to discuss here I’m looking forward to continuing this series to dive into topics around the intersection of compliance and security.
Milan – Yes Lee, it’s been great discussing these topics. For me, I feel like this is the beginning of another Industrial Revolution for Compliance, we have seen the change in the engineering and globalization, and we’re on the verge of revolutionizing the Security and Compliance space. We didn’t even really get into the overall governance and continuous security/compliance versus point in time. Maybe that’s the next discussion!

Chip War Book Afterthoughts

I recently read Chip War by Chris Miller and found it to be a thought provoking exploration of the global supply chain for semi conductors. Most interesting was the historical context and economic analysis of the complexities of the current semi conductor supply chain and how the United States has wielded this technology as an ambassador of democracy across the globe. This book was particularly interesting when considering the recent efforts by the U.S. Administration to revitalize semi conductor manufacturing in the United States via the CHIP Act. Even though the U.S. maintains control over this industry, their control is waning, which is placing the U.S. at risk of losing military and economic superiority.

The US Leads With Cutting Edge Design & Research

One advantage maintained by the U.S. is it leads the way with the latest chip design and research. The latest computer chip architectures increase computing power by shrinking transistors to smaller and smaller sizes, roughly following Moore’s Law to double the number of transistors per chip every two years. In the late 1970’s, the United States was quick to recognize the military and economic advantages provided by semi conductors. Overnight, bombs became more accurate and computing became more powerful allowing decisions to be made quicker and spawning an entirely new industry based on these chips. However, as the U.S. began to rely more and more on semi conductors, the cost needed to come down. This was achieved by outsourcing the labor to cheaper locations (mainly Asia), which subsequently made these countries reliant on the U.S. demand for chips. This allowed the United States to influence these countries to their advantage.

A Technology with Geo-Political Consequences

One side effect of outsourcing the manufacturing of semi conductors is the supply chain quickly became dispersed across the globe. Leading research was conducted in the United States, specialized equipment was manufactured in Europe and cheap labor in Asia completed the package. Until recently, most of this supply chain was driven by the top chip companies such as AMD, Intel and Nvidia. However, other countries, such as China, have recognized the huge economic and military advantages offered by semi conductors and as a result have started chipping away (pun intended) at the United State’s control of the semi conductor supply chain.

The US Can’t Compete On Manufacturing Costs

Despite the passing of the CHIP Act, the United States faces a significant battle to wrest chip manufacturing from the countries in Asia (and mainly Taiwan). The cost of labor in the United States is significantly higher than other countries. Additionally, countries such as Taiwan, South Korea, Japan, Vietnam and China have heavily subsidized computer chip manufacturing in order to maintain a foothold in the global supply chain. In order to compete, the United States will have to make an extreme effort to bring all aspects of manufacturing into the country including heavy tax breaks and subsidies. This will effectively turn into economic warfare on a global scale as the top chip manufacturing countries attempt to drive down costs in order to be the most attractive location for manufacturing.

Supply Chain Choke Points Are Controlled by the US and its Allies (For Now)

However, driving down costs won’t be easy. The highly specialized equipment required to manufacture chips needs to be refreshed every time there is a new breakthrough. The costs are tremendous and make it difficult to break into the industry. Instead, the U.S. has been focusing on maintaining control of particular aspects of the supply chain and even blocking acquisitions of strategic companies by foreign entities. The United States also exerts pressure on the countries within this global supply chain to allow it to maintain an advantage. Yet, as new countries rise to power (China) and seek to control their own supply chains, these choke points will dwindle. Additionally, as non U.S. allies (frenemies?) gain market share in the chip supply chain, the U.S. and its allies need to consider the security of the chips they are receiving from these countries.

Final Thoughts

Chip War by Chris Miller is a fascinating look into the history and global supply chain of semi conductors. For the past 50 years the United States has maintained military and economic advantages over its rival countries as a result of semi conductors. However, this advantage has been waning over the past two decades. The CHIP Act is recognition that the United States must begin to claw back some of the globalization of the supply chain and bring critical parts of the industry back to the U.S in order to maintain economic and military superiority in the future.

Proposed SEC Rule Changes For Cyber

In April of this year the proposed amendments to the cybersecurity disclosure rules are expected to be finalized. These rule changes will have change the way companies report cybersecurity in two main areas. First, it will change when and how companies report security incidents. Second, it will require companies to report how they manage and govern cyber security risk. Let’s dive into how these changes will impact companies, the overall industry and how CSOs can help their businesses navigate the changes.

Changes To Incident Disclosure Requirements

The first major change will standardize how companies disclose cybersecurity incidents. These changes will require companies to report a material incident after four business days and provide updates to past incidents for up to two years after. The effects of these changes are expected to make it easier for consumers and investors to evaluate the impact of a security incident and ultimately how well a company deals with security incidents over time.

The long term results of these incident disclosure requirements may mean publicly traded companies begin to see impact to their stock prices as more material incidents are disclosed. The loss in shareholder value will ultimately result in companies investing more in their cybersecurity programs to better handle incidents or recover more quickly with the goal being to maintain investor or consumer trust. Also, requiring companies to disclose incidents within a specific time period may initially result in more lawsuits, which in the long run may force companies to invest more in security to reduce or manage risk.

For a CSO, I recommend evaluating your existing incident response and disclosure plan. Discuss with your legal and finance team about the criteria for declaring an incident, what constitutes a material incident and how to report this information within the SEC timelines. Four business days is a tight timeline for determining what happened, how it happened, the scope of what happened and accurately reporting this within the standard SEC forms. It will also be challenging to comply with the new SEC rules, while at the same time notifying the appropriate partners, customers or consumers so they aren’t learning about it first from the SEC disclosure. This may result in businesses rushing out the disclosure without all of the details, which could erode investor and customer confidence. Or, it could result in the company changing their rules for determining a “material” incident, which might buy them some time to delay the disclosure for more accurate reporting. This will be a fine line to walk and I highly recommend the CSO partner with the Chief Legal Counsel and Chief Financial Officer so they don’t run afoul of the new rules.

Lastly, a CSO will also want to help their organization navigate the risks of these disclosures. It is possible that a company will still be remediating or recovering from an incident when they are required to disclose the incident in their SEC forms. This could disclose details about the incident, the attack and vulnerabilities in a public forum, which could invite follow on or copy cat attacks. A CSO will need to guide their organization how to manage these disclosure risks, while dealing with the ongoing incident. I strongly recommend you run your executive staff through one or more tabletop exercises that runs through various scenarios you may encounter.

Disclosure Of Cyber Security Risk Management & Governance

The second major change will require companies to disclose how they are managing and governing security risk. This will require companies to provide details into their security strategy, security policies and criteria for selecting third party service providers. It will also require disclosure of management’s role and qualifications for assessing and managing security risk.

Overall, I think these changes will have a positive effect on the CSO role. Organizations that previously gave lip service to establishing, funding and governing a comprehensive security program will now be evaluated by investors and consumers in a standardized public forum. Stiff penalties will follow in terms of loss of market value, loss of consumers or even fines from regulatory agencies if organizations fail to adequately meet “industry standard” or investor expectations for security programs.

Additionally, CSOs can now “strut their stuff” by continuing to build, document and lead comprehensive security programs that measure and manage risk. These programs will stand as evidence to the investment and preparedness of the organization to deal with security incidents and manage risk. The new SEC disclosure requirements will allow investors to evaluate and ultimately reward organizations that are meeting expectations for security maturity and resiliency.

Requiring boards and executive management (named officers) to disclose their role and qualifications for assessing and managing security risk will also have a positive impact in how CSOs and security organizations are treated throughout the company. First, it will become common place for organizations to seek seasoned security veterans for a position on their boards. There will be an initial rush to find appropriate talent and in the long term these board positions will become a new career path for former CSOs and security executives.

Second, the addition of security experience to boards will mean CSOs have an ally at the senior levels of the company who understands risk and can help drive conversations around security that would otherwise be glossed over or dismissed. For boards that don’t hear directly from the CSO, security minded board members can explore security topics with their representatives (like the CTO, CIO or Chief Legal Counsel). The end result will elevate security and risk as a topic of importance within board rooms, beyond the current discussions.

Third, supply chain security will continue to receive focus now that organizations will be required to disclose their selection and evaluation criteria for third party suppliers. Publicly traded companies will seek to identify and manage this risk through comprehensive security evaluations of third parties or even developing comparable capabilities in house. Publicly traded companies will also look to limit their liability from third party suppliers and so I expect increased contract language to meet specific security requirements and penalties passed on to the third parties as a result of security incidents caused by them.

Possible Ripple Effects

Overall, I consider these new rules to be a good thing. They will elevate the conversation of cybersecurity risk to the board level and require companies to prove their maturity through standardized disclosures that investors can evaluate. However, there will be some interesting ripple effects as a result of these rule changes.

First, as organizations begin to comply with these rules and disclose aspects of how they govern cybersecurity there will be a chaotic period where publicly traded companies seek to find the line between disclosing too much information and not enough. The industry as a whole will begin to evaluate these disclosures for what is considered acceptable or “good” and this will eventually drive the industry to a steady state where the disclosures become normal or standard.

Second, the third party evaluation and disclosure requirements will have a trickle down effect to the third party vendors (both publicly traded and private companies) because they will be forced to meet the elevated security standards of the companies they provide products or services to. Third party vendors will also need to worry about any new legislation coming out that will hold them liable for security issues in their products and services as specified in the new National Cybersecurity Strategy. This will ultimately raise the bar or maturity for the entire industry, which is a good thing.

Lastly, I expect a niche industry of board level security certifications to pop up that certify executives for board level service. Service on a board as a certified security representative will also be the new resume builder or LinkedIn credential that senior security executives aspire to in the later stages of their career. This may also become an area the SEC chooses to define in the future, such as number of years of experience required to serve on a board, credentials required, certifications, etc.

Wrapping Up

Overall, the new SEC Cybersecurity rules look to strengthen investor and shareholder confidence in the way a company is handling cyber risk or increase transparency around how the company is handling events over the past 2 years, which could become material in how investors view the health of the company. In short, cyber maturity will become another criteria for how to evaluate the performance of a company. Ultimately, these rule changes will elevate the maturity of security across the industry and enhance investor and consumer trust in a company’s ability to manage cyber security risk.

Link to Proposed Rule Changes

Five Take Aways From The New 2023 National Cybersecurity Strategy

In the first week of March, the Whitehouse released the new National Cybersecurity Strategy that outlines areas of focus and investment to “secure the digital ecosystem for all Americans.” Like most strategies, it is high level, broad in scope and forward thinking. Most of the strategy covers expected topics, with objectives like: protecting critical infrastructure, investing in research and development, expanding the qualified cyber workforce and increasing public-private collaboration. However, I found a few of the objectives thought provoking and ambitious because they have the potential to mature or disrupt the industry if enacted into standards or legislation.

Ransomware

The United States has labeled ransomware as a strategic objective that needs attention to prevent disruption of critical infrastructure and other “essential services,” like hospitals. Payments from ransomware support the activities of criminal groups and ransomeware attacks result in not only financial loss, but can result in loss of life through the inability to provide accurate or timely care. Dish Networks is the latest victim of ransomware, resulting in a 20% decrease in stock price, not to mention the amount it costs Dish to recover from the attack, including the loss of revenue from inability to process payments or provide adequate support.

Ransomware is a difficult problem to solve because the government can’t magically secure all of the vulnerable networks and systems in the US. Instead, the US Government plans to target the financial networks that process ransomware payments, disrupt infrastructure that supports ransomware and place diplomatic pressure on countries that continue to provide safe haven to ransomware operations. It will be interesting to see what effect this will have on ransomware attacks, but optimistically, I hope this will have the same result as recent high profile botnet disruptions.

As of yesterday, the administration can claim its first success in taking down part of a ransomware gang in Germany and Ukraine responsible DoppelPaymer and tied to EvilCorp.

Privacy

The Whitehouse considers privacy a strategic objective for the United States. The European Union set the global standard for privacy with GDPR and since then the United States has lagged behind other countries for national privacy regulations. This is evident because several states like California and Colorado have already passed privacy laws that establish fundamental rights to privacy for their residents and there are another three dozen bills in progress across several states in the US. A patchwork of state privacy laws will make it difficult for companies to navigate and satisfy each individual privacy law. Citizens in the United States suffer from poor privacy practices from companies that seek to monetize or use the data for strategic purposes.

There are dozens of privacy bills floating around Congress to address individual privacy, financial privacy, health privacy, and education privacy. These laws would give US Citizens fundamental rights to their privacy, the ability to control how their data is used and shift the collection of data from opting out to requiring consumers opt in to collection. A national privacy law would help consolidate the patchwork of state legislation and make it easier for businesses to navigate the new requirements. It would also place the United States on equal footing with other international standards like GDPR, which has had a significant impact on advertising and marketing business in the EU.

Liability for Third Party Software Security

One of the most interesting strategic objectives in the National Cybersecurity Strategy is the intent to “shift liability for insecure software products and services” to the companies that produce them. This has the potential to mature the technology sector by establishing a standard of security quality through legislation or penalties. The administration intends to do this by establishing a framework that will shield companies from liability if they follow the secure development practices in the framework.

In reality, software development is not that simple. Following a secure software development framework will not address the complex software security supply chain issues facing the technology sector. Use of open source software libraries is a common development practice that accelerates the development of software so companies don’t have to re-develop functions for themselves. This accelerates the software development life cycle and also self regulates by allowing the industry to settle on and standardize certain functions or technologies. While I applaud the sentiment to hold companies liable, it is unclear where the liability stops and this may actually hinder innovation in the technology sector. If a business includes an open source software package in their software are they now liable for the security of a software package they don’t control? Or, does the liability pass on to the random person who built the software package from their basement? Will companies now shift to stop using software they don’t control and develop these capabilities in house, which can waste development resources from producing products and services that generate revenue? What about embedded systems that have limited network connectivity or limited storage space to support continuous updates?

When looking at the history of massive security breaches like Target, SolarWinds, Sony or Equifax, there is certainly a need to hold someone accountable, particularly when the incident impacts consumers, shareholders or critical infrastructure. However, there are too many questions and complexities within existing software supply chains to simply regulate this problem away. I cautiously look forward to seeing how the administration navigates these issues without impeding innovation or levying burdensome penalties.

Federal Cybersecurity Insurance

One of the more interesting strategic objectives is to explore the creation of a Federal Cyber Insurance backstop. The concept is similar to FDIC for banks or disaster relief funds for natural disasters. A government cybersecurity insurance fund could be used to support areas of economic strategic investment that are not mature enough for full blown commercial cyber insurance, but need some sort of financial safeguard. The backstop can also be used for national level services that would have a catastrophic impact to the country if they were impacted due to a cyber event. A federal cyber insurance fund could be meted out like a disaster relief fund to help these critical services restore functionality or shore up finances in a time of crisis. Overall, I think this is a good thing and could provide some stability to the technology sector that is at times beholden to a cybersecurity insurance industry that has high rates and uncertain payouts.

Global Supply Chain

The COVID pandemic broke the equilibrium of a fragile global supply chain. Small disruptions in factory output or the availability of supplies brought several previously stable industries to a halt. As a result, the United States is rightfully considering the security of this global supply chain and what components are critical to maintaining military and economic superiority.

Computer chips are at the forefront of maintaining this military and economic superiority. In 2022 the Whitehouse signed an executive order, called the CHIPS and Science Act, to fund initiatives to make critical supply chain components, like semi-conductors, in the United States. Shifting or changing the global supply chain will take time, particularly with semi-conductors and so it makes sense to start immediately. Almost all of the manufacturing for semi-conductors occurs in Asia (South Korea, Taiwan and China) and it makes sense for the United States to begin to diversify this critical resource from a geographic region that is seeing increasing geopolitical instability. For example, if China invaded Taiwan it would massively disrupt the global supply chain for the rest of the world (including the United States). However, most semi-conductor industries have been built with, or heavily subsidized by, local governments and so the United States will have to match or exceed these subsidies if they truly want to be competitive in the global market, while securing a critical component of the supply chain.

Wrapping Up

Overall, the National Cybersecurity Strategy is a comprehensive and forward thinking strategy that has identified areas of national strategic cybersecurity importance in need of investment. Not all of the strategic objectives are clear on how they will achieve the goal without causing unintended negative consequences, but the intent to improve the resilience and preparedness of the United States is evident.