Broadcom Content Analysis System (CAS) Security Technical Implementation Guide

Network devices running an unsupported operating system lack current security fixes required to mitigate the risks associated with recent vulnerabilities. Satisfies: SRG-APP-000516-NDM-000351, SRG-APP-000457-NDM-000352, SRG-APP-001035-NDM-000340

System entry and exit points include firewalls, remote access servers, workstations, electronic mail servers, web servers, proxy servers, notebook computers, and mobile devices. Malicious code includes viruses, worms, Trojan horses, and spyware. Malicious code can also be encoded in various formats contained within compressed or hidden files or hidden in files using techniques such as steganography. Malicious code can be inserted into systems in a variety of ways, including by electronic mail, the world wide web, and portable storage devices. Malicious code insertions occur through the exploitation of system vulnerabilities. A variety of technologies and methods exist to limit or eliminate the effects of malicious code. Malicious code protection mechanisms include both signature- and nonsignature-based technologies. Nonsignature-based detection mechanisms include artificial intelligence techniques that use heuristics to detect, analyze, and describe the characteristics or behavior of malicious code and to provide controls against such code for which signatures do not yet exist or for which existing signatures may not be effective. Malicious code for which active signatures do not yet exist or may be ineffective includes polymorphic malicious code (i.e., code that changes signatures when it replicates). Nonsignature-based mechanisms also include reputation-based technologies. In addition to the above technologies, pervasive configuration management, comprehensive software integrity controls, and anti-exploitation software may be effective in preventing the execution of unauthorized code. Malicious code may be present in commercial off-the-shelf software as well as custom-built software and could include logic bombs, backdoors, and other types of attacks that could affect organizational mission and business functions. In situations where malicious code cannot be detected by detection methods or technologies, organizations rely on other types of controls, including secure coding practices, configuration management and control, trusted procurement processes, and monitoring practices to ensure that software does not perform functions other than the functions intended. Organizations may determine that, in response to the detection of malicious code, different actions may be warranted. For example, organizations can define actions in response to malicious code detection during periodic scans, the detection of malicious downloads, or the detection of maliciousness when attempting to open or execute files.

Unencrypted and weakly encrypted connections used for administrative sessions are highly susceptible to man-in-the-middle (MITM) attacks, eavesdropping, and session hijacking. If nonsecure protocols (such as HTTP or Telnet) or deprecated cryptographic algorithms are permitted, malicious actors can intercept sensitive management traffic, capture administrative credentials, or inject unauthorized commands into the session stream. To mitigate these risks, DoW policy mandates that all administrative communications must be protected using strong, approved cryptography. This ensures the confidentiality of the data in transit (preventing unauthorized viewing), the integrity of the session (preventing unauthorized modification), and the authenticity of the endpoints (ensuring the administrator is communicating with the genuine device). For the Broadcom CAS, enforcing FIPS mode ensures the appliance strictly utilizes FIPS 140-3-validated cryptographic modules. Activating this mode inherently disables nonsecure legacy protocols and weak ciphers, guaranteeing that all administrative management interfaces rely solely on DoW-approved encryption standards to protect the system from exploitation. Satisfies: SRG-APP-000179-NDM-000265, SRG-APP-000142-NDM-000245, SRG-APP-000224-NDM-000270, SRG-APP-000411-NDM-000330, SRG-APP-000412-NDM-000331

If a network device does not strictly enforce access control policies, a compromised account or an insider threat could gain unrestricted access to the entire system. Without the principle of least privilege and separation of duties, a standard administrator might be able to alter cryptographic keys, modify security policies, or delete audit logs to cover their tracks. To mitigate this risk, the system must employ RBAC. By mapping authenticated users to specific, restricted roles (such as separating full Administrators from Read-Only viewers), the CAS ensures that users are only granted the specific permissions necessary to perform their assigned duties. This architectural enforcement protects the integrity of audit trails, secures cryptographic modules, and ensures compliance with DoW access control mandates. Network devices that rely on AAA brokers for authentication and authorization services may need to identify the available security groups or access levels available on the network devices and convey that information to the AAA operator. Once the AAA broker identifies the user persona on the centralized directory service, the user’s security group memberships can be retrieved. The AAA operator may need to create a mapping that links target security groups from the directory service to the appropriate security groups or access levels on the network device. Once these mappings are configured, authorizations can happen dynamically, based on each user’s directory service group membership. Satisfies: SRG-APP-000033-NDM-000212, SRG-APP-000119-NDM-000236, SRG-APP-000120-NDM-000237, SRG-APP-000121-NDM-000238, SRG-APP-000122-NDM-000239, SRG-APP-000123-NDM-000240, SRG-APP-000133-NDM-000244, SRG-APP-000231-NDM-000271, SRG-APP-000329-NDM-000287, SRG-APP-000340-NDM-000288, SRG-APP-000378-NDM-000302, SRG-APP-000380-NDM-000304, SRG-APP-000408-NDM-000314, SRG-APP-000516-NDM-000335

Authentication for administrative (privileged level) access to the device is required at all times. An account can be created on the device's local database for use when the authentication server is down or connectivity between the device and the authentication server is not operable. This account is referred to as the account of last resort since it is intended to be used as a last resort and when immediate administrative access is absolutely necessary. The account of last resort logon credentials must be stored in a sealed envelope and kept in a safe. The safe must be periodically audited to verify the envelope remains sealed. The signature of the auditor and the date of the audit should be added to the envelope as a record. Administrators should secure the credentials and disable the root account (if possible) when not needed for system administration functions.

Legacy cryptographic protocols, such as TLS version 1.0 and 1.1, contain inherent design flaws and known vulnerabilities that allow attackers to decrypt or manipulate data in transit. To secure the system's communication channels and APIs (such as the ICAP interface), these nonsecure protocols must be explicitly disabled. The appliance must be configured to enforce only DoW-approved, secure protocols (TLS 1.2 and TLS 1.3) to ensure the confidentiality and integrity of all transmitted data.

Multifactor authentication (MFA) is when two or more factors are used to confirm the identity of an individual who is requesting access to digital information resources. Valid factors include something the individual knows (e.g., username and password), something the individual has (e.g., a smartcard or token), or something the individual is (e.g., a fingerprint or biometric). Legacy information system environments only use a single factor for authentication, typically a username and password combination. Although two pieces of data are used in a username and password combination, this is still considered single factor because an attacker can obtain access simply by learning what the user knows. Common attacks against single-factor authentication are attacks on user passwords. These attacks include brute force password guessing, password spraying, and password credential stuffing. MFA, along with strong user account hygiene, helps mitigate against the threat of having account passwords discovered by an attacker. Even in the event of a password compromise, with MFA implemented and required for interactive login, the attacker still needs to acquire something the user has or replicate a piece of user’s biometric digital presence. Private industry recognizes and uses a wide variety of MFA solutions. However, DoW public key infrastructure (PKI) is the only prescribed method approved for DoW organizations to implement MFA. For authentication purposes, centralized DoW certificate authorities (CA) issue PKI certificate key pairs (public and private) to individuals using the prescribed x.509 format. The private certificates that have been generated by the issuing CA are downloaded and saved to smartcards which, within DoW, are referred to as common access cards (CAC) or personal identity verification (PIV) cards. This happens at designated DoW badge facilities. The CA maintains a record of the corresponding public keys for use with PKI-enabled environments. Privileged user smartcards, or "alternate tokens", function in the same manner, so this requirement applies to all interactive user sessions (authorized and privileged users). Note: This requirement is used in conjunction with the use of a centralized authentication server (e.g., AAA, RADIUS, LDAP), a separate but equally important requirement. The MFA configuration of this requirement provides identification and the first phase of authentication (the challenge and validated response, thereby confirming the PKI certificate that was presented by the user). The centralized authentication server will provide the second phase of authentication (the digital presence of the PKI ID as a valid user in the requested security domain) and authorization. The centralized authentication server will map validated PKI identities to valid user accounts and determine access levels for authenticated users based on security group membership and role. In cases where the centralized authentication server is not utilized by the network device for user authorization, the network device must map the authenticated identity to the user account for PKI-based authentication. Satisfies: SRG-APP-000149-NDM-000247, SRG-APP-000825-NDM-000180

Once issued by a DoW certificate authority (CA), public key infrastructure (PKI) certificates are typically valid for three years or shorter within the DoW. However, there are many reasons a certificate may become invalid before the prescribed expiration date. For example, an employee may leave or be terminated and still possess the smartcard on which the PKI certificates were stored. Another example is that a smartcard containing PKI certificates may become lost or stolen. A more serious issue could be that the CA or server which issued the PKI certificates has become compromised, thereby jeopardizing every certificate keypair that was issued by the CA. These examples of revocation use cases and many more can be researched further using internet cybersecurity resources. PKI user certificates presented as part of the identification and authentication criteria (e.g., DoW PKI as multifactor authentication [MFA]) must be checked for validity by network devices. For example, valid PKI certificates are digitally signed by a trusted DoW CA. Additionally, valid PKI certificates are not expired, and valid certificates have not been revoked by a DoW CA. Network devices can verify the validity of PKI certificates by checking with an authoritative CA. One method of checking the status of PKI certificates is to query databases referred to as CRLs. These are lists which are published, updated, and maintained by authoritative DoW CAs. For example, once certificates are expired or revoked, issuing CAs place the certificates on a CRL. Organizations can download these lists periodically (i.e., daily or weekly) and store them locally on the devices themselves or even onto another nearby local enclave resource. Storing them locally ensures revocation status can be checked even if internet connectivity is severed at the enclave’s point of presence (PoP). However, CRLs can be rather large in storage size and further, the use of CRLs can be rather taxing on some computing resources. Another method of validating certificate status is to use the OCSP. Using OCSP, a requestor (i.e., the network device which the user is trying to authenticate to) sends a request to an authoritative CA challenging the validity of a certificate that has been presented for identification and authentication. The CA receives the request and sends a digitally signed response indicating the status of the user’s certificate as valid, revoked, or unknown. Network devices should only allow access for responses that indicate the certificates presented by the user were considered valid by an approved DoW CA. OCSP is the preferred method because it is fast, provides the most current status, and is lightweight.

Without mapping the PKI certificate to a unique user account, the ability to determine the identities of individuals or the status of their nonrepudiation is considerably impacted during forensic analysis. A strength of using PKI as multifactor authentication (MFA) is that it can help ensure only the assigned individual is using their associated user account. This can only be accomplished if the network device is configured to enforce the relationship which binds PKI certificates to unique user accounts. Local accounts (accounts created, stored, and maintained locally on the network device) should be avoided in lieu of using a centrally managed directory service. Local accounts empower the same workgroup who will be operating the network infrastructure to also control and manipulate access methods, thus creating operational autonomy. This undesirable approach breaks the concept of separation of duties. Additionally, local accounts are susceptible to poor cyber hygiene because they create another user database that must be maintained by the operator, whose primary focus is on running the network. Such examples of poor hygiene include dormant accounts that are not disabled or deleted, employees who have left the organization but whose accounts are still present, periodic password and hash rotation, password complexity shortcomings, increased exposure to insider threat, etc. For reasons such as this, local users on network devices are frequently the targets of cyber-attacks. Instead, organizations should explore examples of centrally managed account services. These examples include the implementation of AAA concepts like the use of external Remote Authentication Dial-In User Service (RADIUS) and Lightweight Directory Access Protocol (LDAP) directory service brokers. Satisfies: SRG-APP-000177-NDM-000263, SRG-APP-000516-NDM-000336

Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. In addition, quickly terminating an idle session will also free up resources committed by the managed network element. Terminating network connections associated with communications sessions includes, for example, de-allocating associated TCP/IP address/port pairs at the operating system level, or de-allocating networking assignments at the application level if multiple application sessions are using a single, operating system-level network connection. This does not mean that the device terminates all sessions or network access; it only ends the inactive session and releases the resources associated with that session.

Allowing administrators to rely solely on local, device-specific accounts makes it difficult to manage identities and maintain a consistent security posture across the enterprise. In a large DoW environment, managing individual accounts on every network device is labor-intensive and prone to error, such as failing to disable an account when a member leaves the organization. Furthermore, using unencrypted protocols (like plain LDAP) to transmit administrative credentials allows for the interception of passwords via packet sniffing. To mitigate these risks, the CAS must be configured to utilize a centralized authentication server (such as Active Directory) via Secure LDAP (LDAPS). This architecture ensures that management access is centrally governed by enterprise security policies and that all authentication traffic is cryptographically protected, satisfying DoW mandates for secure, centralized identity management. Satisfies: SRG-APP-000516-NDM-000336, SRG-APP-000156-NDM-000250, SRG-APP-000400-NDM-000313, SRG-APP-000820-NDM-000170

The aggregation of log data kept on a syslog server can be used to detect attacks and trigger an alert to the appropriate security personnel. The stored log data can be used to detect weaknesses in security that enable the network IA team to find and address these weaknesses before breaches can occur. Reviewing these logs, whether before or after a security breach, are important in showing whether someone is an internal employee or an outside threat. Satisfies: SRG-APP-000516-NDM-000350, SRG-APP-000357-NDM-000293, SRG-APP-000515-NDM-000325