Implementing F5 NGINX STIGs: A Practical Guide to DoD Security Compliance
Introduction In today’s security-conscious environment, particularly within federal and DoD contexts, Security Technical Implementation Guides (STIGs) have become the gold standard for hardening systems and applications. For organizations deploying NGINX—whether as a web server, reverse proxy, or load balancer—understanding and implementing NGINX STIGs is critical for maintaining compliance and securing your infrastructure. This guide walks through the essential aspects of NGINX STIG implementation, providing practical insights for security engineers and system administrators tasked with meeting these stringent requirements. Understanding STIGs and Their Importance STIGs are configuration standards created by the Defense Information Systems Agency (DISA) to enhance the security posture of DoD information systems. These guides provide detailed technical requirements for securing software, hardware, and networks against known vulnerabilities and attack vectors. For NGINX deployments, STIG compliance ensures: Protection against common web server vulnerabilities Proper access controls and authentication mechanisms Secure configuration of cryptographic protocols Comprehensive logging and auditing capabilities Defense-in-depth security posture Key NGINX STIG Categories Access Control and Authentication Critical Controls: The STIG mandates strict access controls for NGINX configuration files and directories. All NGINX configuration files should be owned by root (or the designated administrative user) with permissions set to 600 or more restrictive. # Verify permissions sudo chmod 600 /etc/nginx/nginx.conf Client Certificate Authentication: For environments requiring mutual TLS authentication, NGINX must be configured to validate client certificates: # Include the following lines in the server {} block of nginx.conf: ssl_certificate /etc/nginx/ssl/server_cert.pem; ssl_certificate_key /etc/nginx/ssl/server_key.pem; # Enable client certificate verification ssl_client_certificate /etc/nginx/ca_cert.pem; ssl_verify_client on; # Optional: Set verification depth for client certificates ssl_verify_depth 2; location / { proxy_pass http://backend_service; # Restrict access to valid PIV credentials if ($ssl_client_verify != SUCCESS) { return 403; } } Certificate Management: All certificates must be signed by a DoD-approved Certificate Authority Private keys must be protected with appropriate file permissions (400) Certificate expiration dates must be monitored and renewed before expiry Cryptographic Protocols and Ciphers One of the most critical STIG requirements involves configuring approved cryptographic protocols and cipher suites. Approved TLS Versions: STIGs typically require TLS 1.2 as a minimum, with TLS 1.3 preferred: ssl_protocols TLSv1.2 TLSv1.3; FIPS-Compliant Cipher Suites: When operating in FIPS mode, NGINX must use only FIPS 140-2 validated cipher suites: ssl_ciphers 'TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256'; ssl_prefer_server_ciphers on; Logging and Auditing Comprehensive logging is mandatory for STIG compliance, enabling security monitoring and incident response. Required Log Formats: log_format security_log '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" ' '$request_time $upstream_response_time ' '$ssl_protocol/$ssl_cipher'; access_log /var/log/nginx/access.log security_log; error_log /var/log/nginx/error.log info; Key Logging Requirements: Log all access attempts (successful and failed) Capture client IP addresses and authentication details Record timestamps in UTC or local time consistently Ensure logs are protected from unauthorized modification (600 permissions) Implement log rotation and retention policies Pass Security Attributes via a Proxy STIGs require implementation of security attributes to implement security policy for access control and flow control for users, data, and traffic: # Include the "proxy_pass" service as well as the "proxy_set_header" values as required: proxy_pass http://backend_service; proxy_set_header X-Security-Classification "Confidential"; proxy_set_header X-Data-Origin "Internal-System"; proxy_set_header X-Access-Permissions "Read,Write"; Request Filtering and Validation Protecting against malicious requests is a core STIG requirement: # Limit request methods if ($request_method !~ ^(GET|POST|PUT|DELETE|HEAD)$) { return 405; } # Request size limits client_max_body_size 10m; client_body_buffer_size 128k; # Timeouts to prevent slowloris attacks client_body_timeout 10s; client_header_timeout 10s; keepalive_timeout 5s 5s; send_timeout 10s; # Rate limiting limit_req_zone $binary_remote_addr zone=req_limit:10m rate=10r/s; limit_req zone=req_limit burst=20 nodelay; SIEM Integration Forward NGINX logs to SIEM platforms for centralized monitoring: # Syslog integration error_log syslog:server=siem.example.com:514,facility=local7,tag=nginx,severity=info; access_log syslog:server=siem.example.com:514,facility=local7,tag=nginx NGINX Plus Specific STIG Considerations Organizations using NGINX Plus have additional capabilities to meet STIG requirements: Active Health Checks upstream backend { zone backend 64k; server backend1.example.com; server backend2.example.com; } match server_ok { status 200-399; header Content-Type ~ "text/html"; body ~ "Expected Content"; } server { location / { proxy_pass http://backend; health_check match=server_ok; } } JWT Authentication For API security, NGINX Plus can validate JSON Web Tokens: location /api { auth_jwt "API Authentication"; auth_jwt_key_file /etc/nginx/keys/jwt_public_key.pem; auth_jwt_require exp iat; } Dynamic Configuration API The NGINX Plus API must be secured and access-controlled: location /api { api write=on; allow 10.0.0.0/8; # Management network only deny all; # Require client certificate ssl_verify_client on; } Best Practices for STIG Implementation Start with Baseline Configuration: Use DISA's STIG checklist as your starting point and customize for your environment. Implement Defense in Depth: STIGs are minimum requirements; layer additional security controls where appropriate. Automate Validation: Use configuration management and automated scanning to maintain continuous compliance. Document Deviations: When technical controls aren't feasible, document risk acceptances and compensating controls. Regular Updates: STIGs are updated periodically; establish a process to review and implement new requirements. Testing Before Production: Validate STIG configurations in development/staging before deploying to production. Monitor and Audit: Implement continuous monitoring to detect configuration drift and security events. Conclusion Achieving and maintaining NGINX STIG compliance requires a comprehensive approach combining technical controls, process discipline, and ongoing vigilance. While the requirements can seem daunting initially, properly implemented STIGs significantly enhance your security posture and reduce risk exposure. By treating STIG compliance as an opportunity to improve security rather than merely a checkbox exercise, organizations can build robust, defensible NGINX deployments that meet the most stringent security requirements while maintaining operational efficiency. Remember: security is not a destination but a journey. Regular reviews, updates, and continuous improvement are essential to maintaining compliance and protecting your infrastructure in an ever-evolving threat landscape. Additional Resources DISA STIG Library: https://public.cyber.mil/stigs/ NGINX Security Controls: https://docs.nginx.com/nginx/admin-guide/security-controls/ NIST Cybersecurity Framework: https://www.nist.gov/cyberframework Have questions about implementing NGINX STIGs in your environment? Share your challenges and experiences in the comments below.Zero Trust Application Access for Federal Agencies
Introduction Zero Trust Network Access (ZTNA) and Zero Trust Application Access (ZTAA) represent two distinct architectural approaches to implementing zero trust application access. ZTAA is emerging as the superior choice for enterprises seeking high-performance, application-centric protection. While both operate under the "never trust, always verify" principle, ZTAA can deliver better performance, lower costs, and provide greater granular control at the application layer, where business-critical assets reside. As a leader in application access, F5 provides strong authentication and authorization through its mature BIG-IP Access Policy Manager platform. Access Policy Manager, or APM, is a tool that helps organizations with zero trust. It does this by following many of the zero trust principles that organizations like the DoD, CISA, and NIST document. Capabilities like strong encryption, user interrogation, conditional and contextual access, device posture, risk scoring, and API integration with third-party security vendors all contribute to a modern zero-trust access solution. It can be said that F5 and APM were the original zero-trust access solutions long before Forrester coined the term "zero trust" back in 2010. Understanding the Architectural Divide ZTNA operates as a network-centric model, creating secure tunnels from users to applications through centralized trust brokers and gateways. This approach can necessitate substantial modifications to the network infrastructure, client software deployment, and, in some cases, re-routing all traffic through tunnel concentration points. ZTNA is well-established and has well-established vendor ecosystems. However, ZTNA can cause performance problems, increase latency, and require big changes to the network architecture. Zero Trust Application Access is different because it focuses on individual applications. It protects these applications directly by using reverse proxies that are already in place in the business environments where these applications are located or at cloud gateways for cloud-based workloads. This architecture lets users connect directly to applications without tunneling. This means no extra work, keeps existing network investments, and gives you control at the application layer. ZTAA operates agentless in many scenarios and integrates seamlessly with cloud-native, containerized, and microservices architectures. F5 Zero Trust Direct Application Access The technical differences create distinct performance profiles. ZTNA's tunnel concentration can create bottlenecks for high-volume applications and add latency from traffic backhauling. At the same time, ZTAA eliminates these performance issues through direct application access and a distributed proxy architecture. Organizations with large application portfolios, cloud-native environments, or performance-sensitive applications find that ZTAA delivers superior user experience and operational efficiency. It is worth noting that ZTNA solutions are, at their core, just a proxy and use encryption for transport, such as TLS or IPsec. ZTAA or ZTNA? Application portfolio size serves as a strong decision criterion. Cost and complexity are also strong considerations. Organizations with fewer than 20 applications, primarily legacy systems, and uniform user bases typically find ZTNA's network-centric approach adequate. However, enterprises with 20+ applications, cloud-native architectures, and diverse user requirements achieve better outcomes with ZTAA's application-specific controls. Performance requirements strongly favor ZTAA for high-volume, real-time, or latency-sensitive applications. Cost considerations also help ZTAA adoption. It can be implemented for a smaller amount of ZTNA costs (depending on how the vendor is doing it) while keeping current network infrastructure investments. Organizations prioritizing rapid deployment, application-by-application rollout, or cloud-first strategies find ZTAA's minimal infrastructure impact and flexible deployment models advantageous. Infrastructure strategy alignment matters significantly. ZTNA is best for big network changes and unified SASE plans. ZTAA is best for applications-first approaches, DevOps cultures, and cloud-native changes. The regulatory environment influences decisions, with some compliance frameworks requiring network-level controls that favor ZTNA, while others benefit from ZTAA's granular application-level security audit trails. F5's ZTAA Leadership Position for Federal Agencies F5 has a strong security position in both federal and commercial landscapes—nearly all the Fortune 50 trust F5 to protect their most mission-critical applications. In addition, federal organizations like the DoD and civilian agencies trust F5 to preserve our nation's most critical infrastructure. The federal sector was an early adopter of zero trust principles. NIST and CISA were instrumental in designing zero-trust reference architectures. The NIST 800-207 document was a landmark, describing how organizations can approach the implementation of a zero-trust architecture in their environments. The DoD Zero Trust Strategy document builds off this architecture and gets specific by calling out controls under each zero trust pillar. The DoD Zero Trust Strategy document outlines 152 targets and requirements for achieving a mature zero trust implementation. F5 today meets or partially meets 57 of those targets. In addition, recent work was published by the NCOEE/NIST describing a completely independent, tested solution utilizing F5 as a Zero Trust Application Access. CISA 5 Pillar Maturity Model – Optimal Level F5 Key Capabilities for Zero Trust Application Access F5 BIG-IP APM Identity Aware Proxy (ZTAA) uses access control per request that checks each application access attempt individually. This moves from session-based authentication to transaction-level verification. The platform provides context-aware authentication, evaluating user identity, device posture, location, and application sensitivity for each request. Continuous device posture checking maintains real-time, ongoing assessments throughout user sessions with adaptive multi-factor authentication and risk-based step-up authentication. F5's Privileged User Access (PUA) solution complements ZTAA with DoD-approved capabilities for both privileged and unprivileged user authentication to government systems. The agent-free deployment adds strong authentication, including CAC/PKI and MFA, to old systems that don’t have native support. It also manages temporary passwords and has many audit trails to make sure the system is compliant and secure. The solution is truly zero trust, with neither the end user nor the endpoint knowing the ephemeral password used during the session. Passwords are never stored on disk and are destroyed when the session terminates, creating a strong access solution. Full proxy architecture brings visibility into your network data plane. Protocols like TLS 1.3 and Post-Quantum look to strengthen your network security posture, but they also bring potential blind spots. TLS 1.3 key structure is ephemeral by design. This protocol feature is excellent for application security, but it creates potential blind spots for threat hunters. Traditionally, packet capture inspections happen out of band and potentially at a future date. With TLS 1.3, packet inspection out of band becomes increasingly tricky. Since TLS 1.3 is a perfect forward secret by default, the symmetric key used during sessions is ephemeral. This means you will need every ephemeral key generated during a session to decrypt out of band. This creates challenges with the SOC and your threat hunters. F5 can help with its SSL Orchestration solution. By orchestrating decrypted traffic to your security inspection stack and re-encrypting it to your applications, you can utilize all the strong security features of TLS 1.3 and PQC while still providing complete visibility into your data-plane traffic. Additional Distinctions F5's full-proxy architecture enables comprehensive traffic inspection and control that competitors cannot match. F5 provides a unified platform integrating ZTAA, application delivery, and enterprise-grade security capabilities. The platform also offers fast TLS decryption at large scale without slowing down performance. It also supports old applications and new web services. F5 adds advanced bot detection, fraud prevention, and API security capabilities that pure-play ZTNA vendors lack. F5's extensive identity provider partnerships include deep Microsoft Azure AD integration with Conditional Access policies, native Okta SAML/OIDC federation, and comprehensive custom LDAP/Active Directory support. Protocol support spans SAML, OAuth, OIDC, RADIUS, LDAP, and Active Directory with flexible deployment across on-premises, cloud, hybrid, and managed service models. Identity Aware Proxy - Key Capabilities APM's Identity Aware Proxy is F5's Zero Trust Application Access solution. We throw around a lot of acronyms in the IT industry, so I just wanted to get that out of the way and make it clear. As I mentioned earlier in this post, F5 can currently meet or partially meet 57 of the 152 targets listed in the DoD Zero Trust strategy guide. APM's IAP solution helps meet many of those 57 targets. Let’s look at some of these features in the access guided configuration. You can find it in the APM or Access Policy Manager’s GUI. If you would like to see a full walk-through sample config, check out this page for a great write-up and lab. Authentication and Authorization Authentication and authorization are at the forefront of any Zero Trust solution. APM provides for robust authentication and authorization integration out of the box. APM has deep integration with Active Directory and supports many of the identity SaaS providers, such as Okta, Ping, SailPoint, and Azure Entra ID. In the image above, MFA is a capability built into the GUI, which makes it very easy to implement a two-factor solution within your ZTAA solution. MFA should be a component of every Zero Trust solution, and F5 makes it easy to integrate with your favorite identity provider. Conditional and Contextual Access Another key component of any ZTAA solution is conditional and contextual access. The new perimeter in a zero-trust world doesn't really exist. We should prioritize protecting the data and application, rather than focusing on our network perimeter security. This is not completely true, as we will keep using network firewalls. But the main idea of zero trust is about data and strong identity, not gateways into our networks. Based on that last sentence, we must be able to interrogate both the user and the device they are accessing from. This involves checking a device's posture for an active firewall or determining its location and the time of day of access. Users should be required to provide a strong identity to include MFA and ABAC controls. In the image below, we show the contextual configuration options for Identity Aware Proxy. This capability makes it easy to configure complex if-then logic flows. Another strong capability sometimes overlooked is APM's ability to query third-party systems for additional context. The HTTP Connector, as shown below, allows the administrator to configure a third-party risk score provider or additional telemetry for access decisions. This is all done via API calls, and so it makes interoperability seamless with other ecosystem vendors. Conclusion ZTAA is the change from zero trust architecture to application-focused security. It offers better performance, strong identity, lower costs, and more flexibility than traditional ZTNA approaches. F5 leads this transformation through its authentication and authorization technology platform, comprehensive application security capabilities, and proven enterprise deployment success across federal and civilian agencies. Organizations evaluating zero trust solutions should prioritize ZTAA for their application portfolios, cloud-native environments, and performance-critical deployments. F5's unified platform approach, technical differentiators, and market-leading capabilities make it the clear choice for enterprises seeking comprehensive zero-trust application access solutions that scale with business growth and digital transformation initiatives.How to Extract the UPN from a Digital Certificate on a CAC card using F5 APM
Introduction This article describes two different methods to extract the UPN from the digital certificate for further processing by the BIG-IP. While there are other excellent articles that show you how to build out the entire access policy, this article concentrates on the methods for extracting the UPN. Some Context The CAC card is a "smart" card about the size of a credit card, it is the standard identification for active duty uniformed Service personnel, Selected Reserve, DoD civilian employees, and eligible contractor personnel. It is also the principal card used to enable physical access to buildings and controlled spaces, and it provides access to DoD computer network and systems. Accessing DoD PKI-protected information is most commonly achieved using the PKI certificates stored on your Common Access Card (CAC). The certificates on your CAC can allow you to perform routine activities such as accessing OWA, signing documents, and viewing other PKI-protected information online. In F5, the typical authentication motion for F5 Access Policy Manager when dealing with common access cards is to:- Present a DoD Warning Banner Validate the Certificate through TLS Validate that the certificate has not been revoked Pull the UPN field of the certificate to search for the user in LDAP The F5 Access Policy Manager uses the Universal Principal Name (UPN) taken from the Subject Alternative Name (SAN) field of the Signature Certificate to search for the user in LDAP and allow or deny access based on the information found. The diagram below shows the value that we will be pulling from the certificate to use for further authentication. On a DoD CAC the UPN would be of the format EDIPI@mil. The following describes two methods to extract the UPN as part of an APM policy. If you prefer, I have published a 5-minute demonstration video outlining the steps presented in this article. Otherwise, you may continue reading, or refer back at your desired pace, to the step-by-step presented below. Method One – a Variable Assign within an access policy This method relies on the use of an access policy item called a “Variable Assign” that contains a custom expression. In the diagram below we are placing a variable assign access policy item after checking that the certificate is valid through mutual tls with the On Demand Cert Auth and then checking with an OCSP server that the certificate has not been revoked via OCSP. To add the variable assign click the ‘+’ item in the visual policy editor and select the variable assign item in the visual policy editor. The variable assign is under the Assignment tab in the Visual Policy Editor. In the variable assign give the access policy item a name for instance “upn_extract” and then click the “Add New Entry” button. Then ensure that Custom Variable is selected Create a variable name – for instance session.custom.upn On the right side select “Custom Expression” And place the following expression in the entry field below.. this expression parses the x509 certificate attributes on the CAC card for the UPN. set x509e_fields [split [mcget {session.ssl.cert.x509extension}] "\n"]; # For each element in the list: foreach field $x509e_fields { # If the element contains UPN: if { $field contains "othername:UPN" } { ## set start of UPN variable set start [expr {[string first "othername:UPN<" $field] +14}] # UPN format is <user@domain> # Return the UPN, by finding the index of opening and closing brackets, then use string range to get everything between. return [string range $field $start [expr { [string first ">" $field $start] - 1 } ] ]; } } # Otherwise return UPN Not Found: return "UPN-NOT-FOUND"; Click “Finished”. Method Two – an Access Policy Agent Event with an iRule The second method relies on the use of an access policy item called an “iRule Event” that uses an iRule to extract the UPN. In the diagram below we are placing an iRule event access policy item after checking that the certificate is valid through mutual tls with the On Demand Cert Auth and then checking with an OCSP server that the certificate has not been revoked via OCSP. To add the iRule Event click the ‘+’ item in the visual policy editor and select the variable assign item in the visual policy editor. The iRule Event is under the General Purpose tab in the Visual Policy Editor. Then provide a name and a Custom iRule Event Agent ID. I like to make the name the same as the identifier, but they can bet different. The custom iRule Event Agent ID ties the visual policy editor iRule event item to an iRule. Create the iRule. Now under Local Traffic/iRules click the create button. Provide a name for the iRule. And place the following iRule in the entry field this iRule parses the x509 certificate attributes on the CAC card for the UPN. when ACCESS_POLICY_AGENT_EVENT { if { [ACCESS::policy agent_id] eq "CERTPROC"} { # This event extracts the user principal name from a client-certificate and places it into a session variable. if { [ACCESS::session data get session.ssl.cert.x509extension] contains "othername:UPN<" } { ACCESS::session data set session.custom.upn [findstr [ACCESS::session data get session.ssl.cert.x509extension] "othername:UPN<" 14 ">"] } } } Click “Finished” Then on the virtual server that provides the service select “Resources” and then select “Manage” Finally move the CERTPROC iRule from available to enabled. Conclusion Both of these methods will ultimately result in the user principal name, the “UPN” being stored in a session variable within the access policy. This session variable can then be used in an LDAP lookup that can verify that the user exists within the directory and can also be used to pull further information from the directory that will enable additional verification and authentication. Examples might be performing single sign on to an application or determining group membership. Which one is better? (Editorial Time) While both methods are completely valid. I prefer the variable assign within an access policy as it provides a single place in the VPE where the configuration resides. It also allows for a more rapid understanding of the configuration from a troubleshooting perspective as the expression resides within the visual policy. The iRule method means there will be multiple locations where the configuration resides, an experienced APM administrator will be able to quickly determine that an iRule is being used, for a less experienced APM administrator this may take some more time to determine that an iRule is being used and this could hinder future trouble shooting. On the other hand the iRule method is more performant than the expression method and may be a better for a high traffic APM VIP.
