Balancing User Needs with Security Requirements and Risk

06:04:2024

BY Walker Haddock and Spencer Shimko

Difficulties often arise when selecting security controls that can result in reduced performance or useability of your system. In certain situations, addressing security requirements can have undesirable consequences including rendering your system inoperable or making it prohibitively expensive. While it seems feasible to implement a solution that meets the security requirements, it could lead to the acquisition and implementation of a system that is 1. hard to use, 2. under performant, and 3. forces users to seek a way to work around your system.

But first, let’s look back on the journey of security controls.

Security controls: a brief history

Since 1987, multiple laws have passed addressing computer security issues, including Executive Order 13636 which tasked NIST with the Development of a Cybersecurity Framework for protecting critical infrastructure.

In the Computer Security Act of 1987, Congress requested the National Institute of Science and Technology (NIST) to develop standards for the minimum acceptable practices for information system security. This led to The Help America vote Act (HAVA) in 2002, followed by the Cybersecurity Research and Development Act  and the E-Government Act and Federal Information Systems Management Act (FISMA). The Office of Management and Budget (OMB) released the E-Authentication Guidance in 2003.

Increasing cybersecurity concerns led the Executive Office to issue the Homeland Security Presidential Directive 12 (HSPD-12) and the Executive Order 13636 which tasked NIST with the Development of a Cybersecurity Framework for protecting critical infrastructure. NIST developed the Federal Information Processing Standards (FIPS) and the Risk Management Framework (RMF) in response to these laws and executive orders.

In 2017, Executive Order 13800 was issued which led to a revision of the DoDI 8510.1: Risk Management Framework for DoD Systems. The RMF requires the development of a security plan for all systems in the Federal government that are authorized to operate. The NIST 800-53 provides categories of security controls and guidelines for selecting controls to implement a security plan for a system based on a risk profile of confidentiality, integrity, and availability (CIA).

Lack of funding and other security challenges

While working at a university, we encountered researchers that needed to study sensitive information but had not budgeted for the cost to meet the cybersecurity requirements required by their Federal Grants. They would rely on standalone solutions resulting in more challenges due to lack of proper security controls, mainly adequate backup and a sufficient recovery plan. Lack of funding and security challenges to implement sufficient backup eventually led to data loss. On occasion, they could repair their disk drives and recover the data, however the university researchers could not escape the costly recovery fees and delays for publication.

Many of them invested in a personal Storage Area Network (SAN) which they kept under their desk. They would plug them into the campus network exposing their remote management to the Internet and the associated threats present on that network. Challenges continued as they tried to implement adequate cybersecurity controls. By not accounting for proper risk assessment, they still faced losing valuable research data or the expense of recovering the data caused by a storage failure or ransomware. Either way, the university ultimately accrued extraordinary expenses.

Eventually, the university invested in local and commercial cloud solutions for its researchers. They consolidated the management of these resources, developed security plans in accordance with the NIST guidelines, and reduced the impacts from the ad hoc, underfunded programs that had existed in the past.

NIST Risk Management Framework

To avoid unknown risks and reduce the impact of an incident, NIST RMF provides planning tools early in the process, including a list of control implementations which can be mapped to costs allowing for the required budget to be considered early in the project.

In addition to the real-world examples mentioned earlier, other scenarios exist that require weighing the risks, threats, costs, and the creation of a solution that still appeals to users. The NIST 800-53 includes the system and information integrity controls (SI) which help an organization design a security plan to address the threats to their system’s integrity and the information integrity.

For example, the SI-3 control deals with the threat of malicious code. Because malicious code can be delivered to a system through many vectors, it poses a significant threat to the integrity of your system and its information. This control formalizes the approach to detect and mitigate threats posed by malicious code which can lead to risk reduction. However, cases exist where the impact of the implementation of this control is so significant, it compromises mission goals. For example, a High-Performance Computing system where millions of files are accessed concurrently, file access time scanning may introduce an unacceptable degradation in performance. This could hamper its ability to achieve timely execution of processing of mission critical data.

Threat of malicious code to a system

Information systems that run email applications on a web browser connected to the Internet raise the threat and likelihood of malicious code being delivered to a system.

Information systems that run email applications or a web browser on devices connected to the Internet raise the threat and likelihood of malicious code being delivered to a system. It’s why organizational informational systems need to implement SI-3 as effectively as possible.

With systems that do not allow email and are not connected to the Internet, the threat and likelihood of malicious code arriving in the system decreases. For example, if a standalone system analyzes data from sensors attached to a system under test, it’s unlikely the sensor data contains malicious code. Furthermore, if the organization performing the test and collecting the sensor data has also run a risk assessment and implemented a security plan as guided by the RMF, then another organization receiving the file of sensor data may decide to trust the content without performing malicious code scanning. In this case, the using organization would want to perform an integrity check of the file employing a one-way hash function to prove that the file has not changed. This trust is more important for large data sets where false positives of malware scanners can likely occur and the time to perform the malware scanning is very expensive.

In most cases, a system’s policies and procedures should include scanning all data using an approved malicious code scanning tool, one that’s updated regularly according to SI-3(b). The data must be scanned on ingress to the system and on egress from the system as stated in SI-3(a) and SI-3(c.1). The systems themselves should be scanned at least weekly as per the Joint Special Access Program Implementation Guide (JSIG).

This might be impractical in systems with very large data storage like a high-performance multi-petabyte computing parallel file system or a Hadoop Distributed File System (HDFS). Certain data management architectures can also make scanning difficult including object storage or when data is inaccessible to scanners such as when it is encrypted or stored in an unsupported format.

Flaw Remediation, SI-2

Another System Integrity Family control is the SI-2 Flaw Remediation process which includes the scanning of systems to identify vulnerable components, reporting to include the security risk to the system, and the correction of the flaws. SI-2(a) and SI-2(b) require that the software be tested prior to deployment on the production system. The intent is to remediate identified flaws through mitigation techniques such as configuration changes or software updates.

Some scientific software depends on specific libraries and library versions which might be found to possess critical vulnerabilities. Since this type of software must be strictly tested when changes are made in the code base, which include some libraries which they depend on, it may take a considerable amount of time and effort before the flaw can be remediated. Even when the remediation of the flaw gets delayed, a proper risk assessment must be performed, and mitigations put in place to reduce the likelihood of exploitation.

Security-relevant software and firmware updates should be installed within 30 days of the release date of the updates.

The JSIG mandates that security relevant software and firmware updates be installed within 30 days of the release date of the updates. Software flaw remediation is part of the configuration management process (SI-3(d)) and tools that rely on the hashes of files, like Tripwire, advanced intrusion detection engine (AIDE), or File Access Policy Daemon (fapolicyd) will need to move their database forward to match the new configuration.

These types of controls make rapid deployment of remediations a complex and lengthy process in some deployment scenarios. At the same time, it is possible other remediations can play a role in reducing the risk associated with the vulnerability, such as tightly controlled, low risk network environments, effective auditing, and strong physical access controls.

SealingTech and NIST RMF

In summary, the RMF provides a substantial amount of guidance for designing, implementing, and operating a cybersecurity plan according to your organization’s risk appetite, your type of system, and capabilities. Tradeoffs in the recommended control implementation may need to be made to enable your system to meet the user functional requirements and adhere to budget restrictions.

Subject matter experts (SMEs) in technologies such as High-Performance Computing, Data Analytics, Industrial Control Systems, and other specializations need to measure the risk to performance and mission when designing security controls. Systems may be failures if they do not protect the Confidentiality, Integrity, and Availability concerns which are the focus of the RMF tools. However, if the mission cannot be achieved, this will lead to failure as well. We must look for the minimalization of the risk when designing and building systems for these purposes.

At SealingTech, our team of experts and cybersecurity solutions help organizations detect and mitigate risks and reduce the impact of a cyberthreats through NIST RMF. We also assist the federal government in implementing the prescribed six steps of the NIST RMF to ensure compliance as we continuously work to safeguard their systems and networks.

Want to learn more? Connect with a team member today.

Related Articles

Unsupervised Learning for Cybersecurity

Dashboards and automated alerts remain well-established fundamental components of nearly every cybersecurity team’s toolbelt. Peel back the layers of a network monitoring tool suite, and you’ll discover that every team…

Learn More

Operator X: An Intern Experience 

SealingTech’s exciting new innovation Operator X is a chat interface built to assist cyber operators by bridging knowledge gaps via the use of cutting-edge generative AI tools and techniques. It…

Learn More

Training Open-Source Large Language Models for Cybersecurity

Large language models (LLMs) continue to revolutionize the field of natural language processing (NLP). With the success of platforms such as OpenAI’s ChatGPT and Google’s Gemini, professionals in nearly every…

Learn More

Could your news use a jolt?

Find out what’s happening across the cyber landscape every month with The Lightning Report. 

Be privy to the latest trends and evolutions, along with strategies to safeguard your government agency or enterprise from cyber threats. Subscribe now.