Define SDN APIs (Activity 5.2.1)

A key enabler for enforcing these dynamic policies and adapting to the ever-changing digital environment is network automation. This brings us to a foundational activity in making the network programmable: Zero Trust Activity 5.2.1: Define SDN APIs.

This activity is identifying which of the functionalities exposed by the SDN controller’s APIs are needed for Zero Trust automation and then standardizing how those APIs will be used across the enterprise by various security and orchestration tools to achieve dynamic network control based on identity, device, and security signals. It’s bridging the gap between the network’s technical capabilities and the higher-level Zero Trust automation requirements.

This activity recognizes that to achieve true Zero Trust at scale, the network itself must be dynamic and responsive, capable of automating security actions based on real-time signals. It mandates that the DoD Enterprise, working collaboratively with Components, define the necessary APIs and other programmatic interfaces that enable the functionalities of Software-Defined Networking (SDN).

The crucial aspect is that these defined APIs will enable automation of key Zero Trust-related network functions: authentication decision points, application delivery control proxies, and segmentation gateways.

This activity is not about implementing the automation workflows themselves yet, but about creating the standardized interfaces that allow for that automation. It’s about making the network consumable by other security and orchestration tools through well-defined APIs.

Solutions for Define SDN APIs (Activity 5.2.1)

Activity 5.2.1 is about making the network’s security-relevant functionalities consumable and controllable by your broader Zero Trust automation ecosystem through well-defined, machine-readable APIs. While the SDN vendor provides the core plumbing (the underlying APIs), the enterprise defines the specific interfaces and how they will be used to achieve enterprise-wide Zero Trust network automation goals.

  1. Defining Which Vendor APIs are Necessary and How They Will Be Used: SDN controllers offer a wide range of APIs to control various network functions. The enterprise needs to identify and select the specific APIs from the SDN vendor’s offering that are relevant and necessary for implementing the desired Zero Trust automation functionalities (automating authentication decisions, ADC control, segmentation). Then, they need to define the standardized patterns and workflows for how these selected APIs will be called and utilized by different security tools. It’s about creating a common understanding and approach to consuming the provided APIs for Zero Trust purposes.
  2. Defining Abstract or Enterprise-Specific APIs: In a large, distributed enterprise with potentially multiple underlying network technologies or SDN domains, creating automation workflows that directly interact with each vendor’s specific APIs can become complex and difficult to standardize. The enterprise might choose to define and build its own layer of enterprise-specific APIs that act as an abstraction layer on top of the underlying SDN vendor APIs. These custom APIs would provide a standardized interface for automation tools, hiding the complexity of the diverse network infrastructure below. For example, instead of a SOAR platform needing to know the specific API calls for Cisco ACI, VMware NSX, and a cloud provider’s SDN, it would call a single enterprise-defined “QuarantineDevice” API, and that enterprise API would translate the request into the appropriate vendor-specific calls.
  3. Defining APIs for Integrating SDN Capabilities with Zero Trust Decision Points: The APIs being defined are specifically those that enable the automation of authentication decision points, application delivery control proxies, and segmentation gateways. This means defining APIs that allow external Zero Trust components (like a Policy Decision Point or an IdP) to interact with the SDN to influence network behavior. For instance:
    1. APIs for Authentication Decision Point Automation: These could be APIs on the SDN or related network enforcement points that an external policy engine calls to verify a device’s trust status or request an authentication challenge based on network context.
    2. APIs for Application Delivery Control Proxy Automation: APIs on ADCs or proxies within the network that allow a central controller to dynamically adjust traffic routing or security policies based on application load or perceived threat.
    3. APIs for Segmentation Gateway Automation: APIs on network segmentation enforcement points that allow a security orchestration tool to automatically move a device to a quarantine segment or block specific traffic flows based on a security alert (e.g., from an EDR or SIEM).
  4. Map Use Cases to SDN Functionalities: For each identified Zero Trust automation use case, the enterprise determines what underlying network functionalities are required. For example, automating quarantine requires the ability to dynamically modify access control lists or move a device to a specific network segment. Dynamic application delivery requires modifying traffic steering rules.
  5. Identify Corresponding SDN Controller APIs: The enterprise then examines the APIs provided by their specific SDN controller(s) to see which APIs offer the necessary functionalities identified in step 4.
    1. To automate segmentation, they might need Flow Management APIs or Policy APIs that allow dynamic rule updates.
    2. To automate traffic steering for application delivery, they might need Flow Management APIs or APIs specific to application delivery features within the SDN.
    3. To respond to authentication decisions, they might need APIs that allow for rapid application of access controls based on identity signals received from an external source
  6. Define Standardized API Consumption Patterns (The “How to Use”): This is a crucial part of “defining the APIs” in a large enterprise context. While the vendor provides the API specifications, the enterprise needs to define standardized methods and workflows for how their internal security tools (like SOAR, policy engines) or custom automation scripts will consume these APIs. This involves:
    1. Defining the sequence of API calls for common tasks (e.g., the exact series of API calls to quarantine a device).
    2. Defining the data formats and parameters to be used when calling the APIs.
    3. Defining error handling and response processing.

Relevant Technologies and Tools:

Successfully implementing Activity 5.2.1 relies on technologies that enable network programmability and API development:

  • Software-Defined Networking (SDN) Controllers/Platforms: The core infrastructure that provides centralized control and often exposes APIs for network management and automation. 
  • Automation and Orchestration Platforms (consuming the APIs): Tools that utilize the defined network APIs to automate security policies, incident response actions, and network configurations.  These are tools like your SOAR platform.
  • Authentication Decision Points (PDPs) and Policy Enforcement Points (PEPs): While these are concepts, the technologies implementing them (like policy engines or gateways) will be the consumers of the SDN/network APIs to enact decisions.
  • Application Delivery Controllers (ADCs) / Proxies with API Capabilities: Network devices that manage traffic flow to applications and expose APIs for dynamic configuration.
  • Network Segmentation Gateways/Controllers with API Capabilities: Technologies that control network segmentation and expose APIs for dynamic adjustment.

Example Scenario

Below are examples of APIs an SDN controller might provide and then illustrate standardization:

Examples of APIs Provided by an SDN Controller:

SDN controllers typically expose RESTful APIs (using HTTP methods like GET, POST, PUT, DELETE) with data formats like JSON or XML. Here are some conceptual examples of API endpoints and their functionalities relevant to Zero Trust automation:

  • /network/devices:
    • GET: Retrieve a list of connected network devices (switches, routers) managed by the controller.
    • GET /{deviceId}: Retrieve detailed information about a specific network device.
  • /network/hosts:
    • GET: Retrieve a list of end hosts (devices, servers) connected to the network, as seen by the SDN.
    • GET /{hostId}: Retrieve information about a specific host, potentially including its IP address, MAC address, and connected port.
  • /network/flows:
    • GET: Retrieve the currently installed flow rules on network devices.
    • POST: Install a new flow rule. (e.g., define a rule to block traffic from a specific IP to a specific port).
    • PUT /{flowId}: Modify an existing flow rule.
    • DELETE /{flowId}: Delete a flow rule.
  • /network/segments:
    • GET: Retrieve information about defined network segments.
    • POST: Create a new network segment.
  • /network/policies: (Higher-level policy abstraction)
    • POST: Apply a security policy to a specific network segment or group of hosts (e.g., a policy allowing only encrypted traffic between two segments).

Standardizing How to Use These APIs (Activity 5.2.1):

Now, let’s consider a Zero Trust automation use case: Automatically quarantining a device detected with malware by an EDR.

Without standardization, different Component security teams or automation scripts might use the SDN controller’s APIs in different ways:

  • Team A might use the /network/flows API to insert specific block rules for the device’s IP address on all relevant switches.
  • Team B might use a different set of /network/policies APIs if the SDN controller has a higher-level segmentation policy feature, moving the device’s port to a quarantine segment.
  • Each team would need to understand the specific syntax, parameters, and authentication methods for the SDN controller’s APIs.

In Activity 5.2.1, the enterprise would “define the necessary APIs” by standardizing this process. This could involve:

  1. Identifying the Core Functionality Needed: The necessary functionality for this use case is “Quarantine Device.”
  2. Selecting the Relevant SDN APIs: The enterprise determines that a combination of /network/hosts (to find the device’s current location/IP) and /network/flows or /network/segments APIs are needed from the SDN controller to implement quarantine.
  3. Defining a Standardized Enterprise API (Abstraction Layer): The enterprise defines a single, standardized internal API, perhaps called /enterprise-network-control/quarantineDevice, with a simple, machine-readable input (e.g., {“deviceId”: “xyz123”, “reason”: “malware_detected”}).
  4. Implementing the Enterprise API: A development team builds this /enterprise-network-control/quarantineDevice API. This API internally calls the necessary sequence of vendor-specific SDN controller APIs (e.g., first calling /network/hosts to get the device’s network details, then calling /network/flows to install blocking rules or /network/segments to move the device). The enterprise API handles the vendor-specific complexities.
  5. Documenting the Standardized API: The enterprise provides clear documentation for its internal /enterprise-network-control/quarantineDevice API, including its purpose, parameters, expected responses, and security requirements.

Now, any security orchestration tool (like a SOAR platform) or automation script across the enterprise that needs to quarantine a device simply calls the standardized /enterprise-network-control/quarantineDevice API, without needing to know the specifics of the underlying SDN vendor’s APIs. The enterprise has effectively “defined the necessary APIs” by creating a standardized interface for a critical Zero Trust automation function, built upon the capabilities provided by the SDN infrastructure. This promotes consistency, simplifies automation development for Components, and allows the enterprise to potentially swap out underlying network infrastructure later without breaking automation workflows, as long as the new infrastructure can be integrated with the enterprise’s abstraction layer APIs.

For the Technical Buyer:

Activity 5.2.1 is a fundamental step in making your network an active and dynamic participant in your Zero Trust architecture. It’s not about building the core SDN functionalities from scratch, but about identifying, selecting, and standardizing the use of the APIs that your SDN controller or alternative programmable network infrastructure provides. This includes defining precisely how these APIs will be leveraged to automate critical Zero Trust network functions like influencing authentication decisions, dynamically controlling application delivery, and orchestrating segmentation responses. For technical buyers, success in this activity hinges on ensuring your network infrastructure offers robust, well-documented, and machine-readable APIs. You need to collaborate across teams to define the necessary API consumption patterns and potentially build an enterprise-specific abstraction layer on top of vendor APIs to ensure consistency and simplify integration for your security orchestration and automation tools. This activity is paramount for unlocking the network’s potential to enforce dynamic policies and respond programmatically to threats, creating a truly agile and secure Zero Trust environment.

Pillar: Network and Environment

Capability: 5.2 Software Defined Networking

Activity: 5.2.1 Define SDN APIs

Phase: Target Level

Predecessor(s): 5.1.1 Define Granular Control Access Rules & Policies Part 1

Successor(s): 5.2.2 Implement SDN Programable Infrastructure

Technology Partners