Recap of Part 1

This is the second of a two-part series on Data Classification. The first part spoke to the fact that most security programs grow organically and in the wake of the growth of the business. This organic growth results in the program being reactive for many years and the prioritization of strong controls that can move the needle, such as MFA, VPNs, and EDRs. Naturally, foundational components such as Data Classification are generally second thoughts.

However, foundational means foundational; a mature Data Classification program is crucial for successful:

• Vulnerability Management
• Threat Management
• Identity and Access Management
• Information Security Architecture
• Risk Management

Policy is the (Relatively) Easy Part

Traditional Data Classification programs start with the basic policy, typically defining the type of data the organization handles, their associated classifications, and general guidelines on how each data type should be handled. Simple examples include:

• Confidential – Data With Restricted Access, Sensitive in Nature, Need to Know Basis
• Internal – Data Restricted to Personnel With Legitimate Business Purpose
• Public – Data With No Restrictions on Access or Usage

Furthermore, most Data Classification policies also define data handling requirements, such as encryption for Confidential data, as well as data retention and destruction schedules. Alternatively, the Data Classification policy may link to additional documents such as Data Encryption or Data Retention and Destruction policies.

But defining data types and associated requirements is only part of the data classification business need. We need to expand Data Classification out to System Classification, generally another policy linked from the base Data Classification policy.

In many environments critical system classification will mimic data classification in that the most critical systems store and utilize the most critical data types, such as electronic medical record systems (EMRs) or enterprise resource planning (ERP) systems. However, this may not always be the case. 

One example that comes to mind from experience is that of ceramic plumbing parts manufacturers; the very first step in this process is arguably one of the most important – putting sand through a process of heating and adding elements to produce ceramic sand. Sand isn't exactly a highly confidential data type, but the inability to execute this first step would likely cripple the revenue generation of a ceramic parts manufacturer for some time.

A ringed System Classification standard is a great place to start, and organizations should group their most critical foundational systems, such as Active Directory and IT and operational technology (OT) network infrastructure, into the most critical system classification: Ring 0. Ring 1 systems would include the non-infrastructure critical systems that rely upon Ring 0 systems, such as EMR and ERP systems and industrial control systems (ICSs), especially for critical infrastructure. Adjust accordingly when cloud systems are involved and may not rely upon the above local Ring 0 systems. Less critical systems that utilize Ring 0 or 1 resources or can be assigned Ring 2 criticality, and so forth.

The below is an example ringed System Classification, your organization's mileage may vary:

Business Impact Analysis

The process of defining an organization's critical business systems is typically part of a BIA in which business unit (BU) or division leadership and system owners define their groups' critical systems that are relied upon most to successfully perform the group's organizational responsibilities. The first action item of a BIA is defining the organization's loss thresholds, a process that starts with financial leadership agreeing upon the maximum financial loss the business could absorb without fundamentally altering the way business is conducted (e.g., securing additional lines of credit, bankruptcy protections, layoffs, etc.).

The second action item is to define the appropriate (by default) semi-quantitative loss ranges from the Severe Rating down through a six-tiered loss threshold rating system. This established set of loss thresholds can then be applied to multiple business functions tied to each critical system. For example, if the above sand processing equipment used to create ceramic sand becomes unavailable for a week due to a hardware failure, how much would the organization likely lose from production delays? Customer support? Cash flow?

Once the organization's loss thresholds have been defined, it is now possible to begin modeling high-level outages and breaches. For example, all operations are halted for four weeks to recover from a successful ransomware attack. How much is the expected loss? What insurances exist to offset losses? What systems should be prioritized during recovery? 

Similarly, say Facility A is down for two weeks due to a mechanical failure. How much is the expected loss of this one facility? Which business systems are affected, and which are not? What systems should be prioritized during recovery?

As we work from establishing data policies through the BIA process and defining of business-critical systems and loss thresholds, we reach the last aspect of the system classification link to data classification, or the foundational ‘final boss’—mapping assets to critical systems. As stated in part one of this two-part series, inventories are another foundational component of a security program that’s generally either overlooked or incomplete. And as the old adage goes, you can't secure assets if you don't know they exist in your ecosystem.

For instance, back to our manufacturing ceramic sand example. In many cases automatic asset discovery is prohibited on OT networks, let alone actual vulnerability scanning, due to older systems potentially getting knocked offline. The 23-year-old ceramic sand machine is run from a Windows XP system, and the IT team likely has no idea that this highly business-critical system is run from an unsupported operating system that hasn't been patched.

Similarly, the supporting assets of a large organization's ERP system may include multiple tens of servers across on-premises and cloud servers, some in VM clusters, some physical hardware, many of which are backed up differently, and most of which haven't had restorations tested. Institutional knowledge is great but will only go so far. 

The Inventory Challenge

There have historically been many barriers to accurate and reliable inventories over the years, including IT/OT divisions, platform specific (e.g., Windows but not Linux) inventory solutions, and even the technology supporting inventory systems themselves. The past few years have seen a very marked improvement with many of the technological barriers, with central inventory solutions integrating with different platform-specific solutions, as well as solutions like vulnerability scanners and EDR platforms. Some come with their own vulnerability scanning built into the platform.

Many of these more recent inventory solutions can define groupings of critical systems and even discover which hosts should likely be mapped as supporting assets. Weights can be applied to critical system groups to delineate between Ring 0 and other outer ring system groups, assisting in the prioritization of activities such as vulnerability remediation, system restorations following an incident, targeted adversary simulation, and higher-level BCP and DR testing.

Additionally, most modern inventory solutions integrate with popular corporate ticketing systems, ensuring audit trails exist and accountability is tracked. And several have started integrating with popular SOAR solutions, further empowering IT and Security teams with valuable automation capabilities.

Of course, corporate political divisions are a different beast. To quote one of my favorite infosec elders, Marcus Ranum: "You can't solve social problems with software."

Final Thoughts

Thank you for reading this two-part series, I hope it has provided some valuable insight. Data Classification has historically been an underrated player in Information Security Program development, but a foundational one, nonetheless. Expanding Data Classification to tie into Critical System Classification, defined in part through BIA exercises, is next in our order of operations. Finally, mapping business-critical systems to supporting assets with modern inventory solutions completes the foundational trifecta that is crucial to security program operations such as Vulnerability Management, Incident Response, Adversary Simulation, and DR/BCP testing. 

If your organization needs any assistance in any of these endeavors, do not hesitate to reach out to our awesome TrustedSec account team.