It's been a LONG time since I've posted on here and I wanted to return. One of the recent things I have been working on is trying to "settle the argument" of the DoD's SSE role versus its ISSE role. Below is what I drafted.
Enjoy!
dw
Within the Army’s Acquisition community, there exists today
a lack of clarity when defining and discussing the roles of a System Security
Engineer (SSE) and an Information System Security Engineer (ISSE). This
confusion is due in large part to there being some ambiguity in how the roles
are defined in different publications used within this community. Additionally,
it doesn’t help that the role names are so close to being identical.
Examination of the Official Verbiage
The logical starting point for this discussion is the
examination of what is actually written in the different publications relevant
to both System Security Engineering and Information System Security
Engineering. This discussion will cover the relevant Department of the Army
regulations, DoD’s guidance, and the descriptions of the roles as provided by
NIST.
Army Guidance
The US Army defines the Information System Security Engineer
(ISSE) as being “an individual or a group responsible for conducting information system
security engineering activities, including [AR25-2] [DA PAM25-2-14]:
-
System Architecture
-
System Design
-
System Development
-
System Configuration
Furthermore, Army regulations require that the Program
Manager (PM)/System Manager(SM) assign an Information System Security Engineer
to all IS and PIT systems [AR-25-2][DA PAM25-2-14]. The ISSE should be “fully
integrated into the systems engineering process.”
When discussing the Risk Management Framework (RMF)
specifically, the US Army, in [DA PAM25-2-14] articulates the requirement to integrate
system security engineering into existing processes. Unfortunately, this
statement on its own has caused some confusion as to the ISSE versus SSE role
within DoD and the US Army. There does exist some clarity, discussed later,
when examining publications from both NIST and DoD directly.
The confusion between the SSE and ISSE role is never firmly
answered amongst the multiple levels of regulations and guidance between
Defense Acquisitions through US Army, DoD, and ultimately NIST. However, some
clarity exists in the specific wording chosen in each document.
The ISSE role is specifically identified as being required
in [DA PAM25-2-14].
DoD Guidance
In two tables within [DoD 8570-01M], Table C4.T7 and Table
C10.T7, we find the following:
Table C4.T7.
IAM Level III Functions
M-III.2. Ensure that protection and detection capabilities are
acquired or developed using the IS security engineering approach and are
consistent with DoD Component level IA architecture.
Where “IS” is prepended intentionally to “security
engineering.” We also find the below, an even clearer articulation as to the
name of the role/function.
Table C10.T7.
IASAE Level III Functions
IASAE-III.18. Ensure that acquired or developed system(s) and
network(s) employ Information Systems Security Engineering and are consistent
with DoD Component level IA architecture.
NIST Guidance
Finally, we look at what the different NIST publications have
to say. In [NIST SP800-37] we find a specific definition that, when examined,
shows that there is a difference between SSE efforts and that of an ISSE. The
first definition is:
Systems Security Engineering – Process that captures and
refines security requirements and ensures their integration into information
technology component products and information systems through purposeful
security design or configuration.
Notice that the definition describes the integration of
security requirements into IT products and information Systems. This is not
synonymous with the integration of security requirements into a full system or
system-of-systems. However, one must consider the target audience of this
publication and its content, the Risk Management Framework. In broader scoped
NIST publications, as shown below, this definition is expanded to be
system-holistic and includes cybersecurity concerns, and not solely focused as
the definition above.
Another NIST publication in which its audience and content
must be considered is [NIST SP800-53A]. Two items within this publication
should be considered when examining the relationship between the SSE and ISSE
roles. In the “Target Audience” section, the document uses the term
“information Security Engineers” and does not use the terms Information System
Security Engineers nor System Security Engineers. Later in the document, when
discussing control SA-8 (Security Engineering Principles), the assessment
objective specifically states: “applies information system security engineering
principles” which clearly references the specific role/function of ISSE
efforts.
Finally, [NIST SP800-160 vol I] shows a clear delineation of
the two roles. It should be noted that this publication is title: “Systems
Security Engineering – Considerations for a Multidisciplinary Approach in the
Engineering of Trustworthy Secure Systems”. This is the first of two volumes of
NIST’s System Security Engineer guidance.
[NIST SP800-160 vol I] describes Systems Security
Engineering as focusing on “protection
of stakeholder and system assets so as to exercise control over asset loss and
the associated consequences” and the approach described within the publication
“helps to reduce the susceptibility of systems to a variety of simple, complex,
and hybrid threats including physical and cyber-attacks; structural failures;
natural disasters; and errors of omission and commission”. As this shows, the
publication specifically states that SSE efforts include but is not confined to
cyber aspects. The publication further states that:
“Systems
security engineering, as an integral part of systems engineering, helps to
ensure that the appropriate security principles, concepts, methods, and
practices are applied during the system life cycle to achieve stakeholder objectives
for the protection of assets—across all forms of adversity characterized as
disruptions, hazards, and threats.”
Again, this shows that NIST SP800-160 does not confine SSE
to only the cybersecurity realm, which the publication specifically articulates
a few sentences later:
“Systems security engineering leverages many security
specialties and focus areas that contribute to systems security engineering
activities and tasks. These security specialties and focus areas include, for
example: computer security; communications security; transmission security;
anti-tamper protection; electronic emissions security; physical security;
information, software, and hardware assurance; and technology specialties such
as biometrics and cryptography.”
Comparing the Guidance
It is obvious that there is no apparent agreement in ISSE
and SSE definitions between the US Army, DoD, and NIST publications. However,
as shown here, when the content and audience of each individual publication is
considered, the difference between the two roles becomes clearly defined.
System Security Engineering – the processes of examining and
applying security requirements holistically to a system or system of systems.
These requirements are derived from multiple domains including cybersecurity,
physical security, etc.
Information System Security Engineering – the process of
examining and applying cybersecurity requirements to a system or system of
systems. These requirements are primarily derived via the RMF process and are
defined by NIST Controls [NIST SP800-53r4] and DISA’s Control Correlation
Identifiers.
What is an ISSE?
Looking at some of the referenced definitions above, it
becomes simple to state from a very high level the actions associated with the
ISSE role. Specifically, recall that [AR25-2] [DA PAM25-2-14] identify four primary areas of the ISSE
focus. These four areas are:
-
System Architecture
-
System Design
-
System Development
-
System Configuration
The word System
has been defined within [ISO/IEC/IEEE 15288:2015] as:
-
A set of interacting elements (i.e., system
elements) organized to achieve one or more stated purposes.
In order to understand the role of the ISSE within the scope
of the Risk Management Framework, we must refine the definition of System to the following:
-
A set of interacting elements (i.e., system
elements) organized to process Department of Defense (DoD) data and/or connect
to a DoD Network.
With the appropriated scoped definition of System, we can further define these four
target areas and the ISSE’s role within each.
System Architecture
According to [ISO/IEC/IEEE 15288:2015], System Architecture
can be defined as “fundamental concepts or properties of a system in its
environment embodied in its elements, relationships, and in the principles of
its design and evolution”. In other words, a [normally] high-level description
of a system and its internal and external interactions.
The ISSE role regarding system architecture is examine and
evaluate the proposed interactions and environment of the system. The ISSE best
serves the program by asking specific questions about these high level
interactions, the operational environment, and potential alternatives.
An example of the ISSE function at this level be the
examination of proposed wireless protocols, the spectrum management/saturation
of the operational environment, and the feasibility of the sub-systems connecting
via a proposed wireless protocol.
System Design
Design is defined by [ISO/IEC/IEEE 15288:2015] in two ways:
-
Information, including specification of system
elements and the relationships, that is sufficiently complete to support a
compliant implementation of the architecture
-
Provides the detailed implementation-level
physical structure, behavior, temporal relationships, and other attributes of
system elements
Typically overlooked by ISSEs, or even excluded by design
leads, the system design area is a critical area where the expertise of the
ISSE should be leveraged heavily. The ISSE should be examining the protocols,
transmission mediums, and system instrumentation/performance requirements, at
both the hardware and software levels. This examination should identify
conflicts and potential cost drivers that may have alternatives.
An example of the ISSE function during this process would be
that of examining proposed hardware items to verify their ability to support a
required encryption schema in terms of both cycle time and system power.
Another example would be the examination of the physical design to ensure that
cyber-physical requirements can be sufficiently and appropriately satisfied.
System Development
Development refers to the process, life cycle, or framework
that is utilized within the program in order to implement the system
architecture and design into a given system or system of systems.
The role of the ISSE during System Development really
involves the entire lifecycle of the program and will vary depending upon the
specific process, framework, or lifecycle used to develop the system/system of
systems.
The primary role of the ISSE with this domain is to insure
that the appropriate inject points exist in each phase of the development in
order to ensure that cybersecurity requirements and affects are account for at
the appropriate juncture.
System Configuration
Configuration refers to the specific items and details that
are the realization of the architecture, design, and development processes.
This phase has the lowest level of granularity and is intended to manage a
system/system of systems from development through disposal. Items are tracked
specifically by manufacturer information and serial number. Changes to the
system, to include item replacements are both approved prior to action and
documented.
The ISSE typically does not play a direct role in maintaining
a system’s configuration. However, the ISSE should be involved in all
cyber-related configuration changes and updates. This involvement requires that
the ISSE provide expertise in the potential and known impacts of a given
potential change to the system.
What is an SSE?
As stated above, the SSE role is one that applies security
requirements holistically to a system. These requirements come from both
security-based engineering domains such as cyber and physical, and from
non-security-based engineering domains such as human factors engineering
(Ergonomics) and Reliability, Availability, and Maintainability (RAM)
Engineering.
Traditionally and by best practice, the SSE comes from the
Systems Engineering field and has a broad understanding of many engineering
disciplines. This means that an ISSE with additional engineering experience can
most likely fill the role of an SSE, the less-granular understanding of
cybersecurity engineering makes the SSE a poor choice to fill the ISSE role.
Although not specified in the literature, it is generally
safe to assume that, like the ISSE, the SSE provides engineering assistance in
four domains:
-
System Architecture
-
System Design
-
System Development
-
System Configuration
The difference however, and an important one, is the
definition of System as relates the SSE supporting these four areas. For that,
we go back to the original definition as found in [ISO/IEC/IEEE 15288:2015]:
-
A set of interacting elements (i.e., system
elements) organized to achieve one or more stated purposes.
This means that the general actions of the SSE within these
four areas are the same as the ISSE with the understanding that the SSE is not
looking solely at Cybersecurity requirements but at many requirements from
multiple security and non-security engineering disciplines.
[NIST SP 800-160 vol 1] goes into great, very granular,
detail regarding the System Security Engineering process and the function of
the System Security Engineer. There are numerous and specific tasks as well as
an excellent framework (which makes prudent use of a closed-loop feedback) for
this process.
Conclusion
The roles of the ISSE and SSE are separate, although at
times complementary, functions within the system development life cycle. This
should be obvious to the reader when considering the target audience, wording,
and scope of the references cited herein.
