Cost-effective Operational Reliable Efficient, C.O.R.E. Technology Security Series
Cost-effective Operational Reliable Efficient CORE Technology Security involves only what is required to manage technology risks specific to each organization, no more and no less. By emphasizing CORE, declare the objectives and build to those objectives. Regarding security, CORE enables organizations to have 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. After categorization, CORE Technology Security remediates 100% of the organization’s technologies.
Word to the wise: Organizations should emphasize efforts to complete CORE Remediation once Technology Inventories are 100% accurate. Spend second-round capital budgets on vulnerability management and solutions, where budgets are limited after inventories are complete, on targeted and sustainable remediation.
Technology Composition
All computing technologies comprise common hardware components, software types, and standard protocols. These commonalities allow all technology systems to interconnect and operate efficiently, quickly, and universally.
Vulnerabilities and insecure configurations (security gaps) arise from predisposed conditions in hardware and software and, in many cases, exist to increase usability and ensure functionality. These security gaps exist throughout the system lifecycle, may be remediated or not, and can be exploited at any time.
Remediation includes making configuration changes and installing software fixes that close these gaps. While continuously fixing security flaws might be a burden, this activity is manageable and does not have to hinder the development process or impact operations if done correctly. Before technicians can apply CORE Remediation, it helps if computing technologies are understood and how exploitability occurs first. Start by decomposing technologies to know how to secure technologies through the use of hardware and software remediation.
Computer System Components
Computerized technologies are designed with the same hardware building blocks in principle. These hardware components are configurable and use specialized software. Hardware drivers are software, like operating systems and applications, that can have security gaps, misconfigurations, and vulnerabilities.
Here are some of the most common computer components.
Central Processing Unit (CPU)
Random Access Memory (RAM)
Read-only Memory (ROM)
Motherboard (including integrated circuitry, busses, and expansion slots)
Fixed storage device(s) (Solid State Drives (SSD) or Hard disk drive (HDD))
Removable storage device(s) (USB)
Human Interface Device(s) (mouse, keyboard, touchpad/screen)
Video Graphics Array (VGA)
Wireless network adapter(s) (WIFI)
Ethernet wired adapter(s)
More and more common computer hardware components are being virtualized and becoming software-based. Software configuration and code updates are essential to minimize the risk of exploitation, especially over the wire. Learn how each hardware component can have security gaps closed by either reconfiguration or software updates to understand how to apply CORE Remediation.
How Technology Components Interact
Traditional computers still exist, while cyber has expanded to electronic devices that were not computerized but are now computerized in virtual data centers, The Cloud, mobile form factors, tiny Internet of Things (IoT), and Industrial Control Systems (ICS). Each of these still maintains the essential components of the computer in functionality, at least even where virtualized. Each hardware component in the model below has an input, a function, and an output.
Each of the technology components in the model above has a specific functionality that can be vulnerable to exploitation. It is vital to recognize that some of these components have connectivity with the outside world, away from the computer, while others do not. Therefore, if these off-computer connections did not exist, the technology would not be vulnerable to exploitation over the wire.
This connectivity maps to the CORE Technology Characteristic, Connectivity. CORE Connectivity is based on the Attack Vector Common Vulnerability Scoring System (CVSS) Exploitability Metric. CORE Connection types include:
No connection = Physical
Serial / non-routable only = Local
Routable with trusted networks (i.e., blocked at firewalls) = Adjacent Network
Routable with untrusted networks, accessible to the Internet, IoT, Cloud = Network
Knowing the connectivity per technology is critical to managing CORE Remediation activities; however, start here by identifying where these connections occur on the technologies, as demonstrated in the table below.
Notice that in the table, most of the components are only directly accessible physically and not directly connected to an outside network. This does not mean, however, that they are not exploitable. This means that with physical safeguards, the only other possible attack vector is through one of the Local, Adjacent Network, Network connections, or highly sophisticated indirect means. Indirect exploitation of hardware components must be done through software. Here is a model of how software interacts with each technology component.
When indirect exploitation happens, threat actors utilize software configuration gaps or vulnerabilities in applications, operating systems, drivers, or firmware for all hardware types. This is why focusing on connectivity first is a CORE Remediation philosophy. This philosophy will be explained in further detail later in this text.
Technology Configuration
Secure configuration, or system hardening, can come in two forms. These include hardware (physical modifications) and software (programming modifications). While hardware configurations also include physical and environmental safeguards, exploitability focuses on the connections to access these devices.
By having a physical connection to a technology, exploitation can happen remotely. On the other hand, software exploitation occurs secondary to accessing a technology. This means only by accessing a technology can a software vulnerability be exploited. Therefore, technology-responsible personnel should start the CORE Remediation configuration activities by modeling all connectivity, which is done using a network architecture.
Disclaimer: Assume that another process manages physical security, power protection, and environmental conditions. Each of these elements should be determined before system commissioning under the advisement of engineering teams and operated outside the CORE Technology Security process. Do not dispute this point. Physical security falls under facilities teams and is operated under facilities security plans. Power protection and redundancy fall under facilities teams as well and are managed by power management or facilities teams and, in a crisis, by emergency management. Environmental conditioning is also driven by facilities under teams for Heating, Ventilation, and Air Conditioning (HVAC). Technologies might monitor or control these facility variables and manage those technologies under CORE; however, the variables are collected outside CORE. This is where one line of responsibility is drawn between the security guards and facilities personnel and CORE Technology Security plans.
Start with the Connections
Network architectures represent all physical connectivity to technologies in an organization. The size and number of architectures depend on the complexity and scale of the organization’s technology assets. This can be determined by the CORE Technology Inventories that should have already been accomplished as the number 1 priority in CORE Technology Security. Where inventories do not exist, create them using the CORE Technology Categorization process. For more information, check out https://www.cybersecureot.info/post/technology-categorization-the-key-to-asset-management.
Here is a simplified version of a generic network architecture.
Connectivity and software are core to determining what types of technologies require remediation. Using the example architecture, look at the elements used to determine which Commercial of the Shelf (COTS) technologies to secure.
Here is an example of the technology characteristics listed in the inventory that can be used to determine configuration practices and tools.
Notice that not all inventory attributes are listed (i.e., location, sector, criticality, etc.). Only the above information is needed to determine what is being remediated and how. Remediation prioritization and strategy are essential and will come later. Here is an explanation of how to use each attribute for configuration-related remediation.
Asset ID. This is for identification purposes and will exist in all CORE Technology Security efforts.
Hardware Type. Each technology is remediated and supported similarly to others of the same type.
Service. Each technology is remediated and supported similarly to others with the same service.
Virtualized. Virtualized technologies function the same but are remediated differently than physical technologies.
Manufacturer. Each manufacturer should provide additional security support for its hardware.
Model. Models are used to look up manufacturers’ specific security support options.
Wired. Each wired connection provides a path that should be securely configured.
WIFI. Each connection should be secured; wireless connections have different security configurations and are more challenging to secure than wired connections.
OS. These are the standard COTS software that must be secured on each computer. Secure configuration benchmarks are designed for specific operating systems and OS versions.
Now that the architectures are known, and the characteristics necessary to determine configuration settings have been identified, prepare for configuration remediation. Next, identify if architecture changes are needed for remediation before moving to software configuration.
Architecture Remediation
Remediation of the connectivity to and from technologies occurs outside of the control of changes that can be made directly to the technologies themselves. For this reason, start by looking at the architectural designs of the connections between all technologies and the network architectures.
Most organizations’ technology networks were designed for functionality and performance before security. Security is not wholly absent; however, in these networks, security might have initially included one layer 3 firewall between the organization’s network and the Internet and evolved to include internal virtual local area networks (VLAN) zoning and replacing layer three with layer 7 firewalls.
In any case, there is always room for improvement and additional remediation as technologies and threats continue to evolve. In light of architectural improvements, CORE Remediation includes one of two activities: reconfiguring existing network designs or introducing new network security devices.
Architecture reconfiguration is the most preferred of the two options and should be considered first to prevent unnecessary, costly purchases. However, there are situations when organizations deem that having two networks with different criticalities on the same physical device is an unacceptable security risk. Therefore, new hardware purchases might be necessary. The following includes examples of each type of architecture remediation.
Architecture Secure configuration
Architecture secure configuration includes modifying networked devices and how they are individually connected to make the overall architecture more secure. This is a different activity from security benchmarking, which will be described in the next section due to being from the perspective of the network as a whole instead of one individual device.
An example of reconfiguration includes the router in the snippet image below, number 9 in the red box.
In this example, network engineers discovered that Router 9 allows routing between the green CRM_NET, amber PLT_NET, and blue IOT_NET. Upon further investigation, it was determined that routing the IOT_NET to the other networks created a security risk. Furthermore, operational personnel confirmed no functional requirements for those routes. A reconfiguration work order was processed, and the network engineers removed routes between blue IOT_NET and the other networks. Now, the network is more secure without purchasing new technologies or additional security hardware.
This was both a simple example for this text and also a simple fix in reality. Unfortunately, reconfiguration is not always an option and does not provide the same level of security as adding a new security device to the network.
Network Security Devices
Network security devices provide a physical and logical boundary between networks by restricting data from being transferred in one, two, or multiple directions. Otherwise known as guards, common network security devices include, but are not limited to, the following and descriptions of each.
Firewalls. The Layer 3 (L3) terminology refers to the Open System Interconnect (OSI) Network layer. At layer 3, only internet protocol (IP) routing is restricted. The firewall does not have the capabilities to block, analyze, or restrict application-specific traffic, limiting its protection capacity. Another type of firewall, Layer 7 (L7), can analyze packet data and determine what occurs at the Application OSI layer. This is ideal for network security management as it provides more security functionality and visibility into what type of traffic is traversing an organization’s networks.
Intrusion Prevention System (IPS). IPS is similar to the L7 Firewall because it can function up to the OSI Application layer. An IPS, however, is designed to detect and proactively block possible cyber attacks over allowed connections.
Data Diode. A unidirectional gateway, data diode, physically isolates the two connections, input and output, for transmission in one direction only. This type of device is ideal to ensure that external connections are explicitly restricted. This device functions at the physical layer, protecting all other activities from outside intrusions by disconnecting either the outbound or inbound connection completely.
Using the same network example, the organization decided that the reconfiguration of Router 9 alone was insufficient to mitigate the risk of a cyber attack over the network. One of the security devices listed above was to be installed between the Plant network and Router 9. An L3 firewall was deemed appropriate based on a cost-versus-benefit analysis. The organization believed all other devices would have a premium cost over the L3 firewall. The firewall (Firewall 16) was installed in-line between Router 9 and Network Switch 8 to provide additional security between the Plant network and the less secure Control Room and IOT networks.
Note that in this example, the Router 9 reconfiguration was still applied to ensure routing was not allowed between each network. This is also an example of defense in depth, including both CORE Architecture Remediation techniques, Architecture Reconfiguration, and Network Security Devices.
End with the Endpoints
Even today, system vendors typically deliver their technologies with a blend of security and performance configurations that favor functionality and usability over security. This does not mean that these technologies cannot be configured more securely and, if done correctly, with minimal impacts on performance and functionality. Each technology-responsible team should identify a secure configuration technique that works best for their organization and a plan to deploy it.
CORE Remediation encourages using secure configuration guidelines, otherwise known as security benchmarks. Security professionals and organizations design security benchmarks to enable technology response people to reconfigure common software platforms using preexisting security settings that are typically not enabled on those technologies. These benchmarks exist for standard operating systems, software utilities and tools, databases, web servers, virtualization platforms, networking technologies, and many, many more.
SECURITY BENCHMARKS
CORE Remediation supports primary sources for secure configuration checklists for most commercial off-the-shelf (COTS) software solutions, the Defense Information Systems Agency (DISA) Secure Technical Implementation Guides (STIG), and the Center of Internet Security (CIS) Benchmarks. Commercial organizations will find that the CIS Benchmarks are more appropriate for their endpoints and technologies because they were designed for non-military computing technologies and have a wide array of available Cloud-based, preconfigured server images. In comparison, government and military organizations will rely almost solely on the DISA STIGs.
CORE Remediation does not compare DISA STIGs to CIS Benchmarks or vice versa. Instead, it suggests reviewing the lists of supported technologies from DISA and CIS and comparing them to CORE Technology Inventories to decide which is best for the organization. Additionally, CORE Remediation does not allow for using any security benchmarks other than DISA and CIS, as this will add to the complexity of security management and does not meet the intent of CORE Technology Security, as stated in the opening. Finally, DISA and CIS offer benchmarks that can be actively integrated into automated tools for both scanning and remediation, making them ideal for configuration management.
Disclaimer: Security controls (i.e., National Institute of Standards and Technology Special Publication 800-53, etc.) are not considered a requirement for CORE Remediation. It has been observed that many organizations make the mistake of mapping configuration settings to these security controls, causing increased administrative burden with zero security benefits and wasting time and money managing security compliance programs. Unfortunately, many governments use this scholarly configuration to control the mapping approach. They are beginning to realize it wastes time, effort, and money with no added security benefit. Companies that provide these mapping and compliance services contribute to the waste, usually unintentionally. Put them out of their misery and leave this mapping exercise out of organizations. Instead, apply as many security settings as possible without breaking the systems, then decide if different but equivalent technical mitigations are needed where configurations cannot be changed. Finally, if the mitigations cannot be automatically applied and checked through automated solutions, remove them from the benchmarks and manage the deviations through the configuration management process, hard stop.
Security Configuration Management
Organizations that have never applied security benchmarks should anticipate additional testing and evaluation before making these configuration changes to endpoints, applications, and networking devices, and it will take time to do it correctly the first time. Once the strategy has been determined, operational testing has been completed, maintenance windows are scheduled, configurations applied, future downtime will be lower, updates will be easier to manage, performance and efficiency will be optimized, and security postures will be maximized.
Determine which security benchmarks are required using the CORE Technology Inventory, as shown in the example below.
The following generic list of benchmarks can be made by looking at the inventory above.
Once the list has been made, download the appropriate benchmarks and introduce them into the security configuration management process. There is no need to add the benchmark name to the CORE Technology inventory as that mapping can be automated with inputs from the Configuration Management Data Base (CMDB) to the CORE Remediation process solution.
Disclaimer: Notice that real operating systems and benchmark names are not used, as this example is highly generic. However, this highlights how benchmark determinations can be made and that there are some technologies where specific benchmarks do not exist. In this example, media converters, servos, Industrial Internet of Things (IIoT) sensors, and programmable logic controllers (PLC) all use some version of an embedded Linux operating system. Because these unique technologies exist, CIS and DISA support “generic” operating system checklists that the organization can use for secure configuration. Thereby following the configuration management process to determine how to apply each benchmark and the settings in those benchmarks to customized endpoints.
Here is an example of a security configuration management workflow courtesy of CORE Remediation.
Notice the black box processes on the right to update the automated or manual tools. While vendor agnostic, CORE Technology Security recommends using an automated tool that supports all the CORE Remediation practices. The primary reason CORE Remediation includes only the practices listed in this document is that these practices are sufficient to manage technology hardening, and multiple automated tools in the market support the benchmarks listed here and the software vulnerability identification and patching, which will be covered in the next section.
Disclaimer: Finally, the security configuration management process is complete in this form. In the next section, the software vulnerability management practices will be defined. Software vulnerability management is a highly automated process that identifies the software on an organization’s technologies. Therefore, security configuration benchmarks that apply to the software, in addition to the core operating system itself, may follow the same process as listed above but will be listed in the software tool versus the CORE Technology Inventory. It is recommended to align secure configuration and vulnerability management processes and deployment schedules whenever possible.
Software Vulnerability Management
Identifying software vulnerabilities and remediating those vulnerabilities quickly is at the heart of CORE Remediation. The reason this component is listed after secure configuration is that it focuses and relies heavily on automated tools to be effective. It also leverages what was explained in configuration management to highlight how to automate all CORE Remediation processes. This starts by explaining vulnerabilities.
Technology vulnerabilities exist due to predisposed conditions that exist in software and connections, internally and externally. These predisposed conditions exist, as explained in the Technology Composition section because computerized technologies have common computing components, communication protocols, and software coding platforms. The OSI model is perhaps the simplest way to explain where technology vulnerabilities get exploited, as shown below.
If functioning adequately, each technology component should not be vulnerable to each of these examples. There are dedicated teams, both malicious and non-malicious, actively seeking new and exciting ways to exploit technologies and software. Here is a list of the typical software components targeted for these activities.
Applications and Programs
Operating System
Drivers
Firmware
The following databases are the two most common vulnerability repositories.
CVE.org, managed initially by the MITRE corporation, is the most comprehensive cybersecurity vulnerability database known to exist. At the time this was published, there were over 215 thousand known vulnerabilities that existed for thousands of different technology platforms.
Nvd.nist.gov is the United States government repository for cybersecurity vulnerabilities. This database includes additional mappings to NIST and other government identification tools, making it easier for US Federal agencies to integrate the National Vulnerability Database (NVD) into their automated processes.
Vulnerability Scoring
Vulnerabilities are scored for criticality using a 1–10-point scale from lowest to highest following the Common Vulnerability Scoring System (CVSS) to prioritize remediation activities. CVSS’s current (at the time of this writing) scoring criteria include Attack Vector, Attack Complexity, Privileges Required, User Interaction, Scope, Confidentiality, Integrity, and Availability to determine the base score for a vulnerability. In addition to base scoring metrics, CVSS includes Temporal metrics analyzing Exploit Code Maturity, Remediation Level, and Report confidence to help organizations further prioritize based on what is known about exploiting vulnerabilities when they are recorded. Organizations might find Environmental metrics helpful as well for managing vulnerabilities in their environments.
Disclaimer: CORE Technology Security provides detailed instructions for using the CVSS scoring exploitation, temporal, and environmental metrics to determine exploitation difficulty, patching schedules, and all other security prioritization efforts for an organization’s technologies in CORE Prioritization. This activity is outside of the scope of this document.
Both CVE.org and Nvd.nist.gov use the CVSS process for determining the criticality of vulnerabilities.
Discovering Vulnerabilities
Automated vulnerability discovery has existed for over two decades and will be considered the only method covered in Core Remediation. These scanning tools include original equipment manufacturers (OEM) software and operating system utilities like Microsoft Windows Server Updates Services (WSUS) and Linux versions like Debian’s Advanced Package Tool or Redhat’s Yellowdog Updater Modified, to name a few. However, for Core Remediation, organizations require a vulnerability scanning utility to capture a complete view of all software and component vulnerabilities in their networks. These 3rd party vulnerability scanners can discover vulnerable ports, protocols, and services over the network both passively and actively by authenticating to the end devices.
Passive vulnerability scanning
Passive scanning is accomplished locally on a computer or over the network without authenticating via approved user credentials, i.e., username and password. This method has the benefit of a quicker setup time, easier use, and provides a view of vulnerabilities that an unauthenticated hacker could potentially exploit. Typically, with a passive vulnerability scanning tool, one can see vulnerable network connections and identify which IP addresses are used versus unused. Unfortunately, without authenticating the endpoints, passive scanning falls short when attempting to discover software vulnerabilities.
A passive vulnerability scanner alone is not sufficient for vulnerability discovery, according to Core Remediation.
Active Vulnerability Scanning
Active scanning is accomplished locally or over the network with a valid administrative account, having full privileges on the endpoints. Active scanning provides the results of the passive scan by adding all vulnerable software, including operating systems, drivers, utilities, and firmware. This method does take longer to set up, requiring administrative accounts on all endpoints, is best managed using domain security groups, and should be safeguarded in a privileged network zone or equivalent to prevent unwanted network users from intentional or accidental access to the scanning server.
Only with an active vulnerability scanner can an organization meet the CORE Remediation recommendations.
Disclaimer: Many penetration testing companies include vulnerability scans as a penetration test. This is a misnomer. A vulnerability scan only identifies vulnerabilities as a penetration test attempts to exploit those vulnerabilities. For CORE Remediation, a penetration test is not required.
Vulnerability Management
Once the vulnerabilities are discovered, organizations employ a vulnerability management process to apply the software updates necessary to patch the vulnerability gaps as quickly as possible. As noted earlier, there is no need to list the vulnerable software in an inventory as this adds little to no security value. Instead, the vulnerability scanning results should be aligned with each Asset ID, and each Asset has already been characterized in the CORE Technology Inventories for prioritization purposes. Additionally, technology-responsible personnel should align vulnerability management activities with security configuration management wherever possible. For this reason, the workflows look similar.
Here is an example of a vulnerability management workflow courtesy of CORE Remediation.
Notice the black box processes on the right to update the automated or manual tools. While vendor agnostic, CORE Technology Security recommends using an automated tool that supports all the CORE Remediation practices. The primary reason CORE Remediation includes only the practices listed in this document is that these practices are sufficient to manage technology hardening, and multiple automated tools in the market support the benchmarks listed here and the software vulnerability identification and patching, which will be covered in the next section.
Disclaimer: Finally, the vulnerability management process is complete in this form. Software vulnerability management is a highly automated process that identifies the software on an organization’s technologies. Essentially, software is too dynamic and ever-changing to manage in a software inventory; there is no security value to be gained by documenting software in an inventory, and software inventorying outside of vulnerability management is not supported by CORE Technology Security.
Full CORE Remediation Automation
CORE Remediation includes architecture secure configuration, network security devices, endpoint secure configuration, vulnerability scanning, and vulnerability patching. This CORE Remediation concept is cyclically automated and creates a clearer picture of security issues and statuses in an organization’s networks. The automated process and logic used to decide on a tool or tools are as stated below.
All network architectures must be evaluated to ensure they are secure. Therefore, the automated tool must be able to map out network architectures by device, identify security gaps, and provide a report with this data.
Network architectures may be reconfigured, or new network security devices must be purchased. Therefore, the automated tool must provide sufficient information to determine if reconfiguration alone can remediate the security gaps.
Endpoints must be evaluated against CIS or DISA benchmarks for the technologies listed in the CORE Technology Inventory. Therefore, the automated tool must support scanning the organization’s technologies and the benchmarks of choice.
Benchmark settings might require modification to avoid functional impacts. Therefore, the automated tool must support benchmark modifications.
Endpoints must be securely configured against CIS or DISA benchmarks for the technologies listed in the CORE Technology Inventory. Therefore, the automated tool must support the remediation of the organization’s technologies and the benchmarks of choice.
Networks and endpoints must be passively scanned for common vulnerabilities. Therefore, the automated tool must support passive (unauthenticated) vulnerability scanning.
All technologies must be actively scanned for software vulnerabilities. Therefore, the automated tool must support authenticated scanning.
Active scanners will use administrative accounts and passwords to perform functional scans. Therefore, the automated tools must support secure mechanisms for storing credentials.
All technologies with software vulnerabilities must be patched as efficiently as possible. Therefore, the automated tool must be capable of applying software patches.
CORE Technology Inventories provide scanning and hardening lists. Therefore, the automated tool must be able to import inventories from the Configuration Management Database (CMDB) used by the organization.
CORE Prioritization requires consolidated mappings of security gaps and vulnerabilities to the CORE Technology Inventories; therefore, the automated solutions must provide the capabilities to export vulnerability information.
Here is an example of an automated remediation tool checklist courtesy of CORE Remediation.
When functioning adequately, the remediation cycle should appear as depicted below.
Summary
This write-up included the second step to managing technology risks in an organization. With the CORE Remediation practices learned here, organizations can focus on efficient, effective, and manageable protective actions while simultaneously building automation into the overall CORE Technology Security program. The output of CORE Remediation is only the fundamental tasks necessary for technology hardening and to get the job done.
Comments