Cost-effective Operational Reliable Efficient, C.O.R.E. Technology Security Series
Introduction
Cost-effective Operational, Reliable, Efficient CORE Technology Security is not just a straightforward approach; it's also highly effective. It's designed to manage technology risks specific to each organization without any unnecessary complexities. By focusing on CORE, we set clear objectives and work towards achieving them. With CORE, organizations can achieve 100% accurate asset inventories, proactively manage vulnerabilities, detect threats to each technology, respond to exploits (accidental or otherwise), and maintain business operations while recovery activities are underway. Once CORE Operations are in place, some organizations may further enhance their security programs with a CORE Twin.
It's crucial to note that organizations should follow a logical sequence, prioritizing building their CORE Twin only after CORE Operations and other Technology Security capabilities are 100% complete. This ensures that operations are designed, built, and functioning before the full twin capability is automated, reinforcing the necessity of this approach.
The CORE Security Digital Twin
Digital twins, like the CORE Twin, are virtual models that can simulate the physical world. They allow scientists and analysts to test scenarios without real-world consequences. The CORE Twin follows the security architecture design outlined in CORE. It significantly enhances all inventory, remediation, detection, and decision capabilities in the CORE Operations process, ensuring complete end-to-end, proactive security management. This unique tool can revolutionize your security strategy.
Consider CORE Operations the engine that drives integrated security operations in the real world. In contrast, the CORE Twin operates virtually, enabling planning, prevention, and proactivity. It's a powerful tool that allows for scenario testing and security planning without needing real-world experimentation, enhancing the overall security strategy.
Without a CORE Twin, nearly all technology security decisions are made reactively. This is because security is a supplemental function; it always has been and always will be. Something has to exist as a necessary function before we need to secure it. Also, something has to happen (e.g., the addition of new technologies) before we can determine which security updates to make.
Think of this supplemental concept as a blanket to keep a person’s body warm. The person’s body and metabolic activity are necessary, and the blanket is a supplemental, ancillary function to trap the heat. Just like a blanket can be made with heavier materials to keep it warmer, security can be reinforced to provide more protection. More advanced warming mechanisms can be employed, such as heating and ventilation climate control, extending the scale of the warming environment to include more than just the space within a blanket, a building, let’s say. Security is no different in concept; however, it is much more complex, being more likened to supplementing the metabolic process versus just the warming effects. Scaling up can involve adding automation and encompassing security capabilities, including all organizational technologies and connections. The CORE Twin systematically and virtually represents those organizational technologies to model CORE Technology Security capabilities. It allows for simulation of additions, changes, and deletions, attack simulation, and defensive grit.
CORE envisions this twin as a visual representation of all organizational technologies based on geographical location and connectivity.
The closest description of this concept is similar to the three-dimensional Google Earth concept, allowing for sliding, zooming, and selecting for more detail. It’s essentially a network mapping function, but instead of the “directions” Google Earth feature, there is the connectivity feature. Also, instead of the ability to customize your maps to avoid tolls or take the shortest route, the CORE Twin can map out attack paths and simulate boundary protection effectiveness. On top of that, traffic and accidents (e.g., bandwidth utilization and threat activity) can be represented by near-real-time detection and threat analytics with inputs from CORE Operations. It all starts with the architecture map and all its components.
Paramount Elements of Twin
CORE Inventory, Remediation, and Detection explain technology composition and configuration, which are imperative to understanding remediation and designing the twin virtual model. Therefore, the CORE Twin includes the following paramount elements.
All endpoints, including computers, servers, industrial control systems, networking devices, etc.
All Connections
Serial connections (digital non-routable connectivity)
Wireless serial connections (wireless digital non-routable-connectivity)
Ethernet connections (wired routable connectivity)
Wireless ethernet connections (wireless routable connectivity)
However, this is easier said than done. It hinges on incorporating relevant technology security data into the model. Therefore, we still must incorporate this CORE information as metadata in the twin.
CORE Inventory Data
Organization Characteristics
Critical infrastructure sector
Geographical region
Location
Technology Characteristics
Identification
Hardware
Operating System
Connectivity
Process characteristics
Criticality
Confidentiality
Capability
CORE Remediation Data
Architecture Secure Configuration
Firewalls, Layer 3 and 7
Intrusion Protection Systems
Data Diodes
Endpoint Security
Security Benchmarking (e.g., Center of Internet Security or Security Technical Implementation Guides)
Software Vulnerability Management
Applications and Programs
Operating System
Drivers
Firmware
CORE Detection Data
Add and Remediate
Detect new technologies
Detect vulnerable technologies
Protect and Update
Detecting exposed technologies
Detecting outdated technologies
Retire and Remove
Detecting unsupported technologies
Detecting unremoved technologies
Technologies include all endpoints, routers, network switches, firewalls, etc., typically different brands and configured in many ways. This is why CORE always aligns to standardize technology categorization and remediation through architecture and endpoint security configuration. CORE Detection further ensures that these configurations occur before new technologies are added by detecting new technologies in the CORE Technology Lifecycle. Now, it’s a question of what an organization can do once fully mapped out and prepared to interact with this virtual environment.
Using the CORE TWIN
Security operations should function efficiently and effectively before developing the CORE Twin, so determining the twin's added benefit is crucial. Before examining the Twin’s use cases, let's quickly review the security operations process.
CORE Operations shall be able to perform the following.
New technologies are categorized and added to the inventory before being added to operations.
Operations will immediately identify old technologies and flag them for removal.
Operations will have visibility into networking architecture configurations and be able to manage these architectures over time.
Operations can view current technology configurations to ensure all are remediated.
Operations will be able to identify new software vulnerabilities to prioritize remediation activities.
Operations will detect potential exposures to threat actors' exploitation and prioritize corrective actions through architecture, technology configuration, or vulnerability remediation.
Operations will detect cyberattacks immediately and prioritize remediation activities.
As stated earlier, operations typically function in a reactive mode. Even the planning associated with new technologies is still reactive, as they are added to the operational program once installed. Therefore, the distinction that should be made for CORE Twin is for a proactive mode within CORE Technology Security.
Many organizations may stop at CORE Operations and not invest in a twin. However, for those that are either under constant threat because of their roles in critical infrastructure or those global organizations that have the means, there are benefits to these cases. Here are some examples of uses of a CORE Twin.
Attack path analysis is one of the most common use cases for a security digital twin. Remember, the twin models the exact organizational technology environment virtually. Hypothetical access may occur at any technology or connection, and mappings can be made through the twin infrastructure. This demonstrates where architecture configurations may allow boundary traversal and expected or unexpected access to adjacent networks. This is likened to the Google Maps analogy with the “Directions” feature.
Cyber defense stress testing and analysis may be accomplished with a CORE Twin. In this example, security mechanisms should be simulated to function precisely as they do in the operational environment. An exploitation tool may attempt vulnerability or zero-day exploits, demonstrating the probability of exploitation in the real world. Organizations might find it beneficial to have this capability when threat intelligence suggests these exploits are happening to other organizations.
Security technologies and configurations can be tested in the CORE Twin before changing the operational environment. In this example, a boundary device like a firewall can be configured differently and validated through the connectivity and path analysis functionality. One evaluation criterion could be that if critical endpoints can no longer communicate correctly after updates are made, this will be known before changing the operational environment.
Threat detection mechanisms, technologies, and signatures can be tested for effectiveness. Much like defense stress testing, monitoring capabilities designed to capture and report on nefarious activities should work as intended. The CORE Twin can be used to evaluate the effectiveness of security monitoring capabilities, allowing modifications to be made, proven, and translated to the operational environment without impacting the business.
Demonstration, compliance, and management can all be enhanced with the CORE Twin. This is the virtual model of all technologies and connectivity within the organization. Consider the value of having the ability to generate a model of all parts for the IT or industrial networks at any time, for any reason. This will aid in communicating with everyone from technical teams to executives, making for the best visual aid and technology support team could ever have. Plus, the CORE Twin shall be completely interactive!
There are many more use cases, and with a fully functional CORE Twin, more use cases will present themselves in rapid succession. Now that the use cases and the foundational data have been described, the next step is understanding how to build the twin.
Building the CORE Twin
The most helpful feature of the CORE Twin is a visual representation of the physical inventory with a mapping of all connectivity. A geographic information system (GIS) solution, the Twin, requires a backend database with relevant information for technology security within an organization. This includes a combination of technological and programmatic components. Technological components present the visualization and interaction, the twin itself. This makes up the GIS. Programmatic components provide the modeling design for the twin. This makes up the design of the twin. Before describing the technological components, let’s start with the programmatic components.
Programmatic Components
CORE simplifies the explanation of the twin design by using elements of the System Security Plan (SSP). SSPs are common in the government sector and have been used for decades to document the applied security practices to a single technological system. These documents provide a plan for the security controls to be applied to technologies in layperson's terms. To facilitate the layman, SSPs include a scope and boundaries with clear system descriptions, inventories, network architecture drawings, and an inventory of components.
While this approach works at some level, updating the SSP continuously is impractical, so they quickly become stale and require updates between review cycles. Additionally, CORE focuses on cost-effective security and deemphasizes security controls (e.g., NIST SP 800-53), as these do not add value at a decent cost. The brilliance of the CORE Twin is that it becomes an active, digital representation of the valuable elements of the SSP, rendering the documentation elements unnecessary.
According to the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-18r1, the typical makeup of the SSP includes the following system information.
Name and identifier
Categorization
Contacts (owner, authorizing official, and security responsible personnel)
Operational status
Type
General description and purpose
Environment
Interconnection and information sharing
Applicable laws, regulations, and policies
Security controls
Completion and approval dates
Ongoing plan maintenance.
For more information about the above SSP elements, refer to NIST SP 800-18r1 Chapter 3. For the build-out of the CORE Twin, each SSP element was analyzed to find ways to automate the data collection and management of a virtual SSP.
CORE doesn’t use the exact terminology for system characterization in the CORE Inventory; however, there are direct alignments between the two for the active, necessary elements. For example, the system name, categorization, status, type, purpose, and environment are defined in the inventory and can be found on the CORE Tag and in the Configuration Management Data Base (CMDB), ensuring automation of the CORE Twin when the time comes.
Additionally, CORE Remediation describes the architecture and endpoint security configuration practices that align with interconnection information sharing and security controls from the SSP. Eventually, the completion, approval dates, and ongoing SSP maintenance will become unnecessary technical debt. It can be eliminated using a CORE Twin, making continuous monitoring of the SSP document completely irrelevant. A single system or complete programmatic snapshot can be pulled from the CORE Twin to demonstrate legal and regulatory compliance to auditors and assessors. This leads to the technological design.
Technological design
The CORE Twin's representation comprises only four technological components, making it one of the most simplistic digital twins from a solution development perspective. These include the inventory dataset, the connectivity data set, the geographical information system, and the emulation engine. Three components are commonplace to develop, with the fourth being the most significant challenge. The keen reader may have noticed the method CORE proposed earlier to overcome this challenge, which will be described shortly.
Inventory Dataset
Pulled directly from the CORE Inventory and the CMDB application of choice, the inventory dataset is a straightforward list of data that can be referenced for all technologies in the organization. Additionally, CORE Detection is designed to actively poll the organization’s technology networks and keep the inventory up to date under the watchful eyes of the proposed inventory management team. The inventory dataset will be polled when summarized data are presented in the GIS model, with more data being available upon selection, as shown in the CORE Tag image below.
The graphical representation, as remarkable as it can be, is not solely functional. The user still must be able to zoom, select, and report on whatever scope of the map is selected. This is only the first step to building the Twin.
Connectivity Dataset
Technical teams typically develop network architectures to visually describe and model the networked environment in tools like Microsoft Visio. This is a manual process and can become very difficult depending on the level of detail included in the drawing. Decisions must be made on what to include in the drawing while ensuring its usefulness. Therefore, CORE focuses on two concepts to simplify the drawing and the underlying dataset.
Depict the most usable information in one image at a time. This is called a placemat drawing. Imagine a placemat, including a world map, sitting on the table before you. That map typically includes the names of the oceans, rivers, continents, countries, and major cities. If one were to zoom in on that placemat, then more cities would present themselves, as well as waterways and tributaries. Depending on the zoom level, this map can be overlayed with roads and air traffic like waterways, including the organization’s offices, leased circuits, technologies, and connections.
Connectivity data (maps) primarily come from firewall, router, switch, and wireless access configuration files. This ensures that the CORE Twin is configuration-based, not network traffic analysis. Mirrors the intended and actual environment. Network traffic analysis may enhance connectivity data; however, once the mapping is accomplished, these are used as overlays and for detection. Software products on the market today parse these network device configuration files and graphically depict the physical environment. However, customization is still required to align these depictions with the physical map better and include actual endpoint data. CORE Twin prescribes mapping all connectivity through to all endpoints and resolving those connections in a corresponding connection dataset.
GIS
CORE proposes using the Earth map as a foundation for the visual representation of the Twin. For this to work, mapping data must be correlated with the CORE Inventory and the Twin connectivity dataset to build the drawing. For simplicity's sake, Google provides software for any developer in the Google Earth Studio. Training is necessary to develop using Google Earth, found in the Google Earth tutorials and longitude/latitude mappings. Using this GIS will allow for global connectivity mapping and routing to test out the proliferation of a significant cyber event. Ultimately, and for smaller environments, zooming into a two-dimensional view will still be available.
Emulation engine
Finally, the emulation engine is possibly the most complex component of the CORE Twin. Emulation not only simulates the operational networks and technologies but also the configurations of each device to emulate use cases (e.g., a network attack). The CORE Twin emulation engine is only a concept, including an original design. The foundation for this emulation engine consists of the following principles of functionality.
Principle 1: Start simple and build to encompass all connected technologies. Develop the first emulated environment using one networked environment. Once that environment is built out, add the following scope, then expand as quickly as possible until the entire connected organizational environment is included in the CORE Twin.
Principle 2: Networking traffic simulation must emulate the expected behaviors in an actual environment based on the connected devices' types and configurations. For example, a layer seven firewall should perform differently in the simulation than a layer three firewall, and either should perform differently based on their firewall rule configurations. In another example, a networked web server with two bridged interfaces should perform differently than a database server with two unbridged network connections.
Principle 3: Lightweight mirroring allows for endpoint emulation. From a security perspective, endpoints should be functional in the operational environment. In this sense, the CORE Twin is a virtual server and networking environment that emulates the operational environment without the system resources requirements of a complete clone. This can be accomplished using a virtual hypervisor sandbox and building out actual replicants of the operational devices. However, instead of focusing on storage, memory, computing, and throughput, focus on mirroring the functionality and configuration.
Principle 4: Software vulnerabilities shall be exploitable in the simulation, emulating the way the types of software are supported in the operational environment without exact brand mapping. An example includes a Java-based application that should be compromised by exploits that only apply to Java-based applications. In contrast, Microsoft applications can be exploited only through means that apply to Microsoft applications and do not need to be distinguished to add value. Either web-based application presents the same exploits mitigated by the same general means. The CORE Twin shall allow for the exploitation of the underlying ports, protocols, and services without fully mapping all software vulnerabilities or making them brand-specific.
Summary
Integrating a CORE Twin into an organization’s technology security program should add the necessary capabilities to manage security proactively. However, these capabilities are not available to everyone. Smaller organizations might not return the value based on the costs of the Twin. Larger, more threatened organizations might find this CORE Twin to be precisely the answer to test out new products, simulate cyberattacks, and prevent major incidents from occurring. Since the reality of full, organizational digital twins is limited only to large government and specialized projects, and most are in the experimental phase, CORE prescribes some basic concepts to help technology departments focus on a starting point, with a vision of a usable CORE Twin in the future.
Comments