Action Items in OMB Memorandum M-22-09 “Moving the U.S. Government Toward Zero Trust...”

January 26, 2022

Issuance of M-22-09 “Moving the U.S. Government Toward Zero Trust Cybersecurity Principles”

February 25, 2022

Agencies to designate and identify a zero trust strategy implementation lead for their organization

March 27, 2022

Submit to OMB and CISA an implementation plan for FY22-FY24

May 27, 2022

Chief Data Officers to develop a set of initial categorizations for sensitive electronic documents within their enterprise

January 26, 2023

Public-facing agency systems that support MFA must give users the option of using phishing-resistant authentication

January 26, 2023

Each agency must select at least one FISMA Moderate system that requires authentication and make it Internet accessible

August 27, 2022

Agencies must reach the first event logging maturity level (EL-1) as described in Memorandum M-21-31

End of FY2024

Agencies to achieve specific zero trust security goals

Page

Requirements

F5 Capabilities

F5 Products

6

Section A.1

“Enterprise identity management must be compatible with common applications and platforms. As a general matter, users should be able to sign in once and then directly access other applications and platforms within their agency’s IT infrastructure. Beyond compatibility with common applications, an agency identity management program should facilitate integration among agencies and with externally operated cloud services; the use of modern, open standards often promotes such integration.”

Proxies and transforms client side authentication method to adapt to application’s native authentication method. Modern authentication can now be applied to legacy web application without any changes.

BIG-IP APM

NGINX

7

Section A.2

Agencies must integrate and enforce MFA across applications involving authenticated access to Federal systems by agency staff, contractors, and partners.

MFA, including PIV, can be applied to any applications, whether legacy or modern, without changes.

BIG-IP APM

7

Section A.2

MFA should be integrated at the application layer

MFA, including PIV, can be applied to any applications, whether legacy or modern, without changes.

BIG-IP APM

7

Section A.2

guessing weak passwords or reusing passwords obtained from a data breach

Finds compromised credentials in real-time, identifies botnets, and blocks simulation software.

F5 Distributed Cloud Services

7

Section A.2

many approaches to multi-factor authentication will not protect against sophisticated phishing attacks, which can convincingly spoof official applications and involve dynamic interaction with users. Users can be fooled into providing a one-time code or responding to a security prompt that grants the attacker account access. These attacks can be fully automated and operate cheaply at significant scale.

Finds compromised credentials in real-time, identifies botnets, and blocks simulation software.

F5 Distributed Cloud Services

9

Section A.3

every request for access should be evaluated to determine whether it is appropriate, which requires the ability to continuously evaluate any active session

After a session starts, a per-request policy runs each time the client makes an HTTP or HTTPS request. A per-request policy must provide the logic for determining how to process web-bound traffic. It must determine whether to allow or reject a URL request and control whether or not to bypass SSL traffic.

BIG-IP APM

NGINX

10

Section A.3

Agency authorization systems should work to incorporate at least one device-level signal

alongside identity information about the authenticated user when regulating access to enterprise resources

High-efficacy digital fingerprinting identifies returning web client patterns from new edge devices.

F5 Distributed Cloud Services

12

Section C.1

Agencies should make heavy internal use of recent versions of standard encryption protocols, such as TLS 1.3

Regardless of your TLS version, you need to have visibility into encrypted threats to protect your business. SSL/TLS based-decryption devices that allow for packet inspection can intercept encrypted traffic, decrypt, inspect, and re-encrypt untrusted TLS traffic entering or leaving the network.

BIG-IP LTM

BIG-IP SSLO

NGINX

13

Section C.1

agencies should plan for cryptographic agility in their network architectures, in

anticipation of continuing to adopt newer versions of TLS

Organizations don’t want to reconfigure hundreds of servers just to offer these new protocols. This is where transformational services become cipher agility. Cipher agility is the ability of an SSL device to offer multiple cryptographic protocols such as ECC, RSA2048, and DSA at the same time—even on the same virtual server.

BIG-IP SSLO

13

Section C.2

agency DNS resolvers must support standard encrypted DNS protocols (DNS-over-HTTPS or DNS-over-TLS)

NOTE: DNSSEC does not encrypt DNS data in transit. DNSSEC can be used to verify the integrity of a resolved DNS query, but does not provide confidentiality.

DoH proxy—A passthrough proxy that proxies the client’s DoH request to a backend DoH server and the backend DoH server’s response back to the DoH client.

DoH server—The server translates the client’s DoH request into a standard DNS request and forwards the DNS request using TCP or User Datagram Protocol (UDP) to the configured DNS server, such as the BIG-IP named process and the BIG-IP DNS cache feature. When the BIG-IP system receives a response from the configured DNS server, it translates the DNS response into a DoH response before sending it to the DoH client.

BIG-IP DNS

14

Section C.3

Zero trust architectures—and this strategy— require agencies to encrypt all HTTP traffic, including within their environments.

Handle SSL traffic in load balancing scenario and meet most of the security requirements effectively. The 3 common SSL configurations that can be set up on LTM device are:

-SSL Offloading

-SSL Passthrough

-Full SSL Proxy / SSL Re-Encryption / SSL Bridging / SSL Terminations

BIG-IP LTM

BIG-IP SSLO

NGINX

18

Section D.4

Making applications internet-accessible in a safe manner, without relying on a virtual

private network (VPN) or other network tunnel

Proxy-based access controls deliver

a zero-trust platform for internal and external application access. That means applications are protected while extending trusted access to users, devices, and APIs.

BIG-IP LTM

BIG-IP APM

18

Section D.4

require agencies to put in place minimum viable monitoring infrastructure, denial of service protections, and an enforced access-control policy

Integrate with SIEM for agency wide monitoring or use F5 management platform for greater visibility. On-prem DDOS works in conjunction with cloud service to protect from various attack strategies.

BIG-IQ

BIG-IP AFM

BIG-IP ASM

F5 Distributed Cloud DDOS

19

Section D.6

Automated, immutable deployments support agency zero trust goals

Built-in support for automation and orchestration to work with technologies like Ansible, Terraform, Kubernetes and public clouds.

BIG-IP

NGINX

20

Section D.6

Agencies should work toward employing immutable workloads when deploying services,

Built-in support for automation and orchestration to work with technologies like Ansible, Terraform, Kubernetes and public clouds.

BIG-IP

NGINX

24

Section F.1

Agencies are undergoing a transition to IPv6, as described in OMB Memorandum M-21-

07, while at the same time migrating to a zero trust architecture

The BIG-IP device is situated between the clients and the servers to provide the applications the clients use. In this position—the strategic point of control—the BIG-IP device provides virtualization and high availability for all application services, making several physical servers look like a single entity behind the BIG-IP device. This virtualization capability provides an opportunity to start migrating either clients or servers—or both simultaneously—to IPv6 networks without having to change clients, application services, and both sides of the network all at once.

BIG-IP LTM

NGINX

24

Section F.2

OMB Memorandum M-19-1735 requires agencies to use PIV credentials as the “primary” means of authentication used for Federal information systems

PIV authentication can be applied to any applications, whether legacy or modern, without changes.

BIG-IP APM

25

Section F.3

Current OMB policies neither require nor prohibit inline decryption of enterprise network traffic

SSL Orchestrator is designed and purpose-built to enhance SSL/TLS infrastructure, provide security solutions with visibility into SSL/TLS encrypted traffic, and optimize and maximize your existing security investments.

BIG-IP SSLO

25

Section F.4

This memorandum expands the scope of M-15-13 to encompass these internal connections.

NOTE: M-15-13 specifically exempts internal connections, stating, “[T]he use of HTTPS is encouraged on intranets, but not explicitly required.”

SSL Orchestrator delivers dynamic service chaining and policy-based traffic steering, applying context-based intelligence to encrypted traffic handling to allow you to intelligently manage the flow of encrypted traffic across your entire security stack, ensuring optimal availability.

BIG-IP LTM

BIG-IP SSLO

NGINX