15 May 2001

REAL TIME (RT) SECURITY

STRAWMAN (Draft)

Drafted by: Dr. Sam Bowser, The Aerospace Corp.

For The Open Group RT Forum Security Group

## PURPOSE

Secure systems and real time, embedded systems are subject areas with
many requirements, guidelines, and standards. Historically, real time
systems designers have not included information security/assurance in
their requirements. Our interest area is the intersection of real time
and security. A growing number of systems exist today that have both
real time (including embedded) and security considerations. The Real
Time Security Forum expects the number of such systems to grow rapidly
as we enter the information age of mobile, wireless connectivity.

We recognize that different system domains have different security and
real time requirements, so a single solution is not the answer. There is
a need for an approach that system architects can use and apply within
their own system domain, and yet maintain certain standard to allow
portability among these different systems. There is also a need for
tools the system software developer can use to address security issues
for real time systems.

## SCOPE

We seek practical solutions and tools that will allow the developer to
apply security policy in a flexible cost effective manner. We seek
technologies and practices that can enable a wide variety of system
architects to make informed decisions. As with any architecture, this
involves tradeoffs by the system architect. Areas of tradeoff include:

Resource Utilization

Performance Responsiveness

Availability of Service / Robustness

Security features to support application

Cost

BACKGROUND

Real Time (RT) system requirements are currently being found in systems
ranging from manufacturing to state-of-the-art tactical systems.
However, the inclusion of RT systems into these processes significantly
alters the overall security environment. Information security/assurance
usually has not been addressed as a design constraint. Addressing those
security issues will present some serious challenges to overcome. The
military for example places a tremendous reliance on global information
transfer to all command and fighting elements of a war. Commercial
enterprises have significant information security needs in the current
global environment. Such reliance demands security of this information
far beyond what is present today. Not only is detection of any intrusion
on this global communication important but real time detection and
immediate severing of the intrusion; and continued, unhindered,
operation is a strong requirement. With Real Time required for Command
and Control (C2), the security safeguard of RT systems becomes extremely
critical. The impact of RT on C2 has security implications for the
entire infrastructure in the US and globally for all countries.

**PROBLEM STATEMENT**

The problem focus is upon embedded systems since they present the most
difficult application area. Many embedded RT processors control critical
systems. The range of critical RT systems includes chemical processes,
power plants and grids, traffic control, manufacturing production lines,
avionics, missiles, strategic defense systems, etc. Human lives,
regulatory compliance, mission success, and even national security often
depend on these RT systems properly functioning as designed and with
little margin for error. Because of the unique nature of the RT
operating environment, the protection of embedded RT systems presents a
unique challenge for the system designer.

RT systems are difficult to protect because they often involve some form
of automatic sensor-to-operator system, or network of systems thus
eliminating the traditional human air gap (which, in the past, had
provided some level of disaster avoidance control mechanism). Now, if a
security problem occurs -- especially if it results in some form of
system interrupt, there is usually no way to stop the adverse chain of
events (and the consequences) until it is too late. Consequently, very
high system reliability has becomes a major concern.

Even the minutest interrupt in an RT system can potentially result in a
disaster with extreme consequences. These consequences can include the
loss of many human lives and mission failure. The resulting situation
can even jeopardize national security. Because of the vulnerability
inherent in the RT environment, and the severity of the potential
consequences that can result from of a disruption in normal system
processing (even a brief operating system interrupt), ensuring the
integrity and availability of critical RT systems is of extreme
importance.

The technologies for providing secure systems range from specialized
operating systems to encryption of data. An open question is how
applicable are Secure Sockets Layer (SSL) and other information security
technologies that have been developed for transactional activities for
use in real-time non-transactional activities. Review of the available
solutions and approaches to information security must be included in any
solution proposed for RT systems.

The problem is further complicated by the specialized nature of security
requirements for each domain or application area. There are common
elements across domains and information security generally has not been
recognized as an important aspect of system design. Each domain
(chemical, power, traffic, military, etc.) has unique security
requirements. The inclusion of all these security measures in an
operating system is not practical. The usual RT environment is resource
constrained and will not support unnecessary security requirements.
There is a need to tailor the security environment for each domain. The
bottom line problem is providing adequate security across domains while
maintaining RT operational integrity without the extreme costs
associated with custom operating systems.

## PROPOSED SOLUTION

We recommend the creation of a RT Security API. The RT/OS vendors would
be asked to support the API so that developers could tailor the security
environment to the requirements of the domains supported by the software
under development. Guidelines would be developed to provide the basis
for the API creation using the Open Group as the coordinating body.

These guidelines contain two components:

1.  The Security Requirements Matrix for the RT Security API and the
    hooks needed to implement the API in an RT/OS. This requirements
    matrix constitutes the bottom-line requirements/guidelines for the
    RT software developer and the RT/OS vendor. It would include the
    required interrupt priorities for authentication, authorization, and
    encryption, as required.

2.  An explanation of the overall environment of threats,
    vulnerabilities, and the unique security issues pertaining to the RT
    processing environment. This supplies the system architects with the
    framework for RT system design.

Even though the specific subject of this guidance is software security,
there are some aspects of the RT operating environment for which the
software developer, PM, security officer, and other key project
personnel must be aware. RT operating systems, by themselves, frequently
cannot contain all the necessary security functionality to adequately
protect them. Software security solutions often must work in conjunction
with other security safeguards (e.g., physical security) to achieve an
acceptable level of risk. Software security cannot be considered in a
total vacuum. The developer, and the project administration and security
staff, must be aware of these issues in order to ensure that the other
critical components to achieving a viable security architecture are not
neglected.

**RT SECURITY ENVIRONMENT**

**OVERVIEW**

Embedded RT processors control critical systems. To adequately protect
such a system, it is necessary to ensure effective accountability,
availability, reliability, confidentiality, access control, integrity,
and non-repudiation. The purpose of this section is to provide the
high-level guidance necessary to assist the system developer in ensuring
adequate security for systems operating in the RT environment. Future
versions of this document may incorporate Multi-Level-Security (MLS)
requirements, as they become better defined, and more technically
feasible.

Because of the unique nature of the RT operating environment, and the
inherent potential for critical consequences in the event of a system
failure, ensuring the protection of these systems frequently presents
unique challenges. Therefore, in considering RT security, it is
necessary to address some of the threats and vulnerabilities associated
with the RT operating environment

**THREATS, VULNERABILITIES & SAFEGUARDS**

**THREATS**

The possibility of occurrence of any event, which has the potential to
cause an adverse impact to any system resources (including hardware,
software, information and personnel), constitutes a threat. Threats can
be seen as potential breaches in security, and are present in all system
operating environments. The severity of the potential consequences can
range from minor inconvenience, to extremely severe (possibly
jeopardizing critical system resources, human life, and even national
security). The basic types of threats are:

**Human Intentional.** Such intentional human acts as espionage,
sabotage, employee fraud, misuse, etc.

**Human Unintentional.** Accidents and human error.

**Equipment.** Hardware/mechanical failures, fire, electrical problems,
heating/cooling problems, etc.

**Natural.** Force Majeure. Earthquake, hurricane, tornado, flood,
tsunami, lightning, and other acts of nature.

Every system operates in an environment (external and internal) that
contains some inherent level of threats. T*here are absolutely no
"threat-free" environments* (a totally "threat-free" environment is
achieved when a system is unplugged, disconnected from all networks and
other equipment, and buried so deep that nobody can access it; of
course, it would then be of little use to anyone). Unfortunately, on
occasion: equipment will fail, people will make mistakes, natural
disasters will occur, and international terrorist groups and rogue
governments will attempt to steal or sabotage our critical resources.

Threats are the reason that security precautions are taken, and security
mechanisms are developed. While threats cannot be totally eliminated,
the implementation of various safeguards and procedures can
significantly reduce a system's vulnerabilities (weaknesses that can be
easily exploited by threats) to many threats.

This section discusses the threats that jeopardize embedded and other
real-time systems at each phase of the system's life cycle. Not all of
these threats can be handled by the security mechanisms associated with
a real-time operating system.

**Summary of Computer System Threat Terminology**

The following table lists some common threats and threat terms
associated with RT computer systems.

+------------+---------------------------------------------------------+
| **Ter      | **Description**                                         |
| m/Threat** |                                                         |
+------------+---------------------------------------------------------+
| Aut        | A person authorized to use a system for one purpose     |
| horization | used it for another, unauthorized purpose.              |
| Violation  |                                                         |
+------------+---------------------------------------------------------+
| Bombs      | A bomb is a type of Trojan Horse used to release a      |
| (Logic or  | virus, worm, or another form of attack. It imposes a    |
| Time)      | delay between preparation and activation. A time bomb   |
|            | is set to go off at a specific date and time. A logic   |
|            | bomb is triggered by any combination of conditions,     |
|            | such as particular input transaction or change in a     |
|            | file.                                                   |
+------------+---------------------------------------------------------+
| Browsing   | Browsing is the result of attempts by either a          |
|            | legitimate user or an intruder to access information to |
|            | which read access is neither authorized nor intended.   |
+------------+---------------------------------------------------------+
| Bypassing  | An attacker exploits system flaws or security           |
| Controls   | weaknesses.                                             |
+------------+---------------------------------------------------------+
| Data       | Substitution refers to any action in which valid        |
| Mod        | information is altered or replaced with false           |
| ifications | information such that it serves to deceive an           |
|            | authorized individual or entity.                        |
| Su         |                                                         |
| bstitution |                                                         |
+------------+---------------------------------------------------------+
| Data       | Insertion describes any action whereby an authorized    |
| Mod        | individual or entity is deceived through the            |
| ifications | introduction of false information.                      |
|            |                                                         |
| Insertion  |                                                         |
+------------+---------------------------------------------------------+
| Data       | Deletion describes actions in which an authorized       |
| Mod        | individual or entity is deceived through erasure or     |
| ifications | removal of true information.                            |
|            |                                                         |
| Deletion   |                                                         |
+------------+---------------------------------------------------------+
| Denial of  | Legitimate access to information or other resources is  |
| Service    | deliberately impeded.                                   |
+------------+---------------------------------------------------------+
| Denial of  | User added operating system calls and interrupt         |
| Service:   | handlers may disable interrupts. User programs which    |
|            | spawn large numbers of tasks can overload resources and |
| System     | could deny or badly degrade service.                    |
| Saturation |                                                         |
+------------+---------------------------------------------------------+
| Eav        | Information is revealed from monitored communications.  |
| esdropping |                                                         |
+------------+---------------------------------------------------------+
| EM / RF    | Information is revealed from monitored communications.  |
| In         |                                                         |
| terception |                                                         |
+------------+---------------------------------------------------------+
| Il         | A resource is used by an unauthorized person or in an   |
| legitimate | unauthorized way.                                       |
| Use        |                                                         |
+------------+---------------------------------------------------------+
| Ind        | An authorized person discloses information to an        |
| iscretions | unauthorized person, e.g., for money or favors, or      |
| by         | through carelessness.                                   |
| Personnel  |                                                         |
+------------+---------------------------------------------------------+
| I          | Information is disclosed or revealed to an unauthorized |
| nformation | person or entity.                                       |
| Leakage    |                                                         |
+------------+---------------------------------------------------------+
| Integrity  | The consistency of data is compromised through          |
| Violation  | unauthorized creation, modification, or destruction of  |
|            | data.                                                   |
+------------+---------------------------------------------------------+
| Intercept  | A communicated data item is changed, deleted, or        |
| / Alter    | substituted while in transit.                           |
+------------+---------------------------------------------------------+
| In         | Database query analysis refers to any process in which  |
| terference | an unauthorized individual or entity is able to gain    |
|            | knowledge of sensitive or protected information based   |
| Database   | on data for which they are either allowed to receive,   |
| Query      | or by being notified of denied access to information.   |
| Analysis   |                                                         |
+------------+---------------------------------------------------------+
| Masquerade | An entity (person or system) pretends to be a different |
|            | entity.                                                 |
+------------+---------------------------------------------------------+
| Media      | Information is obtained from discarded magnetic or      |
| Scavenging | printed media.                                          |
+------------+---------------------------------------------------------+
| Physical   | An intruder gains access by circumventing physical      |
| intrusion  | controls.                                               |
+------------+---------------------------------------------------------+
| Replay     | A captured copy of a legitimately communicated data     |
|            | item is retransmitted for illegitimate purposes.        |
+------------+---------------------------------------------------------+
| R          | A party to a communication exchange later falsely       |
| epudiation | denies that the exchange took place.                    |
+------------+---------------------------------------------------------+
| Resource   | A resource (e.g., access port) is deliberately used so  |
| Exhaustion | heavily that service to other users is disrupted.       |
+------------+---------------------------------------------------------+
| Sabotage   | Common examples of sabotage include: destroying         |
|            | hardware or facilities, planting logic bombs that       |
|            | destroy programs or data (see malicious software),      |
|            | entering data incorrectly, crashing systems, deleting   |
|            | data, holding data hostage, and changing data.          |
+------------+---------------------------------------------------------+
| Scavenging | Scavenging refers to the process of searching through   |
|            | system residual information or generally available      |
|            | information to find and acquire sensitive data in order |
|            | to violate information confidentiality.                 |
+------------+---------------------------------------------------------+
| Spying     | Spying is defined as direct covert visual or auditory   |
|            | observation of private information as it is being       |
|            | displayed or entered into a computer or related system  |
|            | with the intention of violating information             |
|            | confidentiality.                                        |
+------------+---------------------------------------------------------+
| Service    | A bogus system or system component aims to dupe         |
| Spoofing   | legitimate users or system into voluntarily giving up   |
|            | sensitive information.                                  |
+------------+---------------------------------------------------------+
| Sniffers   | Sniffing is the process of monitoring data traffic,     |
|            | usually on a network, in order to collect information   |
|            | that could be used for unauthorized access. Sniffer     |
|            | attacks often involve the use of network monitoring     |
|            | tools called sniffers.                                  |
+------------+---------------------------------------------------------+
| Su         | Substitution is the introduction of unauthorized,       |
| bstitution | potentially malicious, components into the system.      |
+------------+---------------------------------------------------------+
| Terrorism  | Terrorism by an individual or organization, when used   |
|            | in a deliberate way can adversely affect the actions    |
|            | and policies of states and organizations.               |
+------------+---------------------------------------------------------+
| Theft      | A security-critical item, e.g., a token or identity     |
|            | card, is stolen.                                        |
+------------+---------------------------------------------------------+
| Traffic    | Information is leaked to unauthorized entities, through |
| Analysis   | observation of communications traffic patterns.         |
+------------+---------------------------------------------------------+
| Trap Door  | A Trap Door is a hidden mechanism contained in the      |
| / Back     | software that allow developers, or anyone else knowing  |
| Door       | the secret, to bypass normal access controls. The       |
|            | mechanism is built into the software by its designer.   |
+------------+---------------------------------------------------------+
| Trojan     | A Trojan Horse is an apparently useful program          |
| Horse      | containing a hidden code fragment, that performs hidden |
|            | functions and exploiting the privileges of the user.    |
+------------+---------------------------------------------------------+
| Tunneling  | Another way to defeat safeguards is to attack below the |
|            | level of the safeguard. For example, if there is access |
|            | control on files, attack the disk sectors where the     |
|            | file is stored. If an application transaction has       |
|            | strict controls, attack the transaction program object  |
|            | module. An attack that goes "under" the controls in     |
|            | this way is called a Tunneling attack.                  |
+------------+---------------------------------------------------------+
| Un         | Impersonating means pretending to be someone else in    |
| authorized | order to obtain that person's access rights and often   |
| Access     | involves an attack on authentication controls. The      |
|            | effects of masquerading may be either to elicit         |
| Imp        | information or to mislead friendly units into taking    |
| ersonating | actions prejudicial to their own interests.             |
| /          |                                                         |
| Ma         |                                                         |
| squerading |                                                         |
+------------+---------------------------------------------------------+
| Un         | Violation of permission refers to authorized            |
| authorized | individuals or entities who exceed their system         |
| Access     | privileges by executing functions that they are not     |
|            | authorized to perform.                                  |
| Violations |                                                         |
| of         |                                                         |
| Permission |                                                         |
+------------+---------------------------------------------------------+
| Un         | Piggybacking (also known as tailgating) is a            |
| authorized | masquerading technique within a computer system or      |
| Access     | communication facilities connected to a computer        |
|            | system. The technique covertly uses facilities of       |
| Pi         | computer access and processing.                         |
| ggybacking |                                                         |
+------------+---------------------------------------------------------+
| Virus      | A virus is a program that attaches itself to a host     |
|            | program so that when the host is executed, the virus    |
|            | will execute. When executed the virus tries to copy     |
|            | itself (or a modified version of itself) to some other  |
|            | host program. Then the virus typically carries out its  |
|            | mission or payload.                                     |
+------------+---------------------------------------------------------+
| Worm       | A worm is a self-replicating program that is            |
|            | self-contained and does not require a host program. It  |
|            | makes a copy of itself and causes the copy to execute.  |
|            | Unlike viruses, worms don't usually modify other        |
|            | programs. Worms may be used to destroy data or they may |
|            | be used to tie up network resources, causing a loss of  |
|            | communication within the network.                       |
+------------+---------------------------------------------------------+

### 

#### Common Threats 

The following are the potential security threats common to real-time
security environments that can result in denial of service or
compromise, exposure, or corruption of vital, sensitive, and / or
classified data:

> • Hardware or software design flaws.
>
> • Accidental component failures.
>
> • Damage to components.
>
> • Hardware failures.
>
> • Unauthorized substitution of components.
>
> • Introduction of environmental hazards or negligent neutralization of
> mechanisms intended to protect against environmental hazards.
>
> • Misuse of systems or components.
>
> • Penetration of systems components, to which the perpetrator is not
> authorized access.
>
> • Initiation of connections to system components, to which the
> perpetrator is not authorized access.
>
> • Malicious or negligent tampering with components, to which an
> embedded application or an individual is not authorized access.
>
> • Probing or performing technical surveillance of classified
> components.

-   Accessing "unused" applications with actual data.

#### Field Test Threats 

In addition to the common threats identified for all real-time security
environments, the Field Test and Acceptance Environment needs to be
protected from the threats listed below. The Field Test and Acceptance
Environment includes test, evaluation, and support components,
personnel, and facilities associated with determination of functional
correctness, operational effectiveness, and reliability of avionics.

> • Test design flaws that can result in excessive stress on test units
> or erroneous test results
>
> • Operator error that can result in false test data, damage to systems
> under test or test systems, unavailability of functionality, or
> exposure of sensitive information to unauthorized personnel
>
> • Jamming of communications among acceptance facilities in order to
> disrupt the acceptance procedure or yield erroneous acceptance results

#### Training Environment Threats 

In addition to the common threats identified for the RT security
environments, training environments need to be protected from the
threats such as those listed below. The Training Environment includes
stand-alone and networked training aids and documentation, training
components and data embedded in avionics systems, and other simulation
systems employed for operator/pilot instruction and all phases of
maintenance training.

> • Design flaws or malfunctions of hardware components that can result
> in release of dangerous processes or weapons during a training
> exercise.
>
> • Hostile takeover of training facilities or participants in exposed
> locations in order to destroy data, corrupt data, deny functionality,
> or expose sensitive information to unauthorized personnel.

#### Operations Environment Threats 

In addition to the common threats identified for RT security
environments, the operations environment needs to be protected from the
threats listed below. The operations environment includes all phases of
operations and support. This includes personnel, facilities, and
components associated with day-to-day training and planning for
operations including unusual or special occurrences.

> • Active wiretapping of communications media that reveal information
> for which the individual is not.
>
> • Hostile takeover of operations facilities or participants in exposed
> locations in order to destroy data, corrupt data, deny functionality,
> or expose sensitive information to unauthorized personnel
>
> • Emergency in a foreign country that can result in unauthorized
> access or exposing a RT system to damage by hostile persons.

#### Maintenance Environment Threats 

In addition to the common threats identified for all security
environments, the maintenance environment needs to be protected from the
threat listed below. The maintenance environment includes personnel,
automated and manual instruments and tools, documentation, and
facilities associated with both preventive and corrective maintenance of
aircraft.

> • Physical access to the embedded system, or other equipment
> containing real-time systems, by maintenance personnel that may result
> in exposing sensitive information to unauthorized personnel or
> physical damage by poorly trained or hostile personnel.

### Attacks 

Attacks are actions performed by some entity with the intent of
violating security. The following discussion by Olovsson of structured
approaches to computer security explains the different types of attacks.

> Examples of attacks are destruction, modification, fabrication,
> interruption or interception of data. An attack results in disclosure
> of information, a violation of object confidentiality, or in
> modification of objects, a violation of object integrity.
>
> The definition of security as protection of objects and the definition
> of a security violation as an action violating the rules stated in the
> security policy (which describes how objects are allowed to be
> accessed), implies that a security violation is always an illegal
> access to an object. An attacker can gain access to a specific object
> by doing his attack in several steps, where each step involves an
> illegal access to an object. For example, system software could be the
> first target for an attacker, which in turn may help him to gain
> access to another object.
>
> Attacks can be both direct and indirect. A direct attack aims directly
> at an object. Several components in a system may be attacked before
> the intended (final) object can be accessed. In this case, all these
> intermediate objects are targets for direct attacks. In an indirect
> attack, information is received from or about an object without
> attacking the object itself. For example, it may be possible to derive
> confidential information without accessing an object at all, by
> gathering statistics and thereby derive the desired information.
> Indirect attacks are especially troublesome in database systems where
> it is possible to ask indirect questions to a database about an
> object, and from the answers derive confidential information. Such an
> indirect attack is often called inference.
>
> There are two different kinds of attacks: passive and active attacks.
> Passive attacks are done by monitoring a system performing its tasks
> and collecting information. In general, it is extremely difficult to
> detect passive attacks since they do not interact or disturb normal
> system functions. Examples of passive attacks are monitoring network
> traffic, CPU and disk usage. Encryption of network traffic can only
> partly solve the problem since even the presence of traffic on a
> network may reveal some information. Traffic analysis such as
> measuring the length, time and frequency of transmissions can be very
> valuable to detect unusual activities. (Rumors say that prior to the
> US Panama invasion, Domino\'s pizza deliveries to the Pentagon jumped
> 25%, a situation in which an external observer could detect that
> something unusual was going on.)
>
> An active attack changes the system behavior in some way. Examples can
> be to insert new messages on a network, to modify, delay, reorder,
> duplicate or delete existing messages, to deliberately abuse system
> software causing it to fail and to steal magnetic tapes. A simple
> operation such as the modification of a negative acknowledgment (NACK)
> from a database server into a positive acknowledgment (ACK) could
> result in great confusion and/or damage. Active attacks are, in
> contrast to passive attacks, more easy to detect if proper precautions
> have been taken.
>
> The following paragraphs will describe some important types of
> attacks: Trojan horses, viruses, worms and covert channels.
>
> **Example 1: Trojan Horses**
>
> A Trojan Horse is a program performing one action but secretly also
> performing another. An example of a Trojan horse is a text editor
> searching documents for special keywords and, if a keyword is found,
> making a copy of the document available to someone else. The
> protection mechanisms in most systems have problems protecting
> information against such an attack. A document may be protected, but
> when entities have the possibility to select protection of objects at
> their own will, it is extremely difficult for a system to stop a
> Trojan horse from requesting a change of protection for an object. In
> fact, most actions an entity may perform can be performed secretly by
> a Trojan horse, since the Trojan horse normally executes with the same
> privileges as the entity using it.
>
> Another task a Trojan horse can perform is to open a back-door into a
> system. If a system administrator or any highly privileged user
> executes a program containing a Trojan horse, almost any action can be
> performed. For example, the Trojan horse may create new user accounts,
> modify the system into accepting users secretly or to modify
> encryption algorithms.
>
> A special type of Trojan horse is a *logic bomb*. It is a program with
> a \"feature\" incorporated into it and this feature often consists of
> the destruction of objects. The bomb is programmed to go off at a
> specific time or when a specific event occurs. The idea behind a logic
> bomb is often to cause as much damage to a system as possible. A
> Trojan horse can enter a system in many ways: it can be planted there
> by another user, it may have entered a system from the network (like
> viruses and worms) or it may have come with any piece of software
> installed in the system. It is normally extremely difficult to
> identify what programs may contain a Trojan horse as well as it can be
> extremely difficult to get rid of a Trojan horse \[34\]. Since the
> most vulnerable target for a Trojan horse is an entity with high
> privileges, this is a motivation for giving entities the least
> possible amount of privileges within a system, as long as they can
> fulfill their working tasks.
>
> **Example 2: Viruses and worms**
>
> Viruses and worms are relatives of Trojan horses. They are programs or
> code sequences designed to spread copies of themselves into other
> programs and to other computers. A virus is a small code sequence that
> modifies other programs into containing a copy of the same virus. A
> virus cannot survive by itself but it needs another program to modify
> and to insert itself into. By \"infecting\" other programs in this
> way, it will spread itself within a system. A worm on the other hand,
> is a program that spreads throughout a system without affecting other
> programs.
>
> The function of a virus or a worm can be to disrupt the service of a
> system or to plant a Trojan horse or a logic bomb into a system. Worms
> and viruses are common in smaller systems lacking protection, but
> systems with a high degree of protection can also be the subject of a
> virus or worm attack \[39\]. Improper handling and incomplete testing
> of software are important channels for the spreading of viruses and
> worms.
>
> **Example 3: Covert channels**
>
> A covert channel is an unprotected channel that can be used by an
> entity to send confidential information to unauthorized entities and
> thereby violate security. In general, it is extremely difficult to
> identify covert channels in a system since they can be of many
> different types: message length variations during transmissions, time
> and length of transmissions, presence and size of files, creation time
> for objects, modulation of disk usage, CPU time usage, etc. It is
> impossible to give a complete list, resulting in that there are no
> simple workable solutions solving all problems with covert channels.
>
> Mandatory encryption of communication is no guarantee that entities
> will not (deliberately or not) send information to another entity over
> a covert channel. For example, it is still possible, while sending
> legal messages to another entity, to modulate the length of messages.
> More importantly this can be done without any users of the system
> being aware of it, since information can be created and sent without
> their knowledge by a Trojan horse.
>
> Sometimes covert channels are divided into two groups: timing channels
> are covert channels modulating a resource in time, and storage
> channels are channels where actions like creation of objects reveal
> information to other entities, for example to choose specific file
> names, file sizes, etc.
>
> It is extremely difficult to eliminate covert channels completely in a
> system, and since a covert channel with a high bandwidth constitutes a
> higher threat than a covert channel with a low bandwidth, most
> security mechanisms try to reduce the bandwidth of these channels as
> much as possible. Even a covert channel with a bandwidth as low as 100
> baud is in some environments considered to be dangerous. However,
> actions to limit covert channel bandwidths always limit system
> performance. For example, in order to avoid the length of messages
> from being used as an information carrier, all messages can be forced
> to be of equal length. The problem with this method is that it reduces
> the available bandwidth of the network as well.
>
> **The Results of Successful Attacks**
>
> There are four fundamental categories of results or conditions that
> can arise from accidental threats or attacks:
>
> **Information Loss or Leakage:** occurs when information is disclosed
> to an unauthorized person or entity.
>
> **Integrity Violation:** occurs when data integrity is compromised due
> to unauthorized destruction, alteration, or creation of data.
>
> **Denial of Service:** occurs when access to information or system
> resources by legitimate users is deliberately obstructed or impeded.
>
> **Illegitimate Use:** occurs when a system resource is used by other
> than legitimate users in an unauthorized way.

### Additional Issues Regarding Threats to Real-Time Embedded Systems

Most of the threat conditions faced by information system developers are
emerging as problems in RT embedded systems. Due to the increased
complexity of software programs and data, and the increased connectivity
of real-time systems (many of which operate on networks), threats from
program flaws, covert channels, and overt attempts to bypass system
controls are very real. Current fictional literature and many instances
in popular film and television, often harbingers of real-life
conditions, depict technically capable persons who are able to bypass
system controls and gain access to vital information or system
capabilities.

Real-time systems can be set up to operate in virtual isolation with
what may appear to be little opportunity for unauthorized access to the
system. However, these systems are not typically developed in isolation,
nor do they operate unchanged for long periods of time. The development
and maintenance operations that these systems undergo provide
opportunities to inadvertently introduce error conditions or
deliberately insert mechanisms to enable covert channel access.

In addition, real-time systems often operate on networks where
information is exchanged with systems that have less stringent
development criteria from a security standpoint. Although precautions
are often taken (physical isolation, firewalls, etc.), many of these
have proven fallible if improperly configured or maintained.

The current trend is for more interconnectivity among RT systems.
Traditional human air-gaps are being eliminated as more
sensor-to-operator systems are developed. As these networks become more
dependent on automated security filters (various guards, firewalls,
etc.) to control data flow, these systems (and the information residing
on them) become more difficult to protect. To make matters worse, these
systems often contain information that is extremely sensitive. In
addition, the integrity of such information (which may be key
intelligence, or control a military combat system) is critical. Also,
the operating systems on many (form, fit, and function) embedded systems
are not as sophisticated as such advanced operating systems as Unix or
NT. Those basic operating systems are frequently incapable of containing
the security functionality necessary to protect those systems, and the
information residing on them.

**The Possibility of RT System Disaster**

Security planning for real-time systems requires a different paradigm of
thinking -- especially in the area of disaster/contingency planning. The
consideration of what constitutes a disaster is quite different in the
real-time systems environment.

A disaster is the occurrence of any adverse event with catastrophic
consequences. For example, if a fire destroyed a major DOD computer
facility, which would certainly, constitute a disaster (system
processing would be disrupted for a significant period of time).
However, if sabotage (or some other adverse event) caused an operating
system interrupt on a real-time embedded system in a power grid, a
plane, or a weapon system, the resulting loss of the availability of
that system for just a few seconds could be disastrous.

The protection of embedded RT systems presents a unique challenge for
the system designer, because the consequences of a disruption in normal
system processing (even a brief operating system interrupt) can be
severe. The integrity and availability of critical RT systems can mean
the difference between life and death for system users, the difference
between success and failure of a critical mission, and (as stated
earlier) even impact national security.

**RISK**

The level of risk to a system, associated from a particular threat, is
derived by considering both the estimated probability of the occurrence
of that event, and the estimated adverse impact that would be expected
to result from the occurrence of that event (this figure is often
expressed in dollars, but can also be expressed in expected loss of
life, political embarrassment, jeopardizing national security, etc. \--
it cannot always be quantified in tangible terms).

**Example:** If one were evaluating the risk of hurricane damage to a
facility in Florida: A level 5 hurricane is the most severe (the adverse
impact would be extremely high); but there have only been a couple of
hurricanes at that magnitude this century in Florida (so the probability
of occurrence is low). A level 2 or 3 hurricane is less severe (less
adverse impact); but Florida has numerous hurricanes at that level (so
the probability of occurrence is much higher). Obviously, in determining
potential hurricane damage, for a Florida facility, both issues
(probability and severity) need to be considered. This same principle
applies to all types of threats.

**RISK MANAGEMENT**

As stated above, the risk associated with the various threats cannot be
completely eliminated, creating a risk-free system. The goal is to
mitigate risk -- to reduce the potential adverse impact posed by the
various threats, down to an "acceptable" level. This process is referred
to as "risk management." The basic steps in the risk management process
are:

1.  **Threats and Vulnerabilities Analysis:** Performing an evaluation
    of the various threats to a system, and the system's vulnerabilities
    to those threats.

2.  **Risk Analysis:** The process of quantifying the anticipated
    adverse impact of all of the most probable threats (see preceding
    section), evaluating the effectiveness of the available safeguards,
    and weighing the costs of those various safeguards against their
    anticipated benefits.

**3. Determination of "Acceptable Level of Risk:"** The final step in
this process is when the Designated Approval Authority (DAA -- must be
the CO or other senior manager) evaluates the information derived from
the two preceding processes. The DAA considers this information, in
addition to a variety of other factors (time requirements, critical need
for the system, budget, etc.). When the DAA is satisfied that there is a
reasonable ("acceptable") level of security functionality to balance
against the other factors he/she must weigh in this decision process,
the DAA makes the official determination that the system is operating at
an "acceptable level of risk." The final decision is at the discretion
of the DAA.

It should be noted that the third step (above) should not be taken
lightly by the DAA. In the pressure to meet tight development deadlines,
it may be tempting for a DAA to simply make a quick "acceptable level of
risk" determination for a system. However, the consequences of a breach
in security can be severe (as noted above); and lead to numerous
investigations from a variety of outside oversight agencies (including
GAO and Congress); and the DAA may be required to explain why he/she
approved the security for that system.

The DAA also has the authority to grant a system an interim authority to
operate, under the condition that certain security deficiencies will be
corrected within a designated period of time (see "Accreditation"
section below).

**SECURITY ARCHITECTURE**

It was noted above that many embedded systems have operating systems
that are not sophisticated enough to have the required security
functionality necessary to protect them. So, on a stand-alone basis, the
operating system would be inadequate to protect the system. However, if
combined with the physical security, and other security functionality
and procedures, that system may still have adequate protection. Security
cannot just be considered relative to a single system component, or
single element of security functionality (e.g., security software
residing on the operating system). When developing security for various
systems, security functionality needs to be addressed in terms of an
entire architecture. A security architecture considers such security
functionality as software security, hardware devices, network
protection, front-end protection, physical security, and various
security procedures. A security architecture is a "big-picture" process,
and should be developed in parallel with the system architecture.

Security considerations need to be addressed at all phases of a system's
life cycle. As the development of a system architecture progresses, the
appropriate security functionality needs to be ensured for all
components of that architecture. The security architecture mirrors the
systems architecture -- with the planned security functionality
(determined from the risk management process) incorporated into it, at
every level.

**CERTIFICATION & ACCREDITATION**

Certification and accreditation constitute a set of procedures and
judgments leading to an official determination of the suitability of the
system to operate in the targeted operational environment.

**Certification**

Certification is conducted in support of the accreditation process. It
is the comprehensive analysis of both the technical and non-technical
security features, and other safeguards of a particular system, to
establish the extent to which that system meets the security
requirements for its operational environment. A complete system
certification must consider factors dealing with the system in its
unique environment, such as its proposed security mode of operation,
specific users, applications, data sensitivity, system configuration,
site/facility location, and interconnections with other systems.

**Accreditation**

The steps outlined in the "Risk Management" Section (above) constitute
the basic elements of the Accreditation process. Accreditation is the
official management authorization to operate a system. The accreditation
normally grants approval for the system to operate:

(a) in a particular security mode

(b) with a prescribed set of countermeasures (administrative, physical,
    personnel, communications security, emissions, and computer security
    controls)

(c) against a defined threat and with stated vulnerabilities and
    countermeasures

(d) within a given operational concept and environment

(e) with stated interconnections to other systems

(f) at an acceptable level of risk for which the accrediting authority
    has formally assumed responsibility

(g) for a specified period of time

The Designated Approving Authority(s) (DAA) formally accepts security
responsibility for the operation of the system; and officially declares
that the specified system will adequately

protect against compromise, destruction, or unauthorized modification
under stated

parameters of the accreditation ("acceptable level of risk"). The
accreditation decision affixes security responsibility with the DAA; and
shows that due care has been taken for security in accordance with the
applicable policies.

An accreditation decision is in effect after the issuance of a formal,
dated statement of

accreditation signed by the DAA, and remains in effect for the specified
period of time

(varies according to applicable policies). A system processing
classified or sensitive unclassified information should be accredited
prior to operation or testing with live data unless a written waiver is
granted by the DAA. In some cases (e.g., when dealing with new
technology, during a transition phase, or when additional time is needed
for more

rigorous testing), the DAA may grant an interim approval to operate for
a specified period

of time. At the end of the specified time period, the DAA must make the
final accreditation decision.

# 

# Security Requirements for RT software systems:

Real time / embedded systems restrict the implementation of security
mechanisms in two ways:

1\. Real time systems impose the requirement of responsiveness, and
predictable timeliness. Security mechanisms implemented must not get in
the way of fulfilling these requirements.

2\. Embedded systems impose the constraints of limited resources, such
as processor power and memory availability. Security mechanisms
implemented must not adversely affect the performance of the primary
function by consuming excessive processor and memory resource.

Given the above constraints, security in real time, embedded system can
be approached in this manner:

1\. Establish a minimum set of robustness at the kernel level.
Robustness can be defined as the ability of a system to perform its
primary function reliably under demanding or hostile conditions. For
example, an operating system that most of us use everyday tends to
\'crash\' even under \'normal\' condition. Such a system is obviously
not robust. From an information security point of view, a robust kernel
is one that does not crash even under invasion by malicious software
code.

One fundamental requirement of kernel robustness is memory protection.
Such a feature prevents the system from crashing due to inadvertent
events such as \'memory leaks\' caused by buggy software, or by
\'deliberately buggy\' software such as viruses.

Another feature is process privilege control. In a multi-processing
system, privilege control can protect the kernel from unauthorized
access to key system process, effectively blocking attacks by malicious
software code.

These two features are fundamental and should be applicable to all
embedded, real-time kernels. For single process kernels, protection
would be more difficult to implement at the kernel and may have to rely
on the higher-level software beyond the kernel.

We should also monitor real life examples of attacks on real-time,
embedded systems, analyze the attack mechanism to see how the kernel
fail in the face of these attacks, then we can add necessary feature to
improve fundamental robustness against similar attacks.

2\. Establish a very extensible and scaleable set of security features
above the kernel or in \'kernel extensions\' such as network protocol
stack, or file systems. This set of security features should be
considered \'added values\' to the operating system. Instead of
mandating vendors to provide them, vendors should be educated and
enticed to implement them as a way to increase their products\' value.

Also, instead of defining a rigid set of APIs with detailed calling
conventions and parameters, we could simply set guideline on the key
aspects of these security features, which, by and large, fall into these
categories:

Confidentiality \-- e.g. Encryption / Decryption functions, callable as
APIs

Integrity \-- e.g. Integrity functions such as hashing routines,
callable as APIs

Authentication \-- e.g. Digital signature signing function, callable as
APIs

Vendors who come up with a rich set of APIs that support these security
functions will no doubt set the standard for these APIs. (Similar APIs
are already available from full features Operating Systems)

A possible solution is to make item 1, robustness, a highly desired, or
even mandatory requirement, and make item 2 value-added features. Item 1
protects the infrastructure, i.e. the platform and the OS, while item 2
protects the information that flow through this infrastructure.

Another tradeoff is between Realtime (deterministic response)
performance requirement and security mechanisms. Certain security
mechanisms (such as encryption and decryption) take time to process. If
such mechanism caused the lost of Realtime performance, then a similar
tradeoff will have to be made. Note that the tradeoff may mean a choice
of a more appropriate security mechanism rather than the elimination of
that mechanism (for example, access control can be implemented as
offline built or as runtime software check. The former imposes no
Real-time overhead while the latter does). Again, such tradeoff or
decision to eliminate certain security mechanism required for the
application domain must be fully documented.

After a set of security requirement is established for the system, the
developer can then determine how these security features be allocated
between the RT/OS API and the application. The table below defines such
a minimum set of security requirements for embedded RT systems.

+----+---------------+-------------------------------+----------------+
| *  | **Fu          | **Security Requirements**     | **Allocated    |
| *N | nctionality** |                               | To**           |
| o. |               |                               |                |
| ** |               |                               |                |
+----+---------------+-------------------------------+----------------+
| 1  | System        | Memory Protection.            | RT/OS API      |
|    | Integrity     |                               |                |
+----+---------------+-------------------------------+----------------+
| 2  | MLS-like      | 1\. Subject-object access     | RT/OS API      |
|    | support       | control mechanism,            |                |
|    |               | (non-intrusive[^1]).          |                |
|    |               |                               |                |
|    |               | 2\. Data labeling mechanism.  |                |
+----+---------------+-------------------------------+----------------+
| 3  | File System   | Guidelines have been          | To be          |
|    | and Network   | established for full          | determined     |
|    | Security      | function, non-real-time OSs   |                |
|    |               | such as UNIX and Windows NT   |                |
|    |               | Kernels. However,             |                |
|    |               | requirements for implemented  |                |
|    |               | on Real-time OSs (such as     |                |
|    |               | LynxOS, VxWorks) are still to |                |
|    |               | be established                |                |
+----+---------------+-------------------------------+----------------+

## ADDITIONAL GLOSSARY ITEMS

**acceptable level of risk**

A management determination (after weighing such elements as: threats,
vulnerabilities, risk, costs, value of assets, budget, time schedule,
and urgency of need) that a system is operating at a reasonable level of
security.

**accreditation**

The official management authorization to operate a system.

**Certification**

Comprehensive evaluation of the technical and non-technical

security features of an information system and other safeguards, made in

support of the accreditation process, to establish the extent to which a

particular design and implementation meet a set of specified security

requirements.

**risk**

The quantification of the expected future adverse impact from a
particular threat, based on its probability of occurrence, and the
anticipated level of damage that would result from its occurrence.

## risk management

The process of weighing the costs of various safeguards and measures,
against their effectiveness in mitigating the risk from various threats,
to achieve an overall acceptable level of risk.

**threats**

Any circumstance or event with the potential to cause harm to a system
in the form of destruction, disclosure, modification of data, and/or
denial of service.

**vulnerability**

A weakness in automated system security procedures, administrative
controls, internal controls, and so forth, that could be exploited by a
threat to gain unauthorized access to information or disrupt critical
processing.

[^1]: Non-intrusive access control mechanism means that the enforcement
    of access control does not intrude into the critical time of a
    Real-time system. An example of such a mechanism is the use of
    off-line built access control table.