On June 13th, the Cybersecurity and Infrastructure Security Agency (CISA) released another Binding Operational Directive (BOD), CISA BOD 23-02, that will shake the feathers within federal civilian executive branch (FCEB) agencies. This wouldn’t be a blog about a government agency without three acronyms in the first sentence. So, let’s dive into the details of this directive to understand the scope and what this means going forward for federal compliance.
What is CISA BOD 23-02?
CISA BOD 23-02 can be quickly described as, “the banning of networked management interfaces open to the internet.” If the first thing you asked when reading that was, “What is and isn’t a networked management interface?” CISA has got you covered:
- Devices residing on or supporting federal information systems and/or networks that belong to one of the following classes: routers, switches, firewalls, VPN concentrators, proxies, load balancers, and out of band server management interfaces (such as iLo and iDRAC).
- Devices for which the management interfaces are using network protocols for remote management over public internet, including, but not limited to: Hypertext Transfer Protocol (HTTP), Hypertext Transfer Protocol Secure (HTTPS), File Transfer Protocol (FTP), Simple Network Management Protocol (SNMP), Teletype Network (Telnet), Trivial File Transfer Protocol (TFTP), Remote Desktop Protocol (RDP), Remote Login (rlogin), Remote Shell (RSH), Secure Shell (SSH), Server Message Block (SMB), Virtual Network Computing (VNC), and X11 (X Window System).
This Directive does NOT apply to web applications and interfaces used for managing Cloud Service Provider (CSP) offerings including but not limited to, Application Programming Interfaces (APIs) or management portals.
Before we dive further into the scope, it may first be useful to break down the historical significance of this directive, as well as how this problem may have become so pervasive in the first place.
The Background Behind the BOD
CISA is effectively putting a 14-day hard-stop upon discovery on the interaction with networked management interfaces reaching across the vast internet. This means that the ‘networked management interfaces’ should no longer be accessible from within the general network, where it could theoretically be accessed by devices which have general internet access themselves.
There are likely many reasons why this directive is both very timely and very needed. There are many recent events that are all valid contributors to the problem, including the Barracuda Networks ESG vulnerability (CVE-2023-2868 ), a vulnerability so severe the recommendation is a replacement of the physical hardware. Other examples include the MOVEit Transfer vulnerability that rocked the global public and private sectors with data still being posted by cl0p as of time of writing, and the Fortinet 0-day dubbed XORtigate (CVE-2023-27997). These were all just within one month of each other.
While this directive was likely drafted for quite some time, it is hard to argue these events are irrelevant to the timely release of 23-02.
We would also be remise if we didn’t mention the clear societal factors at play. The COVID-19 pandemic rocked the world to a standstill, and large organizations and government entities with thousands of devices and people to manage suddenly had to figure out a different way of doing things. This was done in haste, for the safety of everyone involved. In hindsight, this had a hand in misconfigured network access on a grand scale. To put it simply, we enabled the ability for users to be able to complete the same jobs they did before but almost entirely virtually, while also enabling attackers to discover network perimeters that previously didn’t exist.
Management interfaces for software such as Firewall, VPN, Jump Servers, and other access management network devices can sometimes be not-so intuitive. They can sometimes have a GUI, CLI configuration, or both. Often these interfaces and what logical destination they derive from is not clear. This is where it is up to the administrator(s) managing the device to ensure a multitude of boxes are checked, all the while keeping their networks completely secure to do it. The pandemic shifting everyone to a more grand virtual environment surely contributed to the difficult process of checking those boxes.
There are also the existing factors that already contributed to the difficulty in checking these boxes and securing the things: poorly scoped compliance, 3rd party implementation making granular understanding vague, unique environmental characteristics, etc. Many factors added to the complications of avoiding this now-banned practice, and often it can a combination of many.
What CISA BOD 23-02 Aims to Solve
So, how is CISA helping ease the burden with this directive?
CISA will be handling the discovery of these assets themselves, according to the text of the directive, likely leveraging newly developed in-house tools such as Crossfeed. This and other tools will allow CISA to act as an identifier for potentially vulnerable network configurations and work with the owner of the system’s environment to correct it.
CISA recommends two major changes to any existing topology that may fall in the now-banned practices:
- Remove the interface from the internet by making it only accessible from an internal enterprise network (CISA recommends an isolated management network);
- Deploy capabilities, as part of a Zero Trust Architecture, that enforce access control to the interface through a policy enforcement point separate from the interface itself (preferred action).
The following diagrams illustrate most common scenarios in which CISA considers complying with BOD 23-02:
This means that the utilization of a jump box or other common SASE tooling if you fall privy to the cloud like many of us (or don’t and still use SASE – that’s cool too), appears to fall within the directive, which states that the networked management interface must either be not connected to the internet or managed in an isolated network.
If your environment already utilizes ZT PEP architecture, it is recommended to continue that practice when determining what does not fall within the guidelines of this directive. CISA also stated that, for FCEB organizations where the remediation of a finding of this kind will exceed the 14-day timeline, CISA will work with the organization in a reporting interface to determine remediation plans, “CISA will provide federal agencies a reporting interface and standard remediation plan templates if remediation efforts exceed required timeframes.”
Your network is as secure as the least secure thing connected to it. This directive takes aim at a practice which has long existed for many reasons, both practical and bureaucratic. Regardless of why, it is an important standard that CISA is setting. This will result in organizations being more secure to complete takeovers such as ransomware deployments. If your environment is entrenched with strong ZT across your architecture, or your most vital networking resources are managed within an isolated network, it makes it demonstrably more difficult for an attacker to leverage the entire network. You can also apply concepts such as Chaos Engineering. Testing the viability of your network under stress and unexpected circumstances is a fantastic way to gain a true understanding of weak points. Defenders utilizing these frameworks and ideas to holistically control the security of their environments is what sights should remain set on. When CISA comes knocking on BOD 23-02 findings, it may open the door to improving some process somewhere related to the standing up of network infrastructure.
To learn more about binding operational directives, see this page on the CISA website.
If you haven’t had a chance to hear Jen Easterly herself speak with Patrick Garrity, VP and security researcher at Nucleus about binding operational directives and other topics, check out the interview on LinkedIn here.