Complexity and Reliability are Strange Bedfellows

Complexity, Reliability and Safety in a Future Complex Weapon System - Will it be as Reliable? 

Today’s ICBM command and control system is simple compared to current technological command and control capabilities. If you look at fault trees attempting to identify the outcome of all possible failures in a command and control system, then use that analysis to determine all the permutations of failure paths that have the outcome of an accidental launch or the inability to launch a missile, you can calculate probabilities for such system failures to occur. By computing the product of individual failure probabilities, one achieves a probability number for the overall fault path. Unfortunately, this leads to what most scholars concede is an unrealistically low probability of failure, due in large part to the difficulty of determining the interactive complexity of the system and the ‘coupling’, the impact a failure may have on the probability of another failure. The failures are not truly independent events. Then summing the probabilities of all the fault paths provides an overall probability of failure, which again, is unrealistically low.

Using the same fault tree approach for a more complex system, such as a future ICBM, the identifiable population of failure modes is very likely to be much greater, simply for no other reason than the system will be more complex (have more parts/failure paths).  Whether the sum of probabilities of the increased number of fault paths can be maintained acceptably low is undetermined.  I believe ‘undetermined’ is a generous statement. Experience with other complex systems doesn’t encourage me that we can accomplish an overall probability of failure that is lower than today’s ICBM.  The increased complexity means the number of fault path permutations increases greatly.

So, unless the designers can do something to reduce the complexity, the overall probability of failure would be greater.  The designers are very aware of this and are some of the best minds in the country.  The trick will be to try to design the system such that failures that might result in accidental launch or inability to launch is actually a smaller population, i.e., using some design concept such as an automated fault correcting system.  But then the complexity increases even more.  This is why I use the whimsical example of two Campbell’s Soup cans and a string for a NC2 network.  The logic reads ‘the simpler the system, the safer and more reliable it is’. Maybe by isolating the critical paths used to launch and making them as independent from the remainder of the system as possible, the number of fault paths could actually be reduced.  Of course, these points can be debated for days, but I think burden of proof lies with the more complex system to prove it’s comparable and hopefully, safer and more reliable, than the less complex system.   Unfortunately, if it isn’t, we have increased the risks when we deploy such systems.

DoD Nuclear Weapon System Safety Concepts

Posted by Ronald Gault, March 3, 2015

The DoD nuclear safety programs extend from the initiation of a nuclear weapon’s development cycle through the demilitarization and retirement of that nuclear weapon system. Documented nuclear safety design features are incorporated into the weapon system design and a nuclear certification process is employed to evaluate the overall satisfactory implementation of these requirements, and ensure they are met throughout the weapon system’s life cycle.  Nuclear safety design certification is granted based on the acceptance of the design/test data by a Nuclear Weapon System Safety Group and the Secretary of Defense’s office after their study efforts.

1.0  Nuclear Safety Philosophy

DoD documentation states, “due to their awesome destructive capability, nuclear weapons must be designed, developed, produced, fielded, and logistically supported with consistent, stringent safety provided”.  Obviously, there are cost and operational factors involved which must be considered.  The designer must strive for the objective of maximizing nuclear safety consistent with operational and cost constraints, ensuring that cost and reasonableness are considered as factors in the implementation of safety.  It is the responsibility of the DOE and DoD project managers to ensure that the acquisition programs they conduct meet requirements for nuclear safety.

Although a somewhat philosophical assumption, it is generally accepted within the nuclear weapon safety community that no individual nuclear safety subsystem can contribute more than a one in a million (10-6) reduction in the probability of an event that impacts nuclear safety, especially when the entire lifetime of a weapon is considered.  The “limit” of 10-6 per subsystem is founded on the concern that to statistically demonstrated a 10-6 level via testing in all possible normal and abnormal environments and attacks, is economically unfeasible.  Hence a combination of analyses (mostly) and testing (limited but perhaps necessary to validate key elements of the analyses) must be provided to reasonably demonstrate a 10-6 contribution, even though the analysis and testing might not, in the purest sense, be able to satisfy a strict proof of the 10-6 allocation.  The use of features that can be considered to be inherently safe (i.e., requiring no proof, self-evident due to natural law and science) may greatly reduce the burden of analytical/testing support.  Continuing this philosophy, a minimum of 2 safety contributing subsystems would be required to reach a 10-6 probability level and a minimum of 3 subsystems would be required for the 10-9 level.  Therefore, the prevalent opinion in designing reliable nuclear safety into a nuclear weapon system is to incorporate several layers of safety (i.e., a distributive approach) to achieve the required quantitative nuclear safety levels.  The concept is to collectively use multiple nuclear safety subsystems/components/features to provide the required safety standard for both the normal, day to day environments, as well as when the weapon system is exposed to a specific set of abnormal (accident) environments or subversive attack, which might cause one subsystem/component/feature to fail.

The task for the weapon system designers is to develop a nuclear weapon safety theme (an inter-crafted hardware and software approach, tailored to the specific operational sequence of the proposed weapon system) based on this philosophy, that can be demonstrated via analyses and test to comply with quantitative nuclear safety standards.  Another general assumption within the nuclear weapon safety community is that purely electronic safety feature (i.e., semiconductor, microprocessor, integrated chips, etc., circuits) can only be deemed to contribute to safety in normal environments, such as a wiretapping attack.  The proof of demonstrating such electronic subsystems performance during abnormal environment is considered impractical and prohibitive to the stringent levels required of nuclear safety.

2.0    Nuclear Safety Requirements

The basic nuclear safety goals are outlined in four safety standards within DoD Directive 3150.02 and its complementary manual DoD 3150.02M.  These standards must be complied with in any nuclear weapon system’s approach to safety, and are as follows:

1. Prevent nuclear weapons involved in accidents or incidents or jettisoned weapons from producing a nuclear yield.

2. Prevent DELIBERATE prearming, arming, launching, firing, or releasing of nuclear weapons except upon execution of emergency war orders or when directed by competent authority.

3. Prevent INADVERTENT prearming, arming, launching firing, or releasing of nuclear weapons.

4. Ensure adequate security of nuclear weapons pursuant to the provisions of DoD Directive 5210.41.

Further, a fifth concern, although not formally documented, is the prevention of any credible accident from causing the dispersal of plutonium or special nuclear material (SNM). DoD Directive 5210.41 and its complementary manual DoD 5210.41M outline requirements for the security of nuclear weapons in all possible configurations.

Modern nuclear safety criteria have established that for nuclear weapons, in a normal operational environment, the probability of an undesired nuclear event (a nuclear yield greater than 4 pounds TNT equivalent) must be less than 10-9 over the lifetime of a nuclear weapon system.  Additionally, in the abnormal environments that a weapon maybe subjected to (such as lightning, fire, immersion in ocean depths, etc.), the probability of an undesired nuclear event must be less than 10-6 per occurrence of such an abnormal environment.  DoD Directive 5200.16 provides guidelines for the command and control (C2) system of a nuclear weapon, which have similar requirements for protection against an outsider attack (10-9) and an insider attack 10-6).  More specifically stated, the nuclear yield resulting from faults and failures in the nuclear weapon system shall have a probability of:

1. Less than 1 x 10-9 per weapon per stockpile lifetime for normal environments in the absence of warhead unique prearming, environment or trajectory stimuli

2. Less than 1 x 10-6 per weapon per exposure to abnormal environments and in the absence of unique prearming or environmental stimuli.

3. Less than 1 x 10-4 per event where an event is the application of the prearm command deliberate deployment (launch or release) of the weapon, but in the absence of the arming signal.

   In the event of a crisis in which a national defense alert has occurred and nuclear weapon systems are ordered to be released, a progressive reduction of the nuclear safety quantitative requirements is allowed.  The designer should strive to delay this reduction to as late in the release process as possible (i.e., as close to the target as possible), to minimize the time the weapon exists in this less safety mode and to minimize the subversive threat where spoofing is used to generate a crisis situation.

Why Does HIPAA Require a Risk Assessment?

posted Oct 5, 2014, by Ron Gault

From a series of 'Ask the Expert' columns for a HIPAA Compliance website: Why Does HIPAA Require a Risk Assessment?

The HIPAA Security Rules are based on the National Institute of Standards (NIST) guidelines, which stress risk assessment as one of the critical processes of managing any system.  The results of a risk assessment are then available for use in risk management, the effort of minimizing the likelihood of identified undesirable event(s) taking place. The HIPAA Security Rules define some specific, mandatory information security measures, but they also require each entity to identify which of a set of addressable information security measures are needed and to incorporate them only if the risk requires it, a very logical and commonly used way to approach making cost-conscious business decisions.

The risk assessment process endorsed by NIST/HIPAA is a systematic, comprehensive, repeatable and defendable process to determine what the vulnerabilities are of the information system under investigation.  After determining vulnerabilities, the process identifies the risk by combining the vulnerabilities with the consequences of the vulnerabilities either being inadvertently or deliberately exploited (threats).  With this data, it is also possible to identify and evaluate effective means of mitigating any unacceptable risks to an acceptable level. Via the risk assessment, an entity determines which of the HIPAA addressable processes, procedures, and technical measures are required and then defends the sufficiency of their own specific implementation of these.

How would I do a Risk Assessment for my Medical Clinic?

Risk assessment has three major parts: defining the system, identifying the threats, and calculating the risk of individual threats.

Risk assessment starts by identifying the system under consideration and then determining the causes of undesirable event(s), or threats, which could occur in the system. Viewed as a system, the typical small clinic has the physical components of waiting room, exam rooms, physicians’ offices, administration office, laboratory/equipment room, etc.  Within this system, certain assets, such as EMRs and other information processing equipment, form the subsystem of interest for risk assessment. If you look at how information system components interact with each other and where the assets of concern reside/are accessible, then you can evaluate how the undesirable consequences can happen (scenarios) and the likelihood of them happening. 

The major undesirable event of concern for HIPAA (and, therefore, the small clinic) is the compromise of patient information. Included in this area of concern, and probably the more immediate concern for a small clinic, is the loss of the ability to conduct business due to non-operational information systems. For example, an information system could be rendered non-operational by an attack from a virus that has compromised key applications. 

Once the system under analysis is defined and the major threats identified, the causes of the threats can be evaluated for their likelihood of occurrence in the system.  You can then calculate the risk by taking the product of the likelihood of occurrence and the consequence of each undesirable event.  Let’s look at a real-world example.

The typical clinic has numerous computer workstations that allow for access to patient information.  Risk assessment asks: Are the workstations protected from unauthorized use by the casual passerby, or from the covert (i.e., burglar or internet hacker)thief?  For example, do the workstations automatically log off if the authorized user forgets to log off, and are complex passwords required to log on?  Such a risk assessment does not need to be done at a mathematically complex level; it can be done effectively at the top level shown in the table and be successful. 

In this example, let’s assume that you have reviewed your clinic and determined that the likelihood of anyone gaining access to patient data via your workstations is a medium likelihood based on your current configuration and protection measures.  And let’s assume you recently digitized all your old paper files, invested in a non-water fire suppression system, and established a backup copy at a secure remote site.  The likelihood of losing this data is now very low (1).  While the consequence of losing a small amount of patient data through an unprotected workstation is smaller than losing all the data contained in your paper files (5 vs. 7), the likelihood is now much greater for someone gaining patient data via a workstation than the likelihood of a fire causing you to lose all that data (5 vs. 1).  Therefore, the information system risk from the unprotected workstation can be computed to be greater (5 x 5 = 25) than that from a fire in your office (7 x 1 = 7).  If additional resources were to be expended for security, they would best be focused on reducing the risk from unprotected workstations rather than on additional fire protection or data backup.

HIPPA requires you to do a similar analysis on your entire enterprise and show that the information security measures you have in place result in a risk profile (list of all identified risks) that is acceptable.  It doesn’t need to be any more complex than the example given above, and for the small clinic, the effort can be conducted and documented in a short amount of time.  Chances are you have already reviewed some of these issues as part of establishing and setting up your information systems.  We’ll address commonly used information security ‘best practices’ in a future posting.  Right now, it’s time to evaluate and document what your risk profile is and see where you stand!

Protecting Data in Motion

posted Oct 5, 2014, by Ron Gault

From a series of 'Ask the Expert' columns for a HIPAA Compliance website: What are my Options for Protecting Data in Motion?

Data in a medical information system exists in one of two states: 1) ‘at rest’ or 2) ‘in motion’.  At rest means that the data is contained in one physical location, e.g., in a local patient database.  Data in motion, is being sent from one location to another, e.g., patient data being sent to an insurance company for claims processing or to a hospital for updating a in a central repository.  Besides being a HIPAA addressable requirement, the ever increasing news revelations (e.g., Wikileaks, etc.) about information compromises underscore the fact that unsecured data, especially when in motion, is highly susceptible to interception and therefore protection must be considered.  Since the majority of us are using an Internet Service Provider (ISP) via our telephone or cable service, this data is readily available to anyone with minimal skills and a desire to compromise it.

Various methods exist to protect data in motion from a simple password that prevents casual observers viewing the data, to sophisticated encryption schemes that only dedicated analytical attacks can compromise. Encryption is the act of ‘scrambling’ information so that while an interloper may tap onto your communications line, they cannot compromise that information.  Encryption uses mathematical algorithms to encrypt the information at the sending end and decrypt it at the receiving end.  These operations are performed under the control of unique numeric keys so that only holders of the correct keys can successfully pass data back and forth. When you select ‘purchase’ on a website, you’ll see the address of that provider automatically change to include ‘https’ (hypertext transfer protocol secure) which the website owner is using to establish an encrypted connection between the two of you.

Establishing encryption services can be time consuming and expensive, so a simple risk assessment (discussed in a previous article (add a hyperlink?)) is a good first step to help determine the complexity of security required. Ask yourself who are the entities that you are communicating with, what is the quantity of data you routinely send, and what levels of protection is appropriate for this data when in motion?  After you have determined the actual quantity and sensitivity of data at risk, you can scope how much effort you need to expend to protect it. Various encryption techniques are available that are suitable for the small clinic.  Let’s review what they are.

Common Data in Motion Protection Options

Access Protection

Most internet services offer the option of the sender requiring a password be entered by the sender that the recipient must enter to allow viewing.  This is simple to use but does not truly encrypt the information in the message.  It does prevent the casual interloper from compromising the information and can be considered acceptable protection for sending small amounts of data.

Private Networks

When the sender is communicating with a single recipient both parties may coordinate a solution to make the process secure by selecting an encryption scheme and establishing a secret key that they share.  Because only they know the key, it can be reused for months at a time before changing it.

Virtual Private Networks

If you are using several computers to send information and/or you’re communicating with a large organization, they most likely will have the capability to establish a virtual private network (VPN) between you two and provide all management of the process. It generally requires you to make a one-time load of a unique software application on your computers. And use a password that needs to be entered every time you communicate.

Web-based Secure Connections

Many companies are now using secure web-based applications that allow you to use an application in your web browser to securely communicate with them.  It’s based on VPN principles but all the necessary management of the connection is done through a web browser using a protocol called secure socket layer (SSL).  You utilize this method when you conduct business on the internet and you see ‘https’ in the address line.  It requires you to open the browser, but not have to enter a password.

Public Key Encryption

Is a complex but very secure process that is universally accepted for high security data exchanges.  It requires registering with an trusted third-party agency that provides you encryption keys so that you can communicate with anyone else that has so registered.  The establishment and use of this process is generally beyond the needs of the small clinic unless you are passing large amounts of data (e.g., participating in a large clinic trial, etc.)

Summary

Protection of data in motion is important and must be addressed by everyone in the medical field.  Start with a simple risk assessment to determine the amount of effort you need to expend and coordinate with all the organizations you are likely to be communicating with. Perhaps there is one protection technique that is compatible with all of them, and would be the most economical approach for your clinic to adopt. 

Organizations with Immunity to Security Attacks

Organizations with immunity to security attacks

posted Jul 31, 2014, 6:56 PM by Jesse Glidden 

In April of 2014, I attended an ISSA webinar (sponsored by Ixiacom.com) that discussed organizations that seem immune to security attacks. I'll share a few of salient points.

Risk Analysis

• It's not about the resources, it's about a risk-based effort, because you will never have adequate resources

• Take a risk-based approach.

Ask yourself these three questions:

1. What is the risk?

2. Is it the highest priority risk?

3. What is the most cost-effective method of reducing risk?

• Threats: offense must inform the defense

• Risk = Threat * Vulnerability

  • Threat ~ Likelihood

  • Vulnerability ~ Impact

What are the current risks an organization faces?

• Data Theft

• Long-term compromise

• Loss of Command and control capability

• Loss of Competitive Advantage

What are some of the current threats?

• Trusted insiders

• Supply Chain threats (i.e., Target)

What are some of the vulnerabilities?

• Lack of segmentation (access controls, permissions, etc.)

  • Control and minimize damage by “heavily segmenting" data systems

• Prevent access to critical data, or more critical data, and identify where that data is

• Systems not sufficiently hardened

  • For instance, who has direct access to PCI POS systems?

So you need to know a few things:

• What is your critical data, and where is it located in your organization?

• What servers is your data on?

• You need an accurate, current network diagram

Consider this exercise:

1. Identify all critical data (assets), and the business processes that support it.

2. List all threats, starting with the highest likelihood of success to your organization

3. List all vulnerabilities, starting with the highest impact, based on threats that are tied to your critical assets

Number 3 in the above list becomes your action plan, this is where you focus your efforts in the upcoming short-term. [This is what we at RGC consider a risk analysis, with a risk management plan]. 

Targeting

Be sure to differentiate between the source of the threat, and the cause of damage. Many believe that the biggest source of threats out there today are external: foreign adversaries, competitors, etc. Yet, cause of damage is often an “accidental insider”, who is tricked into doing something they would not normally do if they knew the impact of their action, or if they were even aware of what they were doing. Therefore, good organizations can minimize this likelihood with "awareness training". Organizations often overdedicate resources to the external threat, while underdedicating resources to insider, supply chain, internal unpatched systems, etc. type of threats.

What are the classic core characteristics of an attack?

• Target an individual/system

• Deliver payload to system

• Upload files to the system

• Run processes

• Survive a reboot

• Make outbound connections (beacons to C2)

• Perform internal reconnaissance

• Pivot into the network

Why are attacks successful? Here are a few reasons:

• Organizations do not have security devices properly configured

• Organizations don't understand the difference between a product and a solution

• Lack of data classification, or segmentation

• Insufficient logging and correlation

• Too much data visibility on the internal network

• Minimal asset management and configuration control

• Failure to institute least privilege

Here are a few more reasons:

• No risk management program

• No employee training

• No policies

Remember, the source of the damage may be external, but the cause of the damage is internal!

Insider Threats

The deliberate insider the the most difficult threat to mitigate. The most you can do for these threats is to focus on authorization and access policy. For the accidental insider however, you want to focus on 

• Differentiate between required functionality and optional functionality

• Typical avenues of attack, such as

  • Exe attachments

  • Macros embedded in Office documents

  • Active scripting

  • HTML embedded content

• Differences in activity between a normal user and an insider threat

• Activity patterns focused on data:

  • Amount of data accessed

  • Failed access attempts

  • Data copied or sent to external sources

How do you detect the accidental insider? Because, there are differences in activity between a normal user and an insider threat. 

• Almost all external attackers attempt to set up command & control (C2)

• Activity patterns focused on data:

  • Amount of data accessed

  • Failed access attempts

  • Data copied or sent to external sources

• Focus on outbound traffic

  • Number of connections

  • Length of the connections

  • Amount of data

  • Percent that is encrypted

  • Destination IP address