Last month, the Cybersecurity and Infrastructure Security Agency released Binding Operational Directive 23-02: Mitigating the Risk from Internet-Exposed Management Interfaces – a directive aimed at securing both network management devices (e.g., firewalls, routers, VPNs, etc.) and any device that can be remotely managed using a variety of protocols including HTTP, FTP, SSH, SMB, and RDP.
The directive mandates that governmental agencies and sub-agencies make applicable interfaces – whether internally discovered or “within 14 days of notification by CISA” – only accessible internally or deploy access controls where policy enforcement is established from a separate device (a basic tenet of a Zero Trust architecture).
CISA also clarified that they planned to scan for devices and interfaces in the scope of the Directive and notify agencies of all findings. Not more than two weeks later, an analysis of more than 50 federal civilian executive branch agencies was conducted by Internet threat-hunting vendor Censys. In total, Censys found over 250 instances of “web interfaces for hosts exposing network appliances, many of which were running remote protocols”.
The analysis definitely confirms CISA’s worst fears; that, despite a belief that an agency’s network is secure, there are plenty of exposed ports providing threat actors with management communication protocols that can potentially be misused for malicious purposes.
So, what should organizations in the private sector take away from this directive and subsequent risk analysis? Three things come to mind:
- Any Kind of Remote Access Can be a Risk – While we spend a lot of time on this blog talking mostly about remote access from a user “remotely accessing a desktop” perspective, CISA’s list of protocols in the directive is rather extensive and aligns with the long list of examples found within two Initial Access techniques from the MITRE ATT&CK Framework: Exploit Public-Facing Application and External Remote Access. CISA does mention a number of remote desktop-type protocols in their directive as well, furthering the notion that this kind of access remains a risk.
- You Have More Present Risk Than You Think – The Censys analysis found an average of five interfaces per agency that met the directive’s criteria. Some of them were even using the Windows SMB protocol (meaning, in theory, an external machine could map a drive to a Windows share at the exposed IP address). Unless your organization does its own threat hunting and port scanning, you should assume you have more exposure than you know about and commission an analysis of your own externally facing risk.
- “Secure” is the Goal – While CISA’s first mandate is to “remove the interface from the internet”, it’s only mentioned as an alternative, should an agency not be able to bring the exposed remote access under proper controls. From the directive:
For the purposes of this Directive, as outlined in the required actions section below, networked management interfaces are allowed to remain accessible from the internet on networks where agencies employ capabilities to mediate all access to the interface in alignment with OMB M-22-09, NIST 800-207, the TIC 3.0 Capability Catalog, and CISA’s Zero Trust Maturity Model.
So, CISA is saying, IF you can properly secure your remote access (using Zero Trust as the standard), it’s acceptable to have it continue to be accessible from the Internet.
“Zero Trust Remote Access”?
All four of the referenced documents help to define Zero Trust principles. It’s important to keep in mind that there are only Zero Trust principles and solutions that adhere to these principles; there are no actual Zero Trust solutions (i.e., solutions that have somehow received a non-existent Zero Trust certification, etc.).
Applying this to your organization’s secure remote desktop access, what’s important – according to CISA’s directive – is:
- that the remote access is secured by policy
- that the policy engine (the system that establishes and pushes out security policies) be separate from the system proving the remote access.
So, to bring any remote access under “compliance” (if you will) with CISA’s directive for Zero Trust principles to be in place, there are a few things you can initially do:
- Use a Centrally Managed Remote Access Solution – If you are using, say, a single endpoint providing RDP access externally, you’re definitely not secure. You need to use a Remote Access solution that centrally establishes who can access which systems remotely, from where, when, etc.
- Use Multi-Factor Authentication (MFA) – nestled somewhat within the NIST 800-207 document that describes Zero Trust as a core tenet that states that MFA should be used. While not stated to be required at all times, we’re talking about providing access to an endpoint logically within the organization; it potentially could also be a persistent foothold for threat actors. So, MFA is needed here always.
- Determine if Secure Remote Access is All You Need – The state of organizational cybersecurity, in general, is moving towards Zero Trust, albeit slowly; fully implementing Zero Trust can literally take years. It’s why I emphasize the immediate need to embrace Zero Trust principles and not be concerned so much with needing to be “compliant” with Zero Trust (as if it’s a standard with specific implementation requirements… which it’s not). But for those of you thinking that you want to better understand what differentiates solutions like Zero Trust Network Access and a Secure Remote Access solution, read about which solution is right for your organization.
Get Your Remote Access Secure… And Fast!
If nothing else, the directive from CISA makes the case that the risk created by exposed remote access is something that needs to be addressed quickly; their 14-day required response time indicates how big a problem this is, and how fast your organization – regardless of whether you are in the public or private sector – should address the risk.
