Request for Information

Computing security has moved from a niche primarily of interest to the
Government to a concern of high importance for commercial systems in
general. There is a requirement for all critical and safety related
systems (no matter where they are) to be made secure. As systems become
increasingly connected to one another, attacks on systems have become
more commonplace, requiring that more thought be given to reducing the
susceptibility of computing systems to malicious use and exploitation.
The purpose of this Request for Information (RFI) is to solicit
recommendations from the Real-Time Operating Systems (RTOS) community
for mechanisms that would allow incorporation of security features into
their operating systems for building secure applications, and to provide
a stable and robust core on which to build such applications. Mandating
systems to be secure will not make them secure without adequate methods
and means to provide security.

The target domain is real-time and resource constrained systems,
including process control and real-time, embedded systems. Therefore,
the kinds of systems under consideration range from standard desktop or
enterprise-level computing systems with real-time requirements, to
systems that have stringent, hard real-time timing requirements, and
execute in resource constrained environments (e.g. limited memory, no
file system, only custom I/O). However, since security issues for most
desktop and enterprise level systems are covered by, or can be leveraged
from the "General Purpose / non real-time" Operating System community,
our focus is on the resource constrained systems. Due to the wide
spectrum represented by the domain, the expectation is that a "one size
fits all" Application Program Interface (API) approach will not be
suitable. Rather, an approach that is scalable and tailorable is sought
to ensure that only as much security as needed is engendered for any
particular real-time domain (e.g. process control systems, avionics
systems, and automotive control systems). We need an approach that is
extensible. The application developers need the flexibility to add to
RTOS security capabilities in addition to those provided by vendors. It
is assumed that users can configure the RTOS (assuming the RTOS is
modular and configurable) and possible for application developers to add
to the RTOS security capability provided "out of the box."

An extensibility mechanism is expected to allow the basic security
capabilities of an RTOS to be extended to create project specific
security capabilities. For instance, a specific RTOS may not implement
access control lists for all system objects; however, the building
blocks for providing that capability may reside within the functionality
of the RTOS. What is needed is a regular way to access such
functionality in a manner that is supported by RTOS suppliers (i.e. an
interface mechanism that is supported in on-going releases, and NOT
simply modifying the source code of the operating system.)

In summary, we are inviting comments and suggestions for extending RTOS
security capabilities in these three key areas:

1.  Robustness (resilience to exploitation or errors) features of the
    Operating kernel

2.  A tailorable set of security capabilities, (which could be
    implemented as APIs)

3.  A consistent "extension mechanism" for incorporating security
    capabilities (APIs)

# Attachment 1: Initial proposed idea

**Kernel Robustness Attributes:**

Single process system (POSIX 51/53) is not a robust kernel: Ideas are
needed to identify possible approaches to security policy
implementations for these types of systems. In the past security has
been provided by physical isolation and/or controlled accessibility to
the systems. Times have changed and we need better methods/means to
insure security. Input is requested in response to the RFI on how the
RTOS can be managed to help resolve this problem.

Multiprocessing system (POSIX 52/54) require the following attributes:

Memory Protection

Process Management and Creation capability

Process Privilege Control

No unknown service call

Context switching discipline

Clean registers

Clean memory

Provide 'hooks' to report Intrusions

Provide Files system security as extensions (for POSIX 54)

Robust Network Protocol Stack (Not defined as a POSIX profile, may be we
should someday)

Resistant to malicious packets

The list provided is the minimum set of features that need to be
incorporated within the operating system kernel. (Except file system
Security, which could be provided as an extension of the file system).
Since we expect them to be built-in features, we need comments and
suggestions/ideas for keeping their overhead to a minimum. We also
welcome suggestions of additional essential robustness features that we
missed.

**Security Services** **/ Capabilities** **Extensions beyond the
kernel:**

Process / Data security functions

File System Integrity

File system privacy

Labeling support

Network Security functions

Encryption / Decryption functions

Authentication functions

Biometrics functions

PKI Support Function

Security logging:

Intrusion Detection reporting

Security Logging

Intrusion Detection Function

We are requesting input on methods and/or means to provide those
controls that can be standardized across the various RTOS
implementations.

**Extensibility** **mechanism:**

We are requesting that all communities especially Vendor communities
input comments and suggestions in this area. Suggestions and approaches
for providing extensibility are requested. There is a great need to
provide a common accepted approach to give the development/user
communities the methods and means for controlling applied security in
the operating environments. Your response is important and will be given
serious consideration.

**Definitions:**

OS Vendors \-- Those who are in the business of selling RTOS, having the
primarily responsibility of ensuring kernel robustness and providing an
extension mechanism.

Application Developers \-- Those who develop application software on top
of the OS provide by the above. Shall have the reasonability of
selecting and invoking security features required by the application,
using the extension mechanism provided.

End User \-- Those who use the application. Ultimately, they are the
beneficiaries of security work done by the above. Knowledgeable end
users are invaluable in providing security requirement inputs to the
above two groups, from the users\' perspective.