MULE - MULTIFUNCTION UTILITY/LOGISTICS EQUIPMENT VEHICLE
UGCV - UNMANNED GROUND COMBAT VEHICLE
GLADIATOR TUGV - TACTICAL UNMANNED GROUND VEHICLE
Click for Objective Goals Info ...
Click for Operational Capabilities (ConOps) Info ...
Click for UGVs Info ...
Click for UAVs Info ...
Click for JAUS Info ...
Click for DO-178B Info ...
Click for EAL1-7 Info ...
Click for MILS Info ...
MULE - MULTIFUNCTION UTILITY/LOGISTICS EQUIPMENT VEHICLE
UGCV - UNMANNED GROUND COMBAT VEHICLE
GLADIATOR TUGV - TACTICAL UNMANNED GROUND VEHICLE
NGs MQ-88 Fire Scout Vertical Unmanned Aircraft System (VUAS) STANAG 4586
compatible ground control station (GCS)
Broad Area Maritime Surveillance Unmanned Aircraft System (BAMS UAS)
Bat Unmanned Aircraft System (UAS)
RQ-4 Block 10 Global Hawk
RQ-4 Block 20 Global Hawk The U.S. Air Force's desire to expand Global Hawk's role supporting the service's ISR mission launched the development of a more capable and powerful unmanned surveillance system.
M324 UAS (Unmanned Aerial System)
The JAUS Reference Architecture, which is no longer being maintained, is a
component based message passing architecture that defines a data format
and methods of communication between computing nodes. The architecture
dictates a hierarchical system built up of subsystems, nodes and
components, and contains a strictly defined message set to support
interoperability. Significant portions of the architecture, including the
definitions for subsystem, node and component, have been loosely defined
in order to accommodate for the five principles that it is based on.
The architecture has migrated from the JAUS Working Group which was
comprised of individuals from the government, industry and academia to the
Society of Automotive Engineers, Aerospace Division, Avionics Systems
Division. The AS4, Unmanned Systems Technical Committee now maintains and
advances the set of standards. The following standards have been migrated
from the JAUS Reference Architecture to a services based framework:
AS5669, JAUS Transport Standard. Defines packet construction addressing
transport concerns including header compression, source/destination
addressing, TCP, UDP and Serial links. AS5669 defines the format of a JAUS
message as it flows between systems in an Ethernet (TCP and UDP) or serial
data link.
AS5710, JAUS Core Service Set. Establishes a common set of services for
distributed systems communication and coordination. The Core Service Set
includes service definitions for transport, events, access control,
management, time, liveness and discovery.
AS6009, JAUS Mobility Service Set. This standard migrates the primitive
driver, waypoint and path segment drivers, along with the
position/orientation components and messaging to the SAE JAUS set of
standards. Others currently in draft include:
Software level
The Design Assurance Level (DAL) is determined from the safety assessment
process and hazard analysis by examining the effects of a failure
condition in the system. The failure conditions are categorized by their
effects on the aircraft, crew, and passengers.
Catastrophic - Failure may cause a crash.
Hazardous - Failure has a large negative impact on safety or performance,
or reduces the ability of the crew to operate the aircraft due to physical
distress or a higher workload, or causes serious or fatal injuries among
the passengers.
Major - Failure is significant, but has a lesser impact than a Hazardous
failure (for example, leads to passenger discomfort rather than injuries).
Minor - Failure is noticeable, but has a lesser impact than a Major
failure (for example, causing passenger inconvenience or a routine flight
plan change)
No Effect - Failure has no impact on safety, aircraft operation, or crew
workload.
The number of objectives to be satisfied (eventually with independence) is determined by the software level. The phrase "with independence" refers to a separation of responsibilities where the objectivity of the verification and validation processes is ensured by virtue of their "independence" from the software development team. In some cases, an automated tool may be equivalent to independence[2].
The National Information Assurance Partnership (NIAP) is a U.S. Government
initiative by the National Institute of Standards and Technology (NIST)
and the National Security Agency (NSA).
To achieve a particular EAL, the computer system must meet specific
assurance requirements. Most of these requirements involve design
documentation, design analysis, functional testing, or penetration
testing. The higher EALs involve more detailed documentation, analysis,
and testing than the lower ones. Achieving a higher EAL certification
generally costs more money and takes more time than achieving a lower one.
The EAL number assigned to a certified system indicates that the system
completed all requirements for that level.
Although every product and system must fulfill the same assurance
requirements to achieve a particular level, they do not have to fulfill
the same functional requirements. The functional features for each
certified product are established in the Security Target document tailored
for that product's evaluation. Therefore, a product with a higher EAL is
not necessarily "more secure" in a particular application than one with a
lower EAL, since they may have very different lists of functional features
in their Security Targets. A product's fitness for a particular security
application depends on how well the features listed in the product's
Security Target fulfill the application's security requirements. If the
Security Targets for two products both contain the necessary security
features, then the higher EAL should indicate the more trustworthy product
for that application.
Assurance levels
EAL1: Functionally Tested
EAL1 is applicable where some confidence in correct operation is required,
but the threats to security are not viewed as serious. It will be of value
where independent assurance is required to support the contention that due
care has been exercised with respect to the protection of personal or
similar information. EAL1 provides an evaluation of the TOE (Target of
Evaluation) as made available to the customer, including independent
testing against a specification, and an examination of the guidance
documentation provided. It is intended that an EAL1 evaluation could be
successfully conducted without assistance from the developer of the TOE,
and for minimal cost. An evaluation at this level should provide evidence
that the TOE functions in a manner consistent with its documentation, and
that it provides useful protection against identified threats.
EAL2: Structurally Tested
EAL2 requires the cooperation of the developer in terms of the delivery of
design information and test results, but should not demand more effort on
the part of the developer than is consistent with good commercial
practice. As such it should not require a substantially increased
investment of cost or time. EAL2 is therefore applicable in those
circumstances where developers or users require a low to moderate level of
independently assured security in the absence of ready availability of the
complete development record. Such a situation may arise when securing
legacy systems.
EAL3: Methodically Tested and Checked
EAL3 permits a conscientious developer to gain maximum assurance from
positive security engineering at the design stage without substantial
alteration of existing sound development practices. EAL3 is applicable in
those circumstances where developers or users require a moderate level of
independently assured security, and require a thorough investigation of
the TOE and its development without substantial re-engineering.
EAL4: Methodically Designed, Tested, and Reviewed
EAL4 permits a developer to gain maximum assurance from positive security
engineering based on good commercial development practices which, though
rigorous, do not require substantial specialist knowledge, skills, and
other resources. EAL4 is the highest level at which it is likely to be
economically feasible to retrofit to an existing product line. EAL4 is
therefore applicable in those circumstances where developers or users
require a moderate to high level of independently assured security in
conventional commodity TOEs and are prepared to incur additional
security-specific engineering costs.
Commercial operating systems that provide conventional, user-based
security features are typically evaluated at EAL4. Examples of such
operating systems are AIX[1], HP-UX[1], FreeBSD, Novell NetWare,
Solaris[1], SUSE Linux Enterprise Server 9[1][2], SUSE Linux Enterprise
Server 10[3], Red Hat Enterprise Linux 5[4], Windows 2000 Service Pack 3,
Windows 2003[1][5], Windows XP[1][5].
Operating systems that provide multilevel security are evaluated at a
minimum of EAL4. Examples include Trusted Solaris, Solaris 10 Release
11/06 Trusted Extensions,[6] an early version of the XTS-400, and VMware
ESX version 3.0.2[7].
EAL5: Semiformally Designed and Tested
EAL5 permits a developer to gain maximum assurance from security
engineering based upon rigorous commercial development practices supported
by moderate application of specialist security engineering techniques.
Such a TOE will probably be designed and developed with the intent of
achieving EAL5 assurance. It is likely that the additional costs
attributable to the EAL5 requirements, relative to rigorous development
without the application of specialized techniques, will not be large. EAL5
is therefore applicable in those circumstances where developers or users
require a high level of independently assured security in a planned
development and require a rigorous development approach without incurring
unreasonable costs attributable to specialist security engineering
techniques.
Numerous smart card devices have been evaluated at EAL5, as have
multilevel secure devices such as the Tenix Interactive Link. XTS-400
(STOP 6) is a general-purpose operating system which has been evaluated at
EAL5 augmented.
LPAR on IBM System z is EAL5 Certified.[8]
EAL6: Semiformally Verified Design and Tested
EAL6 permits developers to gain high assurance from application of
security engineering techniques to a rigorous development environment in
order to produce a premium TOE for protecting high value assets against
significant risks. EAL6 is therefore applicable to the development of
security TOEs for application in high risk situations where the value of
the protected assets justifies the additional costs. An example of an EAL6
certified system is the Green Hills Software INTEGRITY-178B operating
system, the only operating system to achieve EAL6 thus far.[9]
EAL7: Formally Verified Design and Tested
EAL7 is applicable to the development of security TOEs for application in
extremely high risk situations and/or where the high value of the assets
justifies the higher costs. Practical application of EAL7 is currently
limited to TOEs with tightly focused security functionality that is
amenable to extensive formal analysis. The Tenix Interactive Link Data
Diode Device has been evaluated at EAL7 augmented, the only product to do
so.
Reference:
http://en.wikipedia.org/wiki/Evaluation_Assurance_Level
A MILS solution allows for independent evaluation of security components
and trusted composition.[2][3] MILS represents a relatively new (15 years)
approach to building secure systems in contrast to the older Bell and La
Padula theories on secure systems that represent the foundational theories
of the DoD Orange Book.
A MILS system employs one or more separation mechanisms (e.g., Separation
kernel, Partitioning Communication System, physical separation) to
maintain assured data and process separation. A MILS system supports
enforcement of one or more application/system specific security policies
by authorizing information flow only between components in the same
security domain or through trustworthy security monitors (e.g., access
control guards, downgraders, crypto devices, etc).
Properties:
Non-bypassable: a component can not use another communication path,
including lower level mechanisms to bypass the security monitor.
Evaluatable: any trusted component can be evaluated to the level of
assurance required of that component. This means the components are
modular, well designed, well specified, well implemented, small, low
complexity, etc.
Always-invoked: each and every access/message is checked by the
appropriate security monitors (i.e., a security monitor will not just
check on a first access and then pass all subsequent accesses/messages
through).
Tamperproof: the system controls "modify" rights to the security monitor
code, configuration and data; preventing unauthorized changes.
A convenient acronym for these characteristics is NEAT.
'Trustworthy' means that the component have been certified to satisfy well
defined security policies to a level of assurance commensurate with the
level of risk for that component (e.g., we can have single level access
control guards evaluated at CC EAL4; separation mechanisms evaluated at
High Robustness; two-level separation guards at EAL 5; and TYPE I crypto
all in the same MILS system).
'Untrusted' means that we have no confidence that the system meets its
specification with respect to the security policy.
Reference:
http://en.wikipedia.org/wiki/Multiple_Independent_Levels_of_Security
Multiple Independent Levels of Security/Safety (MILS) is a high-assurance
security architecture based on the concepts of separation[1] and
controlled information flow; implemented by separation mechanisms that
support both untrusted and trustworthy components; ensuring that the total
security solution is non-bypassable, evaluatable, always invoked and
tamperproof.