SOFTWARE-DEFINED SECURITY SERVICESFRAMEWORK VERSION 2.1

A white paper from the ONUG 2017 Software-DefinedSecurity Services Working Group

April, 2017

Table of ContentsDocument Scope

Out of Scope

Executive Summary

Introduction

Software-Defined Security Services Core Security Requirements Core Security Requirements Term Definitions Core Security Requirements Statement

Use Case

Use Case Voting

Top Three Use Cases & Requirements Use Case #1 (Formerly Use Case #8) Use Case #2 (Formerly Use Case #9) Requirements Shared By Use Cases #1 & #2 Use Case #3 (Formerly Use Case #4)

WG’s Top Ten Requirements

Conceptual Framework Diagrams

Spring 2017 S-DSS White Paper Additions Policy Enforcement Everwhere From “Problem Space” To “Solution Space”

Conclusion

Definition of Terms

ONUG Software Defined Security Systems Working Group Members

Definition of Open Networking

Open networking is a suite of interop-erable software and/or hardware that delivers choice and design options to IT business leaders, service, and cloud providers. At its core, open network-ing is the separation or decoupling of specialized network hardware and software – all in an effort to give IT ar-chitects options in the way they choose to design, provision, and manage their networks. These technologies must be based on industry standards. The standards can be de-facto as adopted by a large consortium of the vendor community, open in the sense that they are community-based, or defined as standards by the prevailing standards bodies. Open networking hopes to deliver on two promises:

1) Decoupling of network hardware and software, which serves to miti-gate vendor lock-in and shifts network architecture structure options to users

2) Significant reduction of total cost of network ownership

4

4

4

5

5

7

8

9

12

13

13

16

18

22

Information Systems & Security

Security as a concept and as a practice has extremely wide scope. It touches upon virtually every activity in business and deals proactively with the management of risk. Across the information technology (IT) landscape, security addresses specific concerns within the physical, administrative, and technical business realms, while also manifesting its own set of special challenges in dealing with the complexity and cost that attend these activities.

Generally, information security deals with the risks presented by threats to the confidentiality, integrity, and availability of information assets (i.e.: the security triad - often abbreviated as “CIA”). Information assets are represented by data and the information services and supporting systems that manage data.Information services are assembled, deployed and operated to enable data and information to becreated, shared, and used by the enterprise to pursue its business interests, execute its mission, and deliver value to its stakeholders. The purpose of information security and information assurance is to ensure that these assets are there to support the business. The security triad (CIA) is a well-known and commonly used term throughout the global InfoSec community. It was officially codified by the U.S. government under the Federal Information Security Management Act of 2002 (FISMA).

Every information service comprises one or more service elements, each of which is dependent on one or more systems to perform specific functions under stated conditions on behalf of service consumers. It is the combination of functions deployed across these systems that defines the composition of the service. Every system supporting an information service (or a service element thereof) is composed from some combination of people, processes, and technologies, where each of these constituent elements brings with it its own specific set of security concerns. These concerns include technology vulnerabilities (defects in architecture, design, implementation, deployment, operation, support, retirement) that make a system susceptible to failure and threats that may trigger or exploit a vulnerability. Similarly, both people and processes possess vulnerabilities that can make those system elements susceptible to failure (e.g., via illness, human failure, procedural flaws, and complexity). The potential of encountering any of these flaws represents risk to the business. As a result, information security requires taking a holistic approach to how information systems are developed, deployed, operated, sustained, and retired (the system lifecycle). This is applicable across all of the constituent elements that define the system.

A properly engineered information system considers early on in its lifecycle the need for specific security controls – safeguards and countermeasures – required to deal with vulnerabilities and protect information assets from threats, both naturally occurring and adversarial. These early considerations are driven by security principles and policies established by the enterprise, as well as by regulations and laws imposed by oversight and governing bodies. These drivers, together with the assessed risks to the business and its assets, give rise to the security requirements for information systems.

The proper engineering of any system relies first upon understanding the problem at hand and then craft-ing an architecture and solution that solves the problem. Within the discipline of systems engineering, there is a clear distinction between the problem space and the solution space that results in a separation of activities, roles and responsibilities between the two. The problem space involves understanding what needs to be accomplished, while the solution space deals with how to accomplish it. While an obvious distinction, it is absolutely critical to keep this in mind, for the activities associated with developing re-quirements properly fall within the problem space, and the problem space only. In our view, it is accord-ingly the responsibility of those consuming a product or service (the customers) to articulate their specific and detailed needs to the supplier(s) that provide that product or service. Conversely, the activities, roles and responsibilities associated with delivering a product or service sit squarely in the solution space – where product and service suppliers work to satisfy the needs expressed by their customers through requirements. The definition of requirements therefore constitutes an agreement between the supplier and consumer that specifies what the supplier will provide to the consumer in order to be successful in the marketplace.

Document ScopeThis document provides a set of tactical and strategic baseline requirements to help guide technology suppliers (vendors) in the development of products and services that will enable enterprise customers in their selection and deployment of Software-Defined Security Services (S-DSS). While the impacts discussed are commensurate with the Information Technology Infrastructure Library (ITIL) service delivery model, enterprises can leverage the information for a Request for Information (RFI) and adapt to scale and suit their current or planned organizational support delivery and maturity capabilities. The ONUG S-DSS working group seeks to define requirements for software-defined products that are capable of delivering protections for confidentiality, integrity, and availability of data and information systems equivalent to that currently provided by physically isolated networks and infrastructure.

Out of ScopeThe working group focused its efforts on what is needed to deliver on three important S-DSS use cases to the enterprise market. The working group did not focus and does not offer the “how”; that is, there is no specific protocol(s) or Application Program Interface(s) (APIs) specified to deliver on the S-DSS use cases. The working group leaves that work to the vendor and standards communities. ONUG strongly encourages open interfaces and protocols in the construction of multivendor interoperable S-DSS solutions to deliver the greatest value and choice to enterprise IT executives. Further, the working group does not specify where various S-DSS functions should reside – that is, within physical or virtual products, as modules within existing products or standalone products. That is up to the vendor community.

Executive SummaryThe ONUG S-DSS working group prioritized its efforts around three fundamental use cases, which stress that security policies should be bound to workloads independent of how those workloads are created; that is, whether the workload runs with a virtual machine (VM), container, application or applications based upon microservices or unikernels. Further, security policy should be portable, meaning: policy can be written in one place and deployed in multiple locales, where workload policy enforcement is distributed close to said workload. Verification and auditability of security policy must be enabled to measure the ability of network workloads to ensure the confidentiality, integrity, and availability of the services they are deliver-ing. Security policy bound to workloads, policy portability, distributed enforcement local to that workload, and verification constitute the minimum set of requirements for cloud-based applications and hybrid-cloud deployments within a software- defined infrastructure. In short, these are the minimum security requirements for Software-Defined Security Services.

This document defines an open framework and a common set of functional solution requirements for one of the open networking use cases – Software-Defined Security Services (S-DSS) – identified by the ONUG Board. The content of this document is intended to provide general guidelines for:

• IT enterprise end users to compare vendor solutions and develop RFIs and formal RFP specifications;

• IT vendors to develop and align product requirements;

• Standards organizations to align their initiatives and efforts to deliver an open approach to S-DSS.

Open Networking User Group(ONUG)

ONUG is one of the largest indus-try user groups in the IT infrastruc-ture market. Its board is comprised exclusively of IT business leaders, with representation from Fidelity Investments, FedEx, BNY Mellon, Bank of America, Intuit, UBS, Pfizer, GE, JPMorgan Chase, Morgan Stanley, Citigroup, Credit Suisse, Gap, Yahoo!, eBay and TD Ameritrade. The ONUG mission is to enable greater choice and options for IT business leaders by advocating open, interoperable hardware- and software-defined infrastructure solutions that span the entire IT stack, all in an effort to create business value.

The ONUG community is led by IT business leaders and aims to drive industry dialogue to set the technology direction and agenda with vendors, standards and open source organizations. To that end, ONUG hosts two major conferences per year where use cases are developed and members vote to establish a prioritized list of early adopter, open interop-erable hardware and software-de-fined infrastructure projects that communicate propensity to buy and budget development. The vendor community stages proof of concepts based upon ONUG Use Cases, while standards and open source organi-zations prioritize their initiatives and investments based upon them. ONUG organizes working groups to fully develop use cases and set industry initiatives. ONUG also hosts user sum-mits and smaller, regional user-focused Fireside Chat Meet-Ups through the year.

Defining a common set of solution requirements aligns with ONUG’s goal to drive the IT vendor and standards communities to deliver open interoperability solutions to provide IT business leaders maximum choice and flexibility in deploying open IT framework solutions. The expectation is that this document provides a common baseline, covering a set of enterprise needs for S-DSS solutions. The assumption being made is that this set of requirements will be extended by enterprise-specific requirements to meet specific deployment needs. As the security services working group developed the S-DSS use case, it found that there are, in fact, multiple use cases as the industry transitions from a hardware-based infrastructure to software-defined infrastructure, as discussed below. This version of the white paper document provides several initial, critical use cases in what is meant to be the basis for a new computer network security market.

IntroductionLike building a house or any other structure, secure systems require a solid foundation. The foundations of secure information systems are built upon fundamental concepts that address specific needs supporting confidentiality, integrity, and availability. Within information system security engineering, these fundamentals form the framework by which higher-level security concepts, such as identity, authentication, authorization, auditing, and non-repudiation, are expressed. These concepts, along with still higher-level constructs and with the principle of defense–in–depth, form the security profile for a system.

The security profile represents a set of requirements that the information system must satisfy to be considered “secure” within the business environment. In the context of a software-defined infrastructure (SDI), these requirements are aimed at the technology suppliers (OEMs & ISVs) whose products and services comprise the infrastructure.

As such, it is incumbent upon those articulating needs to be clear about what is being required – both in terms of concepts and language. This includes ensuring that key terms used to construct statements of need (requirements) are unambiguous and well understood between the suppliers and consumers. To accomplish this, an agreed upon vocabulary and taxonomy is needed between those specifying the requirements and those acting upon them. The goal in developing a requirements definition is to define a meaningful set of needs statements that are considered concise, complete, relevant, understandable, non-conflicting, testable, and attainable. In other words, such requirements must be actionable on the part of technology suppliers within their product development cycles so as to deliver products that satisfy the consumers they serve.

Software-Defined Security ServicesThe concept of Software-Defined Security Services (S-DSS) is intended to define security services needed as IT infrastructure transitions from hardware-based to a software-defined market. Here, S-DSS describes the set of network-based security controls (safeguards and countermeasures) that overlay an administrative domain within a trusted boundary formed through confidentiality, integrity, identity, authentication, and authorization that spans untrusted physical and logical boundaries to satisfy a specified security policy.

This definition is intended to cover an almost limitless combination of architectures that are able to comprise both physical and virtual systems, scale across wide geographical distances and over multiple protocols, while also employing different deployment and operational models. This implies that the constituent physical or virtual elements comprising the SDI be resilient in their own right; that is, capable of ensuring that their own confidentiality, integrity, and availability characteristics remain sufficiently intact under defined adverse conditions without reliance on external protections. This further suggests the existence of a set of foundational (or core) security requirements that must be satisfied by each system element supporting the S-DSS to achieve component resiliency

Core Security Requirements

The definition of a “core requirement” is one that is generally applicable across the larger problem space being considered. In this case, a technology supplier whose product or service satisfies such needs would provide an offering with many of the characteristics necessary to deliver secure services. The initial list that follows is not intended to be exhaustive, but rather to provide a baseline starting point for a framework of requirements that can be extended to build higher-level requirements that would inherit the security protections indicated.

The assertion being made here – and explicitly so – is that products delivered to the marketplace (and thus by definition to the ONUG community) cannot address the security concerns of critical infrastructure and high impact business environments unless these foundational requirements are satisfied.

IETF RFC 2119 provides a lightweight, consistent, and convenient method along with guidance for constructing requirements. In adopting RFC 2119 for defining requirements, the needs articulated below will incorporate the use of specific key words to establish the force of the requirements as stated. The key words “MUST,” “MUST NOT,” “REQUIRED,” “SHALL,” “SHALL NOT,” “SHOULD,” “SHOULD NOT,” “RECOMMENDED,” “MAY,” and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

Core Security Requirement Term Definitions

The following definitions are provided to establish baseline meaning and context for important terms used within individual core secu-rity requirement statements appearing below. The terminology describes the operational relationship between subjects and objects in a system. This subject-object relationship is commonly used throughout security engineering practice and is being adopted here to express foundational security needs. As such, these terms are employed as generic synonyms intended to replace specific nouns and noun/verb pairs that would otherwise imply or prescribe a specific architecture, design, or implementation of a requirement.

• The term “object” will be defined as an abstract representation of a tangible or intangible thing – a system, system element, system-of-systems, code, data or other resource – having a defined interaction or access relationship with a subject.

• The term “subject” will be defined as an abstract representation of an actor – a human, machine or other entity operating with intent – having a defined interaction or access relationship with an object.

• The term “security” or “secure” will be defined as maintaining the systemic properties of confidentiality, integrity, and availability for an object or object resource within a stated operational context and access policy.

• The term “network-enabled object” will be defined as a physical or virtual object (e.g., switch, router, sensor, server, appliance, device) having presence on a network within an administrative domain and under governance of an administrative policy and actions.

• The term “data element” will be defined as a named identifier with associated value and data type (e.g., integer, float, string, enumeration, data structure).

• The term “control function” will be defined as any method authorized to invoke an action that alters the operational state of an object on behalf of an authorized subject.

Core Security Requirement Statement

The definition of core security requirements is intended to be generally applicable to individual products or services offered by technology suppliers to the ONUG community (and ultimately, beyond). These requirements are applicable to any and all products or services, regardless of their role in the network and are to be evaluated collectively and in total. As the following list of requirements is indeed “core,” we forgo the priority assignments here, but apply them for individual use cases below.

1. A network-enabled object must provide for a logically-isolated (from other object functions), secure, logical, or physical out-of-band network interface, purpose-built to facilitate the secure monitoring and administration of the object throughout each stage of its in-service lifecycle (i.e., deployment, operation, maintenance, retirement).

2. A network-enabled object must provide secure methods and interfaces for implementing mandatory access controls to facilitate policy-based subject access to the object and its resources.

3. A network-enabled object must be capable of exposing the full set of available operational state reporting and administrative control function elements using a secure method and interface to an authorized subject.

4. A network-enabled object must limit exposure of elements pertaining to its operational state and administrative control func-tions to only those elements granted to a subject based on the subject’s authorization profile and use context (e.g., a polymorphic interface rendering a view/projection of available state and control resources available to a particular subject).

5. A network-enabled object must provide secure methods and interfaces for querying the object’s state by facilitating the retrieval of a specified set of operational data elements on behalf of an authorized subject.

6. A network-enabled object must provide secure methods and interfaces for establishing clipping levels, or thresholds, as mutable values associated with operational data elements to detect state changes within the object. The object must provide a related

method, expressed through the same interface, to define action events that may be invoked within the object and/or notifications to be sent to cooperating entities (subjects or other objects), when the object’s operational state change results in a transition across (e.g., below to above, or above to below) a specified level.

7. A network-enabled object invoking an action event or issuing a notification in response to a state transition across an established clipping level or threshold must result in output of one or more notifications (e.g., log entries) sent to one or more specified receiv-ing (e.g., logging) destinations, and include as metadata/header information in each message:

• A precision timestamp derived from a time source with known accuracy, reliability, and integrity, having resolution of not less than 1ms and in a format consistent with Internet date/time formats described by RFC 3339 and ISO 8601;

• A unique (deterministically resolvable) name or identifier of the source object issuing the notification entry (e.g., system, device, process);

• An event priority level indicating the importance of the event to the administrative domain’s operational context and policy;

• A human readable event description issued using the preferred language of the administrative domain;

• An object-specific payload and format containing encoded data elements/information relevant to the event - the payload may be null;

• In the absence of a secure communications channel, a message authentication code (MAC) and associated trust chain attesting to the integrity of the message payload and its metadata/header information.

8. A network-enabled object must validate inputs for each mutable administrative control data element modified by an authorized subject and enforce input values and ranges based on the access policy governing the subject.

9. A network-enabled object must provide secure methods and interfaces to facilitate in-band confidentiality of data in transit (e.g., encryption on the wire and/or over the air) as the default operational mode.

10. A network-enabled object must provide secure methods and interfaces to facilitate in-band confidentiality of data at rest (e.g., encrypted in storage) as the default operational mode.

11. A network-enabled object must be capable of secure, unattended startup (boot) and shutdown (halt) without exposing confidential data or administrative credentials/keys over insecure channels or protocols.

12. A network-enabled object must provide secure programmatic methods and interfaces to facilitate object monitoring and administrative control by authorized, cooperating objects. Programmatic interfaces should include language bindings for current (2016) as well as available prior versions dating back two years of: ANSI C/C++, Java, Ruby, Perl, Python, PHP, and W3C-compliant HTML5 with requisite extensions and/or supporting markup languages.

13. A network-enabled object should incorporate quantum-resistant protocols (e.g., lattice-based cryptography) to mitigate long-term risks associated with deferred cryptanalysis of intercepted data, facilitated through emerging quantum technologies (i.e., intercept now, decrypt later).

Use CasesDuring the winter months of 2016/2017, the ONUG S-DSS working group met twice a month exclusively with IT executives to capture common security use cases associated with SDI. Two design principles emerged that are fundamental to the following use cases:

1) Software-defined infrastructure must possess a common language to define declaratives and policies that can be consumed up and down the IT stack, physically and virtually.

2) Software-defined infrastructure must be able to instantiate an “Internet-facing workload” in a software-defined data center that provides protection equivalent to today’s physically isolated networks.

It is with these design principles in mind that the following nine use cases emerged:

1) Dynamically capture packets from both bare metal switches and vSwitches

2) Ensure networks possess “data awareness” as well as “application awareness”

3) Latest encryption capabilities remain within the SDN security services framework

4) Must be able to measure the ability of network workloads to ensure the confidentiality, integrity, and availability (the Security Triad) of the services they are delivering

5) Must be able to provide automated security alerts

6) Must be able to provide predictive capabilities

7) Messaging bus implementation

8) Policies should be bound to workloads: whether virtual machines, containers, applications, services or microservices

9) Write security policy in one place and deploy in multiple places, where workload policy would then be enforced

Use Case VotingThe above nine S-DSS use cases were voted upon by IT executives participating in the S-DSS working group to prioritize their development and focus the working group’s activities. The following graphic illustrates the aggregated voting results.

As a result of this vote, the three use cases specified below were selected to become the focus of the working group’s activities. These three use cases have further been prioritized based upon the common needs expressed by S-DSS IT executive working group members:

8) Policies should be bound to workloads: whether virtual machines, containers, applications, services or microservices

9) Write security policy in one place and deploy in multiple places, where workload policy would then be enforced

4) Must be able to measure the ability of network workloads to ensure the confidentiality, integrity, and availability (the Security Triad) of the services they are delivering

Top Three Use Cases & RequirementsThe following section provides descriptions and requirements for the above three use cases. To minimize confusion, throughout the remainder of this White Paper these use cases have now been changed from “8, 9, and 4” to “1, 2, and 3.”

Use Case #1 (Formerly Use Case #8)

Policies should be bound to workloads, such as virtual machines, containers, applications, services or microservices

Problem Statement

In today’s data centers, virtualized servers have provided significant benefits driven by innovation in the more effective design and use of hardware technology, and by the increasingly dynamic nature of implementing and modifying resources (quick start/stop of VMs, memory allocation, processing power, storage allocation, the snapshot of VMs for backups, live VM migration capabilities, and more). Following this example, albeit beginning several years later, a similar transformation has been taking place with regard to network services and associated resources (routers, load balancers, firewalls, etc.) as they have also become more virtualized and software-defined.

Network security policies have been traditionally bound to traditional network topologies and attributes. While, in the past, these have been aligned with physical network infrastructures, improvements have been realized of late with the virtualization of network security appliances, which has in turn improved security policy enforcement functionality and efficacy. SDN capabilities have also brought the ability to better orchestrate network policies, yet these are still very much tied to the traditional constructs that have long been responsible for enforcing those policies. These constructs have, in turn, varied depending on specific network infrastruc-ture deployment architectures, which are typically driven by application needs.

While application architectures have evolved to drive different infrastructure deployment architectures, much of the security policy architecture framework is still constrained by how the network and infrastructure systems are put together (physical or virtual). As application workloads have become more fluid and less dependent on the network and infrastructure, the current approach to defining and enforcing security policies has lagged behind. This drives inconsistency in the technical implementations of those policies, hence increasing operational constraints and opening a window of opportunity to improve how security policies are defined, managed, and enforced from a software-defined security perspective.

One key paradigm shift to improve the status quo is to pursue an approach by which network security policies are less dependent on the network itself – and bound instead to specific workloads.

That said, it is, of course, important to recognize that not all policies and workloads are “created equal,” and so while policies may include such activities as monitoring/DPI/IDS, etc., it may indeed not be feasible to instantiate every one of those capabilities directly with every workload (e.g., as a result of licensing costs or performance issues); it is thus further recognized that this use case should allow for service chaining to bind a workload and its policies across an arbitrary topology, which might include forward-ing packets between physical nodes to receive the service. At the same time, it is important to keep in mind that one of the key, necessary characteristics of a properly formed requirement is that it be achievable given current technology limits.

Requirements

[The requirements for Use Case #1 (previously #8) have been combined with those of Use Case #2 (previously #9) and are listed under the Use Case immediately below.]

Use Case #2 (Formerly Use Case #9)

Write security policy in one place and deploy in multiple places, where workload policy would then be enforced

Problem Statement

As the same time that the SDI market is developing, so too are the various instantiations of cloud solutions. The first trend leverages commoditized hardware across compute, storage, and networking environments, and de-couples features and services into software that may run on a range of platforms – be they controllers, x86 compute platforms, and/or within or on top of

commoditized hardware. The second trend offers a workload placement or IT service delivery option to host applications in private, public, or hybrid cloud facilities. These two trends are creating new workload deployment options and newfound corporate agility.

However, from a security perspective, the ability to define and write security policy for a workload that spans an application and its data, say, in one place and then deploys it in multiple places where the workload policy would then be enforced, represents a major feature functionality gap in the marketplace.

There are many new orchestration tools available for SDI, such as VMware’s vCloud, Kubernetes, Mesos, Scalar, Cirba, Ansible, OpenStack, Docker’s Docker Machine and others. However, while some orchestration tools may include security features such as micro-segmentation orchestration, there is no broad policy engine framework that pushes policy or policies, once centrally defined, through orchestrators to elements for distributed enforcement. In addition, policy engines are typically vendor-specific, with most engineered for a hardware-defined infrastructure deployment model.

This use case therefore calls for a policy engine that communicates with a wide range of orchestrators through open and indus-try-standard interfaces so that centrally defined policies have their enforcement distributed to workloads independent of physical locale and dependency map.

The workload’s dependency map is more often than not a collection of services, which is instantiated within physical and virtual form factors such as firewalls, load balancers, intrusion protection systems, etc.

In short, this use case addresses how best to deploy security effectively in a way that transcends physical and virtual infrastructure in private, public, or hybrid cloud deployment models. Stated another way, this use case is focused upon “choreographing” a set of workload policies that are defined centrally, with enforcement distributed local to that workload, and which moves with the workload as it moves independently from the form factor of its dependency map.

Protections (e.g., isolation, redundancy, fault recovery, fail-secure). At the most basic level, protecting a workload means protecting the process instructions (code) and data that the workload is operating on by ensuring that the confidentiality, integrity, and availability (the aforementioned CIA – the Security Triad) of these objects is preserved. Within information security communities, these protections are referred to as security controls, or controls.

The ability to protect the workload from threats (both operating hazards and malicious actions) within an operational environment speaks to the resiliency of the system.

Resiliency is a desirable systemic quality that describes a system’s ability to withstand adverse conditions or failure modes induced by stress, wearout, latent defects, misuse, or intentional attack. The resiliency of a system contributes to the notion of trust. Trust is the confidence that the system can and will ensure that the workload process(es) it’s managing execute as intended without compromise of the CIA elements of security.

To establish trust, it is necessary to measure the effectiveness of each protection contributing to the resiliency of a system (or a system-of-systems such as a network). It is also necessary to prove that each protection has been properly implemented (e.g., through a formal or mathematical proof) and is operating as intended within the system (operational performance). Such evidence allows stakeholders to gauge the trustworthiness of a system in supporting the business. In order to attest to a system’s resiliency, a testing or benchmarking capability is required to measure, score and substantiate the applied protections used to satisfy the workload’s stated protection needs (security profile). The requirements for this capability have been articulated below.

Requirements:

R-140: The set of measures selected as the basis for assessing system protection effectiveness and operational performance must be rooted and derived from a source deemed to be both trusted and acceptable by the named authority having oversight of the operational domain (e.g., the business risk owner of the network).

R-150: A system operating on the network must be able to guarantee the operational performance of each protection it claims to provide for maintaining the confidentiality, integrity, and availability of a workload object (process or data). If the operational performance of a claimed protection cannot be guaranteed, then the system must be able to report/alert such a condition upon detection to a designated set of receivers (e.g., monitoring system(s)). The confidentiality and integrity of the report/alert must be guaranteed. The measure of each protection’s effectiveness and operational performance must be in accordance with the set of measures described in R-140 above.

R-160: An authorized subject (e.g., administrator, external system) must be able to issue a protection profile request query to a system operating on the network. The system must respond to the query by reporting each protection it claims to provide for maintaining the confidentiality, integrity, and availability of a workload object (process or data). The response content must enumerate each claimed protection and provide sufficient measurement detail to describe each protection’s features, capabilities, implementation methods, and certifications (if any). The confidentiality and integrity of the response delivered to the authorized subject must be guaranteed.

R-170: An authorized subject (e.g., administrator, external system) must be able to issue a protection state request query to a system operating on the network. The system must respond by reporting the current operational performance state (e.g., nomi-nal/available, degraded/ failing, disabled/unavailable, unknown/indeterminate) of each protection it claims to provide for main-taining the confidentiality, integrity, and availability of a workload object (process or data). For a claimed protection reported as functional (i.e., operating in a nominal state), the report must provide proof of protection effectiveness in accordance with the set of measures described in R-140 above. The confidentiality and integrity of the response delivered to the authorized subject must be guaranteed.

R-180: An administratively independent assessor system under the control of an authorized subject (e.g., security assessor) must have the ability to confirm the presence, effectiveness and operational performance of each protection claimed by the target system (the system on the network under assessment) for maintaining the confidentiality, integrity, and availability of a workload object (process or data). The measure of each protection’s effectiveness and operational performance must be in accordance with the set of measures described in R-140 above. The confidentiality and integrity of the assessment results provided to the authorized subject must be guaranteed.

Requirements Shared By Use Cases #1 & #2 (Formerly #8 & #9)

R-10: Network reachability for workloads must be provided to ensure that network segmentation security policies are enforced at the policy enforcement mechanism that’s nearest to the workload.

R-20: Service chaining must be supported to ensure that, as per policy (for a workload), traffic may be steered to specialized security services (deep packet inspection based policies, etc.).

R-30: Policy enforcement mechanism should be common across all different deployment infrastructure models (physical or virtual).

R-40: Policy enforcement mechanism should be integrated with the infrastructure in which the workload resides.

R-50: Policy enforcement mechanism should be at the nearest location to the workload, with the ability to understand and represent the context in which a workload resides (i.e., virtual machine tied to a hypervisor, container tied to an OS).

R-60: Policy enforcement mechanism should be one from which security policies can be portable.

R-70: Policy enforcement mechanism must be programmable, and it must leverage an open interface for management and control.

R-80: Policy enforcement mechanism must scale to enable filtering (ACLs) stateful policies as well as path isolation (whether or not via overlay) for workload-bound traffic, as per policy defined in a single, authorized control plane. R-90: Policy enforcement mechanism must be locked down so that remote access to it can only come from a single, authorized control plane.

R-100: Policy enforcement mechanism must be protected against local privilege escalation so that it can only be changed from a single and remote control plane (i.e., local admin of a system cannot change local policy configuration, even if ‘root’ to local system).

R-110: Policy enforcement mechanism must be implemented so that its local configuration and policies constructs are protected from tampering and compromise (confidentiality and integrity at the local enforcement).

R-120: Policy enforcement mechanism must enable backend integration with policy management/orchestration engine via open and secure APIs (authentication, coarse and fine grain authorization, data-in-transit protection).

R-130: Key management that enables secure communication between policy enforcement mechanism and security policy control plane should follow key management guidelines, such as those offered by SANS Top 20 Critical Controls, NIST in the U.S. etc., and various European country-specific specifications embedded in ISO 27002:2013, officially entitled “Information technology — Security techniques — Information security management systems — Requirements.”

Use Case #3 (Formerly Use Case #4)

Must be able to measure the ability of network workloads to ensure the confidentiality, integrity, and availability (the Security Triad) of the services they are delivering

Problem Statement

A network workload represents a set of related and coordinated (managed) data transformation and/or transfer processes addressable somewhere on a network. The workload may consist of any class of monolithic or distributed processing, includ-ing network node functions (e.g., switching, routing, load balancing, accelerators, security). Collectively, these processes deliver some form of service to a consumer through the network. As these processes transform and move data about the network, they consume resources: compute cycles (data transformations), storage (persistent and non-persistent data at rest), and communications bandwidth (data in transit).

During operation, workload processes are hosted or contained within one or more physical or virtual systems (network-enabled objects). The processes may share these systems and their resources with other unrelated and/or untrusted processes (e.g., applications, OS, VMM). These systems manage process execution and consumption of resources, as well as provide needed

WG’s Top 10 RequirementsThe S-DSS working group members voted on which of the above requirements constituted the “Top 10” from the above three use cases. The following are the top 10 S-DSS requirements:

Requirement Description

1 Policy enforcement mechanism must be common across physical or virtual infrastructure.

2 Service chaining must be supported.

3 Policy enforcement mechanism should be at the nearest location to the workload.

4 Policy enforcement mechanism should be integrated with the infrastructure the workload resides.

5 An authorized subject (e.g., administrator, external system) must be able to issue protection profile and protection state request queries to a system operating on the network.

6 Policy enforcement mechanism must be programmable via open interface for management/control.

7 Policy enforcement mechanism must scale to enable filtering (ACLs) stateful policies and path isolation (overlay/underlay) for workload-bound traffic.

8 Policy enforcement mechanism must enable backend integration with policy management/orchestration engine via open and secure APIs.

9 A system operating on the network must be able to guarantee the operational performance of each protection it claims to provide.

10 Policy enforcement mechanism should be one from which security policies can be portable.

Conceptual Framework DiagramsFigure 1: High-Level Conceptual Overview

As presented in the original Spring 2016 S-DSS White Paper, the following diagram provides a conceptual framework for the three major use cases and associated requirements articulated above, regarding: 1) security policies bound to workloads; 2) policy por-tability between and across environments; and 3) maintenance of CIA characteristics:

Spring 2017 S-DSS White Paper Additions

Policy Enforcement Everywhere

In order to fulfill the requirements set down in the Spring 2016 S-DSS White Paper, which we will refer to here in total as a condition of “policy enforcement everywhere” within the network context, a software object (instructions + data) instantiated as a workload at run-time will have to be able to enforce the technical controls described by its own security policy without the assistance of an external entity. In other words, a workload must be able to determine autonomously during run-time whether or not its policy rules have been satisfied, and then take whatever actions are appropriate based on that determination. This idea is applicable to every system or device shown in Figure 1 and extended to Figure 3 in the section following: i.e., the security controller, SDN controller, virtual switch, and the rest. Each of these elements represent a host system where software objects for one or more workloads are being executed – whether the workloads are running in an embedded device such as a physical switch or router, or running in a virtualized context such as within a virtual machine or container. These systems are all hosting a type of software object or combination thereof (application, system software, firmware, microcode) instantiated as workload. If a network (a system-of- systems) is to be secure as a whole, then all of its constituent system elements likewise need to be secure. The security policy applied to each element establishes what it means for that element to be secure within its operational context.

Applying these ideas in the general case suggests that an otherwise unprotected software object must become aware of the security policy rules applied to it, and must also be able to execute instructions (code) needed to enforce the policy at run-time. This can be accomplished by either implanting the policy rules and enforcement instructions directly into an object’s execution image (e.g., data + machine code, data + bytecode), or by encapsulating the object and its interfaces within a containing object

or environment that has awareness of the policy and the ability to enforce rules on behalf of the workload.

In both cases (implanted or encapsulated), the unprotected object joined with policy rules and enforcement instructions must be tamper proof; such that any evidence or detection of tampering, prior to or during run-time, would result in immediate invocation of countermeasures. Likewise, in the absence of protective hardware features (e.g., instruction set extensions such as Intel SGX or AMD SME/SEV), anti-forensic mechanisms must be applied to help mitigate run-time exposure or tampering with the workload’s memory-resident objects by means of a debugger or other tool/environment having run-time introspection capabilities.

Figure 2: Security Policy Enforcement Approaches

The figure above illustrates three possible approaches that could be taken toward the challenge of applying security policy rules and enforcement code to an unprotected software object.

The approach shown to the left in the figure depicts implanted policy rules and enforcement code, where the unprotected object is joined or integrated directly with these policy elements as part of its machine or bytecode image. Modern software construction techniques can facilitate the insertion of these elements at system provisioning time, allowing both rules and enforcement code to be implanted into an object’s image (or a template) and then instantiated as a workload at run-time.

The approach shown in the center of the figure depicts an unprotected object encapsulated by a containing object that carries with it the policy rules and enforcement code. In this approach, the containing object encloses the entire unprotected object without modifying the object directly. The containing object exercises full control over all of the unprotected object’s interfaces, allowing it to enforce policy rules for the workload at run-time. As long as the interfaces are fully encapsulated and managed, the policy rules can be enforced.

The last approach shown to the right in the figure illustrates an unprotected object encapsulated within a policy-aware environment that is capable of enforcing rules on behalf of the unprotected object after it has been instantiated as a workload. The encapsulation environment has full control over the workload’s processing resources and interfaces, and is therefore able to enforce policy with or without cooperation of the workload. This approach facilitates policy enforcement exclusively through platform and network management operations, where the policy rules may be maintained and deployed centrally within the environment (e.g., through a security controller).

In each of these cases, policy rules may be crafted prior to run-time that would allow dynamic changes to a workload’s policy to be issued by a controller or other trusted entity at run-time. This would happen over a secure channel without violating the integrity context of the workload. For example, baseline rules would define explicitly what entities are considered trusted and would provide keys or other tokens needed to authenticate and authorize communications with the trusted entity.

It is important to recognize that the confidentiality of the policy enforcement rules must be protected because the rules will contain information describing how the workload is protected. An adversary with visibility into these rules may use that information to craft emulation or replay attacks against the workload or the environment hosting it. Moreover, the policy rules may also contain secrets needed to establish secure communications with trusted entities with which the workload is cooperating. The compromise of these secrets would result in compromise of the workload and whatever other trusted entities it is communicating with (e.g., an entire service chain). The use of encryption to secure the enforcement rules would be the obvious countermeasure to this class of threat.

A realization of the ideas above would result in what might be characterized as a protected object; one capable of enforcing its own policy at run-time. This has the property of binding a policy to the object (and therefore to the workload), such that the baseline policy enforcement is self-contained and immutable within the protected object. This property also brings policy inheritance for forked or detached workloads descended from the parent and facilitates location independence as to where the object can be instantiated as a workload. Note that location independence in this context does not mean that the protected object can be run anywhere, but rather that it runs only where its policy allows it to run. Location independence is one characteristic needed for policy portability. Another is interoperability derived from open interfaces for describing policy (syntax and semantics) that would promote vendor-neutral implementations.

It should be noted that there are a number of assumptions being made here that involve trust, not the least of which involves the trustworthiness of the pre-execution and run-time environments for the workload, as well as the supply-chain. Unless these all can be trusted, there are few, if any, controls that can be put into place at the object level that would effectively guarantee the confidentiality and integrity of the workload. Inspection, auditing, hardening, and other safeguards can help mitigate risk, but in the end, the business owner will have to accept whatever residual risk may still exist.

That said, trust is a relative concept, and not every workload requires the same degree of trust across all deployment situations. Security policies help to describe what can or cannot be trusted relative to the level of risk tolerance that an organization’s stakeholders deem to be acceptable. For some communities, no part of their IT infrastructure or workloads will ever see the inside of a public cloud service provider; the risk is just too great. For others, the operational and financial benefits of a public cloud deployment is the only way to go. Whatever the case, when it comes to risk, everything is relative and being able to specify and enforce a security policy through rules at a fine-grain resolution – down to the workload – gives businesses and service providers more options and more opportunity.

From “Problem Space” To “Solution Space”

Over the winter of 2016/2017, as a number of solution providers (vendors) became increasingly engaged with IT executives from the S-DSS Working Group in addressing the detailed implications of the “problem space” evidenced by the section immediately above, the working group’s discussions similarly led to a more detailed consideration of the “solutions space” – specifically around the definition of security controller features and functionalities. As indicated by Figure 3 below, the security controller interface is conceived of as being composed of two interfaces: one “user” and one “security function.” The Security Controller’s User Interface exposes a RESTful Interface (e.g. GUI portal) while maintaining agnosticism of security function placement within the network. This is a declarative or descriptive model rather than an imperative or prescriptive one. It seeks to answer the question “how would a user like to express a security policy?” rather than prescribe how such a policy should be implemented. Likewise, the Security Function Interface of the Controller provides a RESTful interface. This security function is vendor-, implementation- (virtual/physical), and hosting-agnostic. It is also control- and data-plane agnostic. It thus represents one potential reference architecture aligned with the encapsulation model described above. The development reference architectures for implanted and object encapsulated are likely to be follow-on efforts in the near-term.

Figure 3: Security Controller Architectual References

ConclusionAs noted above, the task set forth by the ONUG community for the Software-Defined Security Services Working Group was to provide a set of functional requirements to guide industry vendors in their development of open architecture framework, security-related products and solutions. As the working group proceeded to explore the plethora of considerations needed to provide meaningful direction in this area, it became clear that the creation of a robust software-defined infrastructure would also require the development of a new security framework – not a framework that discards “traditional” security concerns or conceptualizations (such as the Security Triad, to pick one key example), but rather one that builds upon, extends, and fundamentally enhances those core frameworks.

As the history of earlier forays into open, virtualized architectural frameworks (such as server virtualization) demonstrates, there are many ways of potentially addressing the various problems and issues presented by such a complex challenge as the working group has now before it, and one can quickly end up deep in the quagmire of trying to sort out fundamental needs, priorities, and possibilities. Hence the working group’s conviction stated early on in this document, that it was critical to separate “problem space” from “solution space,” and to recognize explicitly that its proper purview and focus needed to be on exploring and defining the problem space via the development of specific use cases and attendant requirements. Hence too the working group’s explicit goal, shared by ONUG in general, that the solution space was properly within the purview of solutions vendors. The working group’s job here is accordingly to enable the follow-on development work needed from that community through the clear and sensible articulation of requirements. As Figure 3 indicates in the section immediately preceding this conclusion, we have now actively begun to progress into that solutions space with the articulation of our first solutions reference architecture.

As evidenced above, the working group proceeded with this task by first declaring a set of broadly-accepted industry standards and acknowledging the work of standards-setting bodies. This allowed it to establish “core requirements,” along with a common language and taxonomy upon which the working group could build an initial, open architecture-specific group of use cases and an SDI-specific set of security requirements.

From both the original superset of nine use cases to the three cases agreed upon as the areas for immediate focus, it is clear that the working group came to see the fundamental unit of concern as the integrity of the network or infrastructure “workload” itself.Understanding this led to the recognition that it is clearly incumbent upon the SDI security framework to ensure that security policies are fully bound to the workload itself, independent of their particular technology vehicle (VM, containers, et al.) and supplying vendor, that those workloads will be protected both in transit and at rest (across and between environments), that policies should be both centrally-created and distributed throughout and across the network, that policy enforcement efficacy is also maintained in a “close to the workload but distributed” manner, and that the confidentiality, integrity, and availability of all workload services can be measured and verified. Workload security compliance can thus be ascertained at any juncture. Furthermore, solution vendors are expected to understand prerequisites that are indeed necessary to enable the top 10 requirements, which includes knowing the risk appetite of their client base as that may fundamentally influence what’s acceptable for them as roots–of–trust for the solution.

The three use cases thus selected led to a set of requirements that focus on ensuring the ability to instantiate and enforce security policy. This is quickly ascertained by perusing the requirements presented above and numbered R-10 through R-180. At the most basic level, security policy enforcement must be possible across multiple workload deployment scenarios, whether physical or virtual, and whether carried out in on-premise data centers or in cloud- or hybrid/public-cloud-hosted environments. Beyond that, policy enforcement mechanisms should not only be able to understand and address the specific context in which a workload resides, but they must be programmable and leverage an open interface for management and control. Further, workload confidentiality, integrity, and availability must be discoverable, reportable, verifiable – in short, the Security Triad of a workload must be guaranteed within the boundaries of the requirements laid out by the S-DSS working group.

Definition of Terms

Term Definition

ACL Access Control List In computer networking, a set of rules that define how Layer-2 and/or Layer-3 traffic passes through a network device. In computer systems, a set of data elements that describes access rights (permissions and privileges) to system objects by an authorized subject.

Attack In information systems, an assault on system security that derives from an intelligent threat, i.e., an intelli-gent act that is a deliberate attempt (especially in the sense of a method or technique) to evade security services and violate the security policy of a system. (https://tools.ietf.org/html/rfc2828)

Availability The percentage of a specified period of time for which a system or service (or component thereof) is satisfactorily performing its intended function. The ratio (typically expressed as a percentage) of measured up-time vs. measured down-time for a system or system element.

Baseline A measurement, calculation or location used as a basis for comparison; a measurable characterization that is used as a basis to establish current state.

Capacity In information systems, the characteristic describing the amount or number in units of objects or work that can be maintained or managed by the system or system element.

CIA Confidentiality, Integrity and Availability – the Security Triad.

Clipping Level See threshold.

Container In software systems, the virtualization of an operating system kernel to support the concurrent execution of multiple, managed, and isolated user-space instances of an operating environment with low resource overhead imposed on the host operating environment.

Countermeasures In systems security engineering, the actions, devices, procedures, techniques, or other measures aimed at a specified threat to reduce the vulnerability of an asset to a specific hazard or attack.

DPI Deep Packet Inspection

Encryption In cryptography, the process of encoding data to protect its confidentiality such that only authorized sub-jects may have access to, or visibility of, the unencoded data.

Hypervisor A class of virtual machine monitor (VMM) used to virtualize a host machine (Type-1, or bare-metal) and/or its operating environment (Type-2, or hosted) so as to allow the host to simultaneously run multiple, distinct operating environments, or guests, as if each environment was running on its own dedicated ma-chine.

Information Security Within information systems, the concerns related to the protection, preservation, and assurance of con-fidentiality, integrity, and availability of an object or object resource (e.g., data) within a stated context, and extended to concerns related to higher-level concepts such as identity, authentication, authorization, auditing, and non-repudiation.

Interface In systems design, a point of interaction between two system elements that facilitates the exchange of data, energy or other transfer through a medium using a defined protocol.

Introspection In software systems, the ability of a software process to examine the memory content of a workload object at run-time.

Isolation In systems design, the practice of maintaining separation between discrete objects, functions or components in order to preserve the confidentiality, integrity, and/or availability of each.

ITIL Information Technology Infrastructure Library. Defines a set of best practices for IT service management organized around a service lifecycle which includes five key stages: Service Strategy, Service Design, Service Transition, Service Operation, and Continual Service Improvement. ITIL is a component of the UK government’s portfolio of best management practices maintained by HM Government, Office of Govern-ment Commerce (OGC).

Term Definition

Latency The time delay experienced in performing a specified unit of work.

Microservice In software architecture, the restructuring or decomposition of a software application into a set of fine-grained functions or service elements that are then organized into higher-order, loosely-coupled services through lightweight communication protocols.

Network Service Chaining

In network engineering, the creation of logical relationships between connected network service functions in order to automate the provisioning of more sophisticated network applications or services with different features and capabilities that can be made available for use over a single connection or with different traffic flows.

NFV Network Functions Virtualization

NIST National Institute of Standards and Technology - a directorate of the US Department of Commerce charged with promoting innovation and industrial competitiveness, and is the parent of the Information Technology Laboratory and Computer Security Division that conducts research and provides guidance on technical topics dealing with information security and information assurance.

Notification In communications, an announcement sent to a receiving entity regarding the occurrence of an event or an action having taken place.

Object In systems security engineering - An abstract representation of a tangible or intangible thing – a system, system element, system-of-systems, code, data or other resource – having a defined interaction or access relationship with a subject.

Operational Performance

In systems engineering, the ability of a system or system element to satisfy its intended function under stated conditions within the capacity and response time parameters of its design.

Orchestration In distributed computing systems, the automated deployment or dynamic placement/re-positioning of provisioned computing resources.

Overlay Network In network engineering, a logical network layer abstraction used to run separate, discrete virtual net-works on top of a physical transport network or another logical network; often involving protocol encapsulation and tunneling.

Performance A measure of capacity or work with respect to unit time (e.g., Gb/s, events-per-second).

Platform The hardware, operating environment, and application supporting software components of a system.

Policy Enforcement Point

In network security, a location on a network where subject access requests for an object are intercepted for adjudication by a policy decision agent based on the authorization policies governing the object.

Problem Space In systems engineering, the representation of what need or condition that is to be satisfied, or engineering problem to be solved; the definition and understanding of the set of requirements describing the desired end-state to be realized, considered along with relevant constraints and assumptions, expressed from the perspective of stakeholders seeking a solution.

Reliability The probability that a system or service (or a component thereof) will continue to satisfactorily perform its intended function at a specified point in time under specified conditions.

Resiliency The characteristics enabling a system or system element to resist adverse conditions and/or actions (at-tacks) that would compromise or defeat its operation.

Response Time The characteristic describing the time required by a system or system element to perform some defined/measured unit of work.

Safeguard A proactive control or mitigation mechanism designed as a protection or defense measure for an asset against specified hazards or attacks.

Scalability A measure of the ability to comply with stated service policies relative to changes in workload demand for a system or service (or component thereof).

SDI Software-Defined Infrastructure

SDN Software-Defined Networking

Term Definition

SDN Controller A software application for intelligent networks having a view of the entire network and acting as an integration and control point between network applications and the data forwarding plane of the network in order to manage network flow policy decisions regarding routing, forwarding, redirecting, load balanc-ing, security, and other functions.

Security Controls In information systems security, the set of physical, technical, and administrative safeguards and countermeasures intended to protect the confidentiality, integrity, availability, authentication, authorization, accounting, and/or non-repudiation properties of a system or system element against a hazard or attack.

Security Policy In information system security, a set of laws, rules, standards, and/or practices that regulate how an organi-zation manages and protects information and information systems; the overarching, multi-level framework under which the protection of confidentiality, integrity, and availability related to information and informa-tion systems is established.

Security Profile In information systems security, the framework based on policies for the protection of confidentiality, integrity, and availability by which security concepts, such as identity, authentication, authorization, audit-ing, non-repudiation and higher-level constructs, are expressed relative to system impact level and risk.

Security Threat In information systems security, any circumstance or event with the potential to adversely impact an infor-mation system through unauthorized action.

SEV Secure Encrypted Virtualization – A set of AMD64 instruction extensions on AMD microprocessors that allows the memory contents of a virtual machine (VM) to be transparently encrypted with a key unique to the guest VM in order to protect the confidentiality and integrity of the guest VM at run-time. First avail-able on processors using the AMD Zen microarchitecture.

SGX Software Guard Extensions – A set of x86_64 instruction extensions on Intel microprocessors allow-ing software applications to create and run within secure enclaves inside the processor, along with encrypted memory to protect the confidentiality and integrity of the application at run-time. First available on processors using the Intel Skylake microarchitecture.

SME Secure Memory Encryption – A set of AMD64 instruction extensions on AMD microprocessors facilitating transparent memory page encryption to protect the confidentiality and integrity of memory content as a countermeasure against process and memory introspection/reflection and cold-boot attacks. First avail-able on processors using the AMD Zen microarchitecture.

Service In information systems, a means of delivering value to consumers (customers) through information sys-tems integrating people, process, and technology that facilitates desired business outcomes without the specific costs and risks associated with ownership of the systems.

Service Element In information systems, a component or constituent part (people, process, technology) supporting a larger service that provides a specific subset of features or capabilities needed by the larger service in order to deliver value to its consumers.

Solution Space In systems engineering, the representation of how a need or condition is to be satisfied, or an engineering problem solved; the interpretation and analysis of stakeholder requirements, considered together with relevant constraints and assumptions, in order to synthesize a realizable solution that satisfies the desired end-state.

Stakeholder In information systems, any entity (individual or organization) with a legitimate interest in the desired future state outcome of a project, system, or service.

Subject In systems security engineering, an abstract representation of an actor – a human, machine or other enti-ty operating with intent – having a defined interaction or access relationship with an object.

System In systems engineering, an integrated set of elements, subsystems, assemblies, and/or components that accomplish a defined objective.

Term Definition

System Element In systems engineering, a member or constituent system or component of a larger set of systems or components that constitutes a system. A system element is typically thought of as a component, however it can be a system in its own right; one that is also part of a larger system (i.e., a system-of-systems). A system element can include: people, processes, technology (hardware, software, firmware, microcode), data, facilities, or other objects that may be needed for a system to accomplish its objective.

System Observabil-ity

In systems design, the capability to collect measurements which accurately represent the run-time behavior and/or state of a system.

Systemic Qualities The set of non-functional requirements that describe desired characteristics or properties of the system or system element within a defined operational context. These are also known as the “-ilities” and include characteristics that describe such things as: capacity, response time, availability, reliability, maintainability, resiliency, recoverability, and similar characteristics.

Threat In information systems security, the prospect that a natural hazard or conscious action on the part of an adversary will cause harm to an information system or the objects and resources it manages through the exploitation of a vulnerability.

Threat Actor In information systems security, a person or other entity, typically having malicious intent, that invokes harm, or has the potential to invoke harm, on an information system.

Threshold In systems design, a value (typically numerical) representing a change in state or operational context of a system or system resource.

Throughput The amount of work accomplished per unit measure of time.

Trust Boundary In information systems security, the physical or logical demarcation denoting where all elements operating within the boundary share the same level of trust, while elements operating outside of the boundary are considered to be untrusted.

Trustworthiness The confidence given to someone or something deemed as reliable or dependable in performing the intended or expected behaviors, interactions and outcomes for a specified function or role under stated conditions.

VLAN Virtual Local Area Network - a partitioned Ethernet broadcast domain isolating a collection of network devices at the data link layer (Layer 2) in a network switch.

VM Virtual Machine

VMM Virtual Machine Monitor – see hypervisor

VNF Virtualized Network Function

VPN Virtual Private Network

Vulnerability In computer security management, a weakness or defect in a system which is susceptible to a natural hazard or exploit by an attacker.

Vulnerability Reme-diation

In computer security management, the process of eliminating security weaknesses or defects in a system which could be exploited by an attacker.

Workload In computing systems, a set of related and coordinated data transformation and/or data transfer pro-cesses implemented through assembled collections of computer instructions and data, organized into monolithic or distributed processing elements, cooperating through interfaces and protocols, and when executing, consuming machine resources: compute cycles (data transformations), storage (persistent and non-persistent data at rest) and communications bandwidth (data in transit).

ONUG Software-Defined Security Services Group Members

Rakesh Kumar, Juniper Networks - Co-Chair Fred Lima, eBay - Co-Chair Scott Bradner, Independent - Co-Chair Michael Thomas Clark, Exceptional Leaders International - Editor Thom Schoeffling, General Dynamics IT - Contributor Mukesh Gupta, Illumio - Contributor Linda Dunbar, Huawei - Contributor John Burns, Wells Fargo - Contributor Srinivas Nimmagadda, Juniper - Contributor Hari Krishnan, Nuage - Contributor Brighten Godfrey, Veriflow - Contributor David Anderson, vArmour - Contributor Marc Woolward, vArmour - Contributor Ted Turner, Intuit - Contributor

Tavarez Dudley, Advocate Insiders Alex Kurgan, AFEX Ben Mourad, Allegis Group Venkatarao Mokkapati, American Express Rashad Mahmood Khan, APECON Craig Martinson, Australia & New Zealand Banking Group (ANZ) John Mammen, Bank of America Ravi Malhotra, BNY Mellon Neal Secher, BNY Mellon Terry McGibbon, Barclays Leo Pang, Bloomberg Pei Qi, Bloomberg Chris Christou, Booz Allen Hamilton Michael Lundberg, Booz Allen Hamilton Raj Mathialagan, Booz Allen Hamilton Dave Larkin, Cigna Andy Iaman, Cigna Matthew LaLumiere, Cigna Christopher Lockery, Cigna Xiaobo Long, Citi Zoran Kostic, Columbia University Gary Ramah, Disney Josh Archambault, DTCC Manoj Koshti, Ellie Mae Tony Chong, ExxonMobil Peter Kispert, FedEx Barry Poole, FedEx Michael Wynston, First Data James Noble, Gaikai Snehal Patel, Gap Lisa Huang, GE George Konapozhil, GE Hassan Ahmad, Google Solomon Tekle, Intuit Gani Riasudeen, JPMorgan Chase Pete Kwon, Legacy Texas Bank PashanthKumar, LinkedIn Michael Martin, McKinsey & Company Arup Chakravarty, MetLife Bob Natale, MITRE Hailu Meng, Monsanto Graeme Hay, Morgan Stanley Gideon Tam, MSKCC Ashutosh Chandra Jha, NASDAQ Ashok Patel, Owens Corning Shena Tharnish, PNC

Steve Lafrentz, Principal Financial GroupBrian Peister, ProtivitiShradha Sharma, PwC Advisory ServicesAli Sydney, Raytheon BBN TechnologiesDavid Lucey, SalesForceAzharul Mannan, Standard Chartered BankBrian Anderson, TegnaMahesh Desai, Tesla MotorsPai-Nui Chen, University of Chinese Academy of Science Mehrdad Moradi, University of MichiganRahul Godha, University of Wisconsin-MadisonVijay Balasubramanian, ViacomYinfeng Shi, ViacomRandhir Chawda, VisaZakir Hussain Mohideen, VisaMarcelo Silva, VisaPhil Hattwick, Wellington ManagemenKelley Mak, Work-BenchZahid Kalwar, XL Global ServicesPhil Lynch, WestpacAmir Sharif, AporetoManish Kumar, CiscoManoj Kale, CiscoAaron Linn, CiscoTina Zhang, CiscoNagendra Kumar Nainar, Cisco Stacy Brown, Cisco Todd Kelly, Cradlepoint Hakim Abdelkader, HPE Ami Das, HPE Richard Shi, Huawei Ayush Sharma, Huawei George Zhao, Huawei Yang Yang, Huawei Wei Wei, Huawei Jim Guichard, Huawei Benny Huang, Huawei Moloy Chatterjee, Juniper Christopher Messina, Juniper Anil Lohiya, Juniper Chinma Bhawe, Juniper Prakash Seshadri, Juniper Dinesh Naganna, Juniper Tarun Banka, Juniper Sumeet Singh, Juniper Simon Fiddian, Nuage Nabil Bitar, Nuage Darren Richards, Nuage Hussein Khazaal, Nuage Toshal Dudhwala, Nuage Steven Shalita, Pluribus Apurva Mehta, Versa Anusha Vaidyanathan, Versa Mark Weiner, Versa Darrell Long, Versa