Orchestration Threats For SD-WAN

I recently wrote an article describing four main threats for SD-WAN that can be used as a checklist for cybersecurity professionals and enterprise stakeholders when reviewing and implementing SD-WAN.

In this article today, I am going to dive deeper into some important Orchestration Plane and Management Plane Threats for SD-WAN and some key points for consideration. This is important because administration tasks happen over the Internet.

With Software Defined Wide Area Networking (SD-WAN) quickly becoming an enterprise staple to help control costs, reduce application latency, and reduce network downtime, we need to pay closer attention to the related threats and mis-uses cases when performing threat modeling and risk assessments.

Get My Free Cloud Security Journal

Management interfaces for SD-WAN are designed to communicate with system admins over the Internet making them a prime target for attackers. This design choices makes one scratch their head when thinking about threat vectors and possible attacks. Several of the OWASP Top 10 web application security risks come into play and so organization’s need to take this very serious.

As shown in the diagram above, northbound interfaces are used to interface with the orchestration layer and southbound interfaces are used by controllers (Control plane) to communicate with routers.

You will need to verify with your unique implementation of SD-WAN, but Openflow, NETCONF, REST API and custom protocols are used over TLS to program network connectivity and GRE and VXLAN are frequently used to provide overlay tunnels.

This information is useful when considering your attack surface and developing mis-use cases in your threat modeling.

KEY ORCHESTRATION LAYER SD-WAN THREATS

• Eavesdropping
• Sensitive information exposure
• SD-WAN node spoofing (edge router, controller, orchestrator)
• Unauthorized access to operating system resource via vulnerable functions or methods
• Unauthorized access to methods or functions via exposed interface

You can use these threats when developing your mis-use cases and threat modeling exercises.

REAL-WORLD EXAMPLES

Security researchers have found hard-coded TLS certificates and the corresponding public-key cryptography key pair in well-known SD-WAN products.

In at least one specific case, they went on to discover that all controllers and orchestrators from a vendor used the same pre-installed self-signed RSA certificate.

It is hard to imagine that a vendor would be so sloppy and allow these vulnerabilities to go into production. It is this reality that requires us to perform our due diligence as cybersecurity professionals.

In scenarios where the remote host is running a service that is using a publicly known SSL / TLS private key, an attacker can use this key to decrypt intercepted traffic between users and the device. A remote attacker can also perform a man-in-the-middle attack in order to gain access to the system or modify data in transit which could lead to devastating consequences in an SD-WAN environment.

In the attack vector described above in an SD-WAN environment, the attacker could use the certificate and corresponding private key to perform eavesdropping and spoofing attacks against ALL SD-WAN nodes!

SD-WAN vendors also use the WebSocket protocol on northbound interfaces (orchestration plane) which is vulnerable to Cross-Site WebSocket Hijacking (CSWSH) attacks.

This attack vector could allow a remote threat actor to perform commands on edge routers!

The WebSocket protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections.

WebSocket uses HTTP as the initial transport mechanism, but keeps the TCP connection alive after the HTTP response is received so that it can be used for sending messages between client and server. This is an important concept to understand when considering attack scenarios.

Get My Free Cloud Security Journal

CSWSH attacks as described above use a well-known cross-site request forgery (CSRF) vulnerability in the WebSocket handshake. It arises when the WebSocket handshake request relies solely on HTTP cookies for session handling and does not contain any CSRF tokens or other unpredictable values.

An attacker can create a malicious web page a domain which establishes a cross-site WebSocket connection to the vulnerable application. The application will handle the connection in the context of the victim user’s session with the application.

The attacker’s page can then send arbitrary messages to the server via the connection and read the contents of messages that are received back from the server.

This means that, unlike regular CSRF, the attacker gains two-way interaction with the compromised application.

The WebSocket Protocol was designed to allow two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. This does not meet the description of the typical SD-WAN implementation.

If WebSocket is used in your SD-WAN, then you will want to make sure an encrypted WebSocket connection is used with Transport Layer Security (TLS).

I hope this article raises your awareness about Orchestration layer threats in SD-WAN environments and encourages you to dig deeper when performing risk assessments in your network.

Tim Layton specializes in demystifying the complexities and technical jargon associated with cloud computing security and risk management for business stakeholders across the enterprise. Tim is a cloud security thought leader defining actionable and defensible strategies to help enterprise stakeholders make risk-based decisions and prioritize investments in the new digital frontier.

Stay Connected With Tim Layton

LinkedIn: www.Linkedin.com/in/TimLaytonCyber

Website: http://CloudSecurityLaunchPad.com

Get My Free Cloud Security Journal

COMMON CYBERSECURITY RISK TERMS DEFINED

Threat: Any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the Nation through an information system via unauthorized access, destruction, disclosure, or modification of information, and/or denial of service. (NIST 800–30)

Threat: potential cause of an unwanted incident, which can result in harm to a system or organization. (ISO 27001)

Vulnerability: Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited by a threat source. (NIST 800–30)

Vulnerability: weakness of an asset or control that can be exploited by one or more threats. (ISO 27001)

Likelihood: A weighted factor based on a subjective analysis of the probability that a given threat is capable of exploiting a given vulnerability or a set of vulnerabilities. (NIST 800–30)

Likelihood: chance of something happening. (ISO 27001)

Risk: A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. (NIST 800–30)

Risk: effect of uncertainty on objectives. (ISO 27001)

Security Controls: The management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for an information system to protect the confidentiality, integrity, and availability of the system and its information. (NIST 800–30)

Compensating Security Control: A management, operational, and/or technical control (i.e., safeguard or countermeasure) employed by an organization in lieu of a recommended security control in the low, moderate, or high baselines that provides equivalent or comparable protection for an information system. (NIST 800–30)

Impact Level: The magnitude of harm that can be expected to result from the consequences of unauthorized disclosure of information, unauthorized modification of information, unauthorized destruction of information, or loss of information or information system availability. (NIST 800–30)

Residual Risk: Portion of risk remaining after security measures have been applied. (NIST 800–30)

Security Posture: The security status of an enterprise’s networks, information, and systems based on information assurance resources (e.g., people, hardware, software, policies) and capabilities in place to manage the defense of the enterprise and to react as the situation changes. (NIST 800–30)