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.