In my last paper I went over the reasons why conducting a Center for Internet Security (CIS) controls assessment is a good way to build a roadmap for establishing a solid information security program at your organization. This week I’m going to discuss how a CIS controls assessment is conducted, the control categories that make up the current CIS Critical Security Controls (version 8) and the results that you can expect to get from the assessment.

The first step in conducting a CIS controls assessment is determining which CIS implementation group (IG1, IG2 or IG3) your organization should aspire to achieve. For simple organizations that do not have a complex network, and that do not hold sensitive private or regulated data, IG1 may be appropriate. However, for most commercial businesses, implementation groups IG2 and IG3 are recommended. These higher levels of controls offer higher safeguards for private/regulated data and help the organization resist focused cyber-attacks such as ransomware. At this time, the organization also determines the amount of time they wish to allow for reaching their aspirational security goals. This can vary from one organization to the next, but a typical time frame for full implementation is three years.

The next step in the process involves interviewing knowledgeable persons in the organization in order to compare the CIS V8 controls to your current information security measures. The interviewer will question your personnel about each security control and rate your organization’s compliance as:

• Steady-state operational: these are controls that are already being used by the organization and that are included in written policies and procedures. To assure that these controls are in place, the assessor will ask for proofs such as screen shots or records.
• Ad-hoc: these are controls that the organization does employ at least somewhat, but that are not documented or applied systematically.
• Non-existent: these, obviously, are controls that the organization does not employ at all.
• Non-applicable: these are controls that are recommended by the standard, but do not apply to the technology stack or processes that are in use in the organization.

This interview process will probably take 2 or more sessions to complete as there are currently 18 control categories in version 8 of the controls. These include:

1. Inventory and control of enterprise assets
2. Inventory and control of software assets
3. Data protection
4. Secure configuration of enterprise assets and software
5. Account management
6. Access control management
7. Continuous vulnerability management
8. Audit log management
9. Email and web browser protections
10. Malware defenses
11. Data recovery
12. Network infrastructure management
13. Network monitoring and defense
14. Security awareness and skills training
15. Service provider management
16. Application software security
17. Incident response management
18. Penetration testing

In the next step of the process, the assessors will perform written gap analyses of both the baseline security controls (IG1) and the aspirational security controls (IG2 & IG3). These gap analyses will detail percentages of controls that are compliant, ad-hoc, non-existent and NA, and detail the levels of risk that these gaps pose to the organization.

Finally, the assessors will document a detailed roadmap for closing the gaps found during the assessment and meeting the control goals of the organization. This roadmap is typically split into several phases. With a three-year overall timeframe for achieving aspirational goals, these phases will include immediate goals (3-6 months), short-term goals, (6-12 months), intermediate goals (13-24 months) and long-term goals (25-36 months).

These roadmaps are quite detailed. They list the recommended controls to be implemented during each time period. They also list the estimated technical complexity, political complexity and financial cost of implementing each control rated as high, medium or low. Other implementation guidance is also listed for each control as necessary.

As can be seen from this overview, conducting a CIS security controls assessment will provide your organization with a clear understanding of where you are now, where you need to be in the future and what you need to do to reach your security goals. This will bring an end to much of the confusion and frustration entailed in implementing an information security program. It will also give your organization the comfort of knowing that you are working with cutting edge information security controls that give you the most bang for your buck!

No matter what size business or organization you have, in today’s world, the ever-increasing cyber-menace we face affects all of us. To keep our heads above water, all concerns need to have at least a basic documented and monitored information security program in place. For small and medium concerns, how to accomplish this necessary task without breaking the bank can be a truly frustrating and confusing task to undertake.

For one thing, your concern has different information security needs depending on what type of organization you have. Is your network simple or complex? Do you hold or process regulated data such as personal private information, personal health information or financial information? Could compromise of your organization provide a portal for cyber-attackers to gain access to other organizations?

Another point of confusion is provided by the disparate security service organizations, security devices and security applications that are available. How do you know which of these you may need, and how do you pick between the varying offerings? What is the learning curve involved, and will you need extra personnel to handle the increased load? These are all questions that can be very difficult to get a handle on let alone answer decisively.

To help cut the confusion and avoid unnecessary frustration, it seems to me what is needed is a clear path to follow to your security goal. That means finding out where you are now, constructing a roadmap of what needs accomplishing and building a timeline for reaching each step in the process. This is where a Center for Internet Security (CIS) Critical Security Controls assessment comes into play.

The CIS was formed in 2000 with the goal of “making the connected world a safer place by developing, validating, and promoting timely best practice solutions that help people, businesses, and governments protect themselves against pervasive cyber threats.” To accomplish this goal, they publish a list of the most effective security controls available, which are arrived at through a consensus decision-making process of the cybersecurity community. These controls are constantly under scrutiny and are updated regularly. Currently, the CIS Security Controls are in version 8. In this version there are 18 safeguard categories, each with a varying number of individual information security controls to be implemented. These controls are further divided into three implementation groups (IG1, IG2 and IG3).

IG1 controls are those that provide “the basic cyber security hygiene that all organizations, regardless of size, complexity, and regulatory requirements should meet to resist basic attacks and breaches.”

IG2 controls are those at “the maturity level which is designed for distributed organizations with multiple sites, networks, and complex data structures but without regulatory concerns and a significant amount of sensitive data to protect…”

IG3Controls are at “the highest level of maturity, designed for complex environments with access to significant amounts of sensitive data who need to resist focused, well-resourced attacks.”

There are two basic factors that makes this type of information security controls paradigm most suitable for roadmapping the security needs of disparate organizations: The first factor is the effectiveness of the controls, especially when employed as a group. These are the controls that do the job and give your organization the most bang for your buck. The second factor is the granularity of the controls. The three implementation groups allow your concern to plan and implement your information security program in easy bites over a reasonable period of time.

In addition, knowing what you need to accomplish over a period of time allows your organization to choose how you want to implement your program with the end game in sight. This allows you to choose security service providers, devices and application wisely, avoiding unnecessary duplication and waste of resources. The fewer the number of these types of security assets you have, the easier they are to update and protect. This is in addition to the money savings you will incur.

In my next blog, I will describe what a CIS controls assessment entails and the different control categories that are included.

In my last paper I discussed the high level of risk that third-party service providers and vendors pose to organizations. If vendors have a connection to your internal network, or are trusted implicitly by organizational staff, they are a potential risk to private information and services at your business. Because of this danger, it is becoming increasingly important to conduct vendor risk assessments. In addition, vendor risk assessments will produce information valuable to increasing the accuracy of the organization’s business impact analysis. For small to medium size businesses, the goal is producing a useful vendor risk assessment without expending inordinate amounts of time and resources. I will outline below the basic methodology for conducting such a risk assessment.

The first step is formulating questionnaires for both internal employees and for the services providers being assessed. For the internal questionnaires, it is best to question application/vendor owners and subject matter experts. It is also valuable to have the input of IT and security personnel. Some of the information you may want to gain from this effort includes:

• What data and systems does the vendor have access to? How critical to the business are these systems and data? Is the data regulated or sensitive (i.e. PPI, PHI)?
• How does the vendor access these assets (i.e. via VPN, 2FA, simple user name/password)? Is access automatic or must it be enabled before access is granted? Is vendor access logged and monitored? Is there a shared access account used to communicate with the vendor, or is access individual to the employee?
• How critical is the availability of this vendor to business processes? Is the vendor really necessary (Are there other vendors used by the organization that provide similar services to other lines of business, and is it possible to a number of vendors with just one)?
• Has a review of vendor contracts and agreements been performed to see if they meet the organizations security policy and functional requirements?
• Are there periodic reviews of the vendor performed to check on their status in the industry (i.e. financial status, reputation)?

For the external questionnaires, the goal is to gain information about and from the vendor. This information can be gleaned from publicly available sources, user groups, the Better Business Bureau, or you can contact the vendor itself. Some of the information you may wish to collect includes:

• Does the vendor have a SOC 2, PCI DSS, ISO certification in place, or is there other evidence of a risk management program in place?
• Does the vendor support multi-factor authentication mechanisms such as hard tokens, Okta, etc.?
• Is the vendor financially sound?
• Does the vendor have a good reputation in the industry and among users of the vendor service or application?
• Does the vendor have a documented information security program in place that is compliant with the organization security program? Does the vendor perform logging and monitoring of their systems? Do they have an incident response program in place? Etc.
• Does the vendor have a history of security compromises or data breaches?

Once you have the information about the vendors you need, you can apply the regular risk assessment paradigm to them; what threats may menace the vendor, what impacts would the business suffer if the vendor were compromised, how likely is compromise of the vendor? From this you assign the vendor a risk rating, usually stated as high, medium or low.

After the risk ratings have been assigned to all of the organization’s vendors, the risk treatment process can be undertaken. For example:

• Should additional security controls be put in place around the vendor?
• Should a replacement be found for the vendor?
• Is there a way to avoid the risk posed by the vendor to the organization?
• Does the benefit derived from using the vendor outweigh the risk posed to the organization by the vendor?
• Can agreements with the vendor be renegotiated in order to meet the organization’s security and functionality needs?

Although this process is relatively simple, the organization can derive great benefit from undertaking it. In the present business climate, information security cannot be taken too seriously.

We all are a little overwhelmed by the complexity and difficulty of securing our private information against attackers such as cybercriminals and nefarious nation states. It seems that attacks come at us from all sides on a regular basis. One way we cope with this is to outsource our cybersecurity needs to third-party organizations that have staff who perform such services as network monitoring or security patching for a number of client organizations. Another way is to employ third-party security applications that provide such services as email security and data loss protection. We trade our money for their time and expertise.

And there is nothing wrong with that in a lot of ways. The people that form and work for these organizations are able to concentrate their efforts on specific aspects of information security, and often have a great depth of understanding of their particular subjects. Using them or their applications certainly will save you time and can also save you money. However, it is ironic that the very act of allowing such organizations and applications to connect to your networks is a great risk to your private information and systems in and of itself. So, in a way, by trying to simplify your risk management problems, you are actually increasing the attack surface available to cybercriminals, thereby making your cybersecurity problems even more complex and unwieldy.

A big problem is that, despite our best efforts, risk can never be totally eradicated; risk can only be lessened. This is the result of Order and Chaos and the very nature of reality. So even when a cyber-service provider is conscientious and diligent in their security efforts, they can still be compromised. And when they are, there is a good chance that their clients will be compromised as well. Unfortunately, no matter who was responsible for the compromise, you or your organization have the ultimate responsibility for the security of your own information or assets. This creates a no-win situation; you lose, your customers lose, and the service provider loses.

A current example of this is the LastPass hack that occurred sometime in August according to the company. Although details are sketchy, the latest information shows that the breach was massive and exposed encrypted password vaults as well as other user data. The company announced that hackers were able to copy a backup of customer vault data from the encrypted storage container. This means that these hackers have had months to try to guess the master passwords for these vaults. With time, cracking these passwords becomes more and more likely. This creates a huge hassle for clients who now have to change all their passwords and ensure that two-factor authentication is enabled wherever possible. It also has created a huge reputational hit for LastPass. Many information security professionals are even recommending that their clients dump LastPass.

So, what can we do to protect ourselves from the dangers of service provider compromise? The answer is that there is no perfect solution. The best thing we can do is be constantly aware of the situation and put no trust in our hope that the service providers we employ will not be compromised. We need to examine each service provider we use and ask ourselves if we really need the app or service. If we can get by without, then dump that provider. The less service providers we have, the smaller the attack surface we present to the outside world. We also need to do risk assessment of our current and prospective service providers to see how competent and stable they are, and to determine the impact we would experience if compromise did occur. In addition, we need to develop incident response procedures to help us minimize negative impacts that we can foresee, and practice our responses so that we are quick and competent if the incident occurs. Forewarned is forearmed!

Data is the mountain of unorganized fact that inhabits our computer systems and networks. It is analogous to unrefined ore in mining: we mine ore and then process it until we end up with useful metals. Similarly, we mine our computer networks for raw data and process it until we end up with useful information.

It is amazing what information we can glean from seemingly innocent and unrelated facts! People can combine bits of data and deduce who we are, where we live, how we shop, how many kids we have and a plethora of other information that we don’t really want to be common knowledge. This is true not only on the personal level, but on the business and government levels as well. Hence the rise of laws like GDPR, the California Consumer Privacy Act, the Utah Consumer Privacy Act, the Virginia Consumer Data Protection Act and the Colorado Privacy Act. We can expect more privacy and data protection laws from more states and countries in the future. To address these problems, it is very important for organizations to develop and maintain a data management policy and the processes necessary to carry it out.

Among the most important of these processes is data inventorying. A data inventory (or data map) should fully describe the data asset and should include such information as the data’s name, contents, ownership, classification (sensitivity level), retention factors, origin, and other considerations that are important to the organization. Setting up such an inventory may be a daunting task, but once in place, will greatly simplify complying with regulatory requirements and other data management tasks. Along with data inventorying, it recommended that data flows should be tracked. Knowing what data you have and where and how it flows across the network is vital to protecting it.

Another important consideration in data protection is ensuring access to specific data is limited to only those individuals with a legitimate need for that access. This is where access control lists come into play. Access control lists should be strictly maintained and reviewed regularly. It is important to adjust these lists immediately when individuals change jobs within the organization, quit or are terminated. It is also highly desirable to employ strong access controls such as MFA to ensure that the person who is accessing protected data is indeed the person they claim to be.

Another way to protect data is through the use of encryption. Encryption is highly effective in protecting data if it is implemented correctly. Data should be encrypted when at rest and when it is being transmitted across networks. This is especially important in keeping ransomware attacks from becoming devastating. Even if attackers gain access to private data on your system, encryption means they can’t actually read it. This limits their attack to availability only, and eliminates compromise of confidentiality, which can save the organization from regulatory and legal penalties. Strong encryption algorithms should be employed, and a usable and secure key management system should be employed. Encryption keys should be among the most highly protected data assets you have, and ideally should be air-gapped from the rest of the network.

Data backups should be made regularly depending on business requirements of the organization. Backups should be stored in more than one location and should be protected as diligently as information on your production network. Backups of sensitive data should be encrypted and tested on a regular basis.

In addition, access to sensitive data, it’s modification and disposal should be logged and monitored. This should include access to encryption keys and security logs themselves. Protecting and managing data is not easy, but will provide your organization with a bounty of advantages that could help your reputation and save you time and money in the long run.

The Cyber Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA) was adopted in March of 2022 and is an outgrowth of the National Infrastructure Protection Plan (NIPP) that has been around since 2013. What this means to organizations that are covered critical infrastructure entities it that they will be required to report cyber incidents and ransomware attacks to the Cybersecurity and Infrastructure Security Agency (CISA) in a very short time frame. Specifically, these organizations must:

• Report any “covered cyber incident” within 72 hours of determining that the incident has occurred to the CISA
• Report issuance of a ransomware payment to the CISA within 24 hours
• Provide CISA with supplemental information when substantial or new information regarding the incident becomes available to the entity

A question that immediately occurs to one upon reading these requirements is, what is a “covered cyber incident” under CIRCIA? Covered cyber incident under this law must meet any one or all of the following criteria. A covered cyber incident causes or creates:

• “Substantial loss of confidentiality, integrity, or availability” in information systems or “serious impact on the safety and resiliency” of operations
• “Disruption of business or industrial operations,” including service denials, ransomware attacks, or exploitation of “zero-day vulnerabilities)”
• “Unauthorized access or disruption of business or industrial operations” from the loss of services facilitated through or caused by a third-party data hosting provider or supplier

What business sectors are considered critical infrastructure in the U.S.? Critical infrastructure includes the following 16 sectors:

1. The Chemical sector
2. The Commercial Facilities sector
3. The Communications sector
4. The Critical Manufacturing sector
5. The Dams sector
6. The Defense Industrial Base sector
7. The Emergency Services sector
8. The Energy sector
9. The Financial Services sector
10. The Food and Agriculture sector
11. The Government Facilities sector
12. The Healthcare and Public Health sector
13. The Information Technology sector
14. The Nuclear Reactors, Materials and Waste sector
15. The Transportation Systems sector
16. The Water and Wastewater Systems sector

So, how are you to know if your organization is included under this new law? That is being determined now by the CISA. To define a covered entity under the law, they are considering three factors:

1. The consequences that a particular cyber incident might have on national or economic security, public health and safety
2. The likelihood that the entity could be targeted for attack
3. The extent to which an incident is likely to disrupt the reliable operation of critical infrastructure

These criteria not only cover critical infrastructure organizations, they cover organizations that support the security and resiliency of critical infrastructure.

Luckily, organizations in this sector will have some time to get ready for these new requirements. The deadline for the publication of the Notice of Proposed Rulemaking is not until March 15, 2024, and the deadline for issuance of the Final Rule is slated for September 15, 2025. My advice is to take advantage of this time and prepare!

Cyber criminals are finding and exploiting vulnerabilities in programs and equipment faster than ever. For an example, just this week the Cybersecurity and Infrastructure Security Agency (CISA) warned of two vulnerabilities with CVE ratings of 9.8 that are being actively exploited in the wild to attack unpatched versions of multiple product lines from VMware and of BIG-IP software from F5. According to an advisory published Wednesday, the vulnerabilities (tracked as CVE-2022-22960 and CVE-2022-22960) were reverse engineered by attackers, an exploit was developed, and unpatched devices were being attacked within 48 hours of the release. Currently, this kind of rapid exploitation is not at all unusual. This means that to keep in step, organizations not only must monitor all of their IT assets for vulnerabilities, they must patch them quickly and intelligently.

This is where the CISA Known Exploited Vulnerabilities Catalogue (also known as the “must patch list”) can be a real help. It is free to all, regularly updated, and can be accessed at https://www.cisa.gov/known-exploited-vulnerabilities-catalog. What is nice about this tool is that it only includes vulnerabilities that are known to be currently exploited and dangerous. This helps you avoid wasting time and effort patching vulnerabilities that can wait. The catalogue also helps prevent organizations from concentrating too much on Microsoft systems. When you view the current catalogue, you will see exploited vulnerabilities in Apple, Cisco, VMWare, Big-IP, Fortinet, Chrome and IBM just to name a few.

As we have emphasized before, it is very important to track all of your IT assets. That is why maintaining current inventories of all hardware devices, software applications, operating systems and firmware applications on your networks is listed as Job #1 in cutting-edge information security guidance. Once you have a process in place to ensure that your inventories are complete and regularly updated, why not leverage all of that work to inform your patching and security maintenance program? You can simply compare the must patch list with your IT asset inventories and see if any of the currently exploited vulnerabilities pertain to your systems. If they do, that gives you a quick guide on which systems should be immediately patched. Remember that in the current threat environment, speed is indeed of the essence!

Look at the state of cybersecurity now. What a mess! Things have been getting steadily worse now for years and there seems to be no end in sight. Every time we seem to be getting a handle on one new malware campaign another one comes online to bedevil us. The latest iteration is the Log4j debacle. In its wake, the government has demanded that their departments increase their efficiency and timeliness in the patching of their systems. Non-government organizations should take a cue from this and also increase their efforts to patch their systems in a timely manner. It is certain that cybercriminals are not wasting any time in exploiting unpatched vulnerabilities on the computer networks of all kinds of organizations.

One thing to keep in mind in the present environment is that the most serious and far-ranging exploits against computer networks in the last several years are coming from nation states and government sponsored hackers. These groups are developing very cleaver attacks and then striking selected targets all at once. Once they have taken their pound of flesh, they are then ensuring that their exploits are shared with cybercriminals around the world so that they too may get on board the gravy train. That means that organizations that are not a part of the original attack list have some amount of time make their systems secure. But this lag time may be of rather short duration. It would be unwise to simply wait for the next patching cycle to address these virulent new exploits. This means that organizations need to institute programs of continuous vulnerability monitoring and patching, despite the headaches such programs bring with them.

Another thing to keep in mind is that organizations need to ensure that all network entities are included in the patching program, not just Windows machines. All operating systems, software applications, hardware devices and firmware applications present on the network should be addressed. To ensure that all these network entities are included, we advocate combining vulnerability management programs with hardware and software inventories. That way you can ensure that no systems on the network are “falling through the cracks” when it comes to monitoring and patching.

Although perfect patching is not a panacea, and is reactive rather than proactive in nature, it goes a long way in preventing successful attacks against the average organization. This is especially true if your reaction time is short!

There has been a lot of interest lately in formulas for calculating cyber security risk value. That is not at all surprising given the crisis in cyber security that has intensified so greatly in the last few years. Every interest from large government organizations and corporations to small businesses and even individuals are struggling to get a handle on data breaches, ransomware, supply chain attacks, malware incursions and all the other cyber-ills that are besetting us from every angle. And to gain that handle, interests must be able to assign relative value to their information assets and systems. It only makes sense that you provide the highest level of protection to those information assets that are the most critical to the organization, or those that contain the most sensitive information. Hence, the need for the ability to calculate risk value.

The formula for risk value, as it pertains to cyber security, is simply stated as the probability of occurrence x impact. This should not be confused with the formula for calculating cyber security risk, which is risk = (threat x vulnerability x probability of occurrence x impact)/controls in place. As can be seen, cyber security risk value is a subset of the larger cyber security risk calculation. It is useful because it allows the organization to assign a value to the risk, either in terms of the level of risk (i.e. high, medium or low) or the actual cost of the risk (i.e. dollars, time or reputation). The more realistically risk value can be calculated, the better an interest can rate the actual value of an information asset to the organization. In other words, it is the meat of risk assessment.

So, lets take a look at the two factors in risk value and see how we can calculate them. First is possibility of occurrence (or likelihood) determination. According to NIST, to derive the overall likelihood of a vulnerability being realized in a particular threat environment, three governing factors must be considered:

1. Threat source motivation and capability: Is the threat source liable to be interested in the information asset? Can they make money or gain advantage from it? Do they have the ability to get at the asset? Is there known malware or social engineering techniques that may be able to get at the asset?
2. Nature of the vulnerability: Is the vulnerability due to human nature? Is it a weakness in coding? Is it easily exercised or is it difficult to exercise? Is it presently being exploited in the wild?
3. Existence and effectiveness of current controls: What security mechanisms are in place that could possibly prevent or detect exercise of the vulnerability? Have these controls been useful in stopping similar exploits in the past? Have other organizations demonstrated controls that have been effective in countering exercise of the vulnerability?

There is also a handy table for rating the likelihood of occurrence as high, medium or low:

Now let’s look at the other factor: impact. When judging the impact of the compromise of an information asset, we need to carefully consider a couple of factors:

1. System and/or data criticality: What would happen if the information asset was illicitly modified? (Loss of integrity) What would happen if the information asset or system was not accessible or working? (Loss of availability) What would happen if the privacy of the information asset was compromised? (Loss of confidentiality) How much money per time period would the organization lose if the information asset was compromised?
2. System and/or data sensitivity: Is the information asset proprietary to the organization? Is the information asset protected by government or industry regulation? Could compromise of the information asset lead to lawsuits? Could compromise of the information asset lead to loss of reputation or business share?

It should be noted that impact levels can be gauged in two ways: Quantitatively or qualitatively. Judging impact quantitatively means putting an actual dollar value on the successful compromise of an information asset. This type of impact analysis is very useful to business management, but is very difficult to accurately calculate in many cases. In my opinion, quantitative impact analysis works best when the complexity of the system is small. As complexity grows, so does the inaccuracy of the calculation.

Qualitative impact is easier to calculate, and is liable to be more useful when judging impact of complex systems or the enterprise as a whole. Qualitative impact ratings result in levels of impact such as high, medium or low, although I have seen impact level granularity of five or more levels. NIST has a handy table for judging the magnitude of a business impact:

I personally have employed these paradigms and definitions in performing risk assessments for a number of organizations of many types over the last two decades and have found them very useful in assigning both risk value and overall risk to organizations. They help me to be inclusive and clear in in my judgments while operating in a world of complexity and uncertainty.

Here is a new reason to get your cybersecurity incident response program in order: federal banking regulators have issued a new rule requiring banks to notify regulators of “qualifying” cybersecurity incidents within 36 hours of recognition. This rule has the collaboration of the FDIC, the Federal Reserve and the Comptroller of Currency, and will be effective on April 1 of 2022.

It’s not as bad as it seems, though. According to the rule, a computer security incident is defined as an occurrence that “results in actual harm to the confidentiality, integrity or availability of an information system or the information that that system processes, stores or transmits.” However, a computer security incident that must be reported according to the new timeline is one that has disrupted or degraded a bank’s operations and its ability to deliver services to a material portion of its customer base and to business lines. Since this is somewhat nebulous, they also listed a number of examples of incidents requiring 36 hour notification. These include (but are not limited to):

• A failed system upgrade resulting in widespread user outage.
• A large-scale DDoS attack disrupting account access for more than four hours.
• A ransomware attack that encrypts core banking systems or backup data.
• A bank service provider experiencing a widespread system outage.
• A computer hacking incident disabling banking operations for an extended period of time.
• An unrecoverable system failure resulting in activation of business continuity / disaster recovery plan.
• Malware on a bank’s network that poses an imminent threat to core business lines or critical operations.

This same rule also requires banking service providers to notify at least one bank-designated point of contact at each affected customer banking organization “as soon as possible” when the service provider has experienced a computer security incident that disrupts services for 4 hours or more.

Although 36 hours seems like an adequate amount of time for banks to notify the FDIC, in reality this time is very short indeed. From having worked with financial institutions that have had various compromises in the past, we know that determining if the incident is real, determining exactly what happened, when, how and was perpetrated by whom are thorny problems that can take days to figure out. There is also the reality to consider that modern cyberattacks often have multiple stages in which one attack is used to obfuscate other insidious attacks that are launched during the confusion. The regulators have been working with banking industry to try to craft requirements that do not overly burden the affected financial institutions during times of crisis, but who knows how well that will work? Guess we’ll see next spring!