Unified Communications Session Management Security Requirements Guide

Attackers that are able to exploit an inactive account can potentially obtain and maintain undetected access to an application. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. Unified Communications Session Managers must track periods of user inactivity and disable accounts after 35 days of inactivity. Such a process greatly reduces the risk that accounts will be misused, hijacked, or data compromised. DOD has determined that 35 days is the appropriate time period of inactivity for Inactive accounts. Therefore, systems with a per user paradigm of management would apply.

Display of a standardized and approved use notification before granting access to the network ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist. This requirement applies to network elements that have the concept of a user account and have the logon function residing on the network element. The banner must be formatted in accordance with DTM-08-060. Use the following verbiage for network elements that can accommodate banners of 1300 characters: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." Use the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner: "I've read & consent to terms in IS user agreem't."

The banner must be acknowledged by the user prior to allowing the user access to the network. This provides assurance that the user has seen the message and accepted the conditions for access. If the consent banner is not acknowledged by the user, DOD will not be in compliance with system use notifications required by law. To establish acceptance of the application usage policy, a click-through banner at application logon is required. The network element must prevent further activity until the user executes a positive action to manifest agreement by clicking on a box indicating "OK". This requirement applies to network elements that have the concept of a user account and have the logon function residing on the network element.

Network element management includes the ability to control the number of users and user sessions that use a network element. Limiting the number of allowed users and sessions per user is helpful in limiting risks related to DoS attacks. This requirement addresses concurrent sessions for information system accounts and does not address concurrent sessions by single users via multiple system accounts. The maximum number of concurrent sessions should be defined based upon mission needs and the operational environment for each system. This applies to network elements that have the concept of a user account and have the login function residing on the network element.

Without the capability to generate session records, it is difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible. Session records are generated from several components within the Voice Video system (e.g., session manager, session border control, gateway, gatekeeper, or endpoints). Session record content that may be necessary to satisfy this requirement includes, for example, type of connection, connection origination, time stamps, outcome, user identities, and user identifiers. Additionally, an adversary must not be able to modify or delete session records.

Without the capability to generate session records, it is difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible. Session records are generated from several components within the Voice Video system (e.g., session manager, session border control, gateway, gatekeeper, or endpoints). Session record content that may be necessary to satisfy this requirement includes, for example, type of connection, connection origination, time stamps, outcome, user identities, and user identifiers. Additionally, an adversary must not be able to modify or delete session records.

Without the capability to generate session records, it is difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible. Session records are generated from several components within the Voice Video system (e.g., session manager, session border control, gateway, gatekeeper, or endpoints). Session record content that may be necessary to satisfy this requirement includes, for example, type of connection, connection origination, time stamps, outcome, user identities, and user identifiers. Additionally, an adversary must not be able to modify or delete session records.

Without the capability to generate session records, it is difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible. Session records are generated from several components within the Voice Video system (e.g., session manager, session border control, gateway, gatekeeper, or endpoints). Session record content that may be necessary to satisfy this requirement includes, for example, type of connection, connection origination, time stamps, outcome, user identities, and user identifiers. Additionally, an adversary must not be able to modify or delete session records.

Without the capability to generate session records, it is difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible. Session records are generated from several components within the Voice Video system (e.g., session manager, session border control, gateway, gatekeeper, or endpoints). Session record content that may be necessary to satisfy this requirement includes, for example, type of connection, connection origination, time stamps, outcome, user identities, and user identifiers. Additionally, an adversary must not be able to modify or delete session records.

It is critical for the appropriate personnel to be aware if a system is at risk of failing to process session records. Without this notification, the security personnel may be unaware of an impending failure of the session record capability. Session record processing failures include software/hardware errors, failures in the capturing mechanisms, and storage capacity being reached or exceeded. This requirement applies to each session record data storage repository (i.e., distinct information system component where session records are stored), the centralized session record storage capacity of organizations (i.e., all session record data storage repositories combined), or both.

Auditing and logging are key components of any security architecture. Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or to simply identify an improperly configured network element. Thus, it is imperative that the collected log data from the various network elements, as well as the auditing tools, be secured and can only be accessed by authorized personnel.

If session records were to become compromised, then forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. To ensure the veracity of session records, the information system and/or the application must protect session information from unauthorized modification. This requirement can be achieved through multiple methods, which will depend upon system architecture and design. Some commonly employed methods include ensuring log files receive the proper file system permissions and limiting log data locations.

If session records were to become compromised, then forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. To ensure the veracity of session records, the information system and/or the application must protect session information from unauthorized modification. This requirement can be achieved through multiple methods, which will depend upon system architecture and design. Some commonly employed methods include ensuring log files receive the proper file system permissions and limiting log data locations.

Without the capability to generate session records, it is difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible. Session records are generated from several components within the Voice Video system (e.g., session manager, session border control, gateway, gatekeeper, or endpoints). Session record content that may be necessary to satisfy this requirement includes, for example, type of connection, connection origination, time stamps, outcome, user identities, and user identifiers. Additionally, an adversary must not be able to modify or delete session records.

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). This requirement only applies to components where this is specific to the function of the device, such as application layer gateway (ALG), which provides these access control and auditing functions on behalf of an application. This does not apply to audit logs generated on behalf of the device itself (management).

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). This requirement only applies to components where this is specific to the function of the device, such as application layer gateway (ALG), which provides these access control and auditing functions on behalf of an application. This does not apply to audit logs generated on behalf of the device itself (management).

A certificate's certification path is the path from the end entity certificate to a trusted root certification authority (CA). Certification path validation is necessary for a relying party to make an informed decision regarding acceptance of an end entity certificate. Certification path validation includes checks such as certificate issuer trust, time validity, and revocation status for each certificate in the certification path. Revocation status information for CA and subject certificates in a certification path is commonly provided via certificate revocation lists (CRLs) or online certificate status protocol (OCSP) responses.

If passwords and PSKs are not encrypted when stored, they may be read if the storage location is compromised. Note that DOD requires the use two-factor, CAC-enabled authentication and the use of passwords incurs a permanent finding. Passwords should be used only in limited situations. Examples of situations where a user ID and password might be used include: - When the user does not use a CAC and is not a current DOD employee, member of the military, or DOD contractor. - When a user has been officially designated as temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) (i.e., Temporary Exception User) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied. - When the application is publicly available and/or hosting publicly releasable data requiring some degree of need-to-know protection. If the password is already encrypted and not a plaintext password, this meets this requirement. Implementation of this requirement requires configuration of FIPS-approved cipher block algorithm and block cipher modes for encryption. This method uses a one-way hashing encryption algorithm with a salt value to validate a user's password without having to store the actual password. Performance and time required to access are factors that must be considered, and the one-way hash is the most feasible means of securing the password and providing an acceptable measure of password security. Verify the user knows a password is performed using a password verifier. In its simplest form, a password verifier is a computational function that is capable of creating a hash of a password and determining if the value provided by the user matches the hash. A more secure version of verifying a user knowing a password is to store the result of an iterating hash function and a large random salt value as follows: H0 = H(pwd, H(salt)) Hn = H(Hn-1,H(salt)) In the above, "n" is a cryptographically strong random [*3] number. "Hn" is stored along with the salt. When the application wishes to verify that the user knows a password, it simply repeats the process and compares "Hn" with the stored "Hn". A salt is essentially a fixed-length cryptographically strong random value. Another method is using a keyed hash message authentication code (HMAC). HMAC calculates a message authentication code via a cryptographic hash function used in conjunction with an encryption key. The key must be protected as with any private key. This requirement applies to all accounts including authentication server; Authentication, Authorization, and Accounting (AAA), and local accounts, including the root account, and the account of last resort.

Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. Use of passwords for authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication. Although allowed by SP800-131Ar2 for some applications, SHA-1 is considered a compromised hashing standard and is being phased out of use by industry and government standards. Unless required for legacy use, DOD systems should not be configured to use SHA-2 for integrity of remote access sessions. The information system must specify the hash algorithm used for authenticating passwords. Implementation of this requirement requires configuration of FIPS-approved cipher block algorithm and block cipher modes for encryption. Pre-shared key cipher suites may only be used in networks where both the client and server belong to the same organization. Cipher suites using preshared keys must not be used with TLS 1.0 or 1.1 and must not be used with TLS 1.2 when a government client or server communicates with non-government systems. This requirement applies to all accounts, including authentication server, AAA, and local accounts such as the root account and the account of last resort. This requirement only applies to components where this is specific to the function of the device (e.g., Transport Layer Security [TLS] Virtual Private Network [VPN] or Application Layer Gateway [ALG]). This does not apply to authentication for the purpose of configuring the device itself (management).

Configuring the network element to implement organizationwide security implementation guides and security checklists ensures compliance with federal standards and establishes a common security baseline across DOD that reflects the most restrictive security posture consistent with operational requirements. Configuration settings are the set of parameters that can be changed that affect the security posture and/or functionality of the network element. Security-related parameters are those parameters impacting the security state of the network element, including the parameters required to satisfy other security control requirements. For the network element, security-related parameters include settings for network traffic management configurations.

It is detrimental for Unified Communications Session Managers to provide, or enable by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors. Unified Communications Session Managers are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions).

Without identifying devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. Typically, devices can be identified by MAC or IP address, but certificates provide a greater level of security. Identification of devices works with registration of devices as part of a defense in depth approach to Voice Video networks. Registration is the process of authorizing endpoints to communicate with the session manager. Registration occurs with the SIP server in VoIP systems and with a gatekeeper in H.323 systems. Without enforcing registration, an adversary could impersonate a legitimate device on the Voice Video network.

Terminating network connections associated with communications sessions includes, for example, de-allocating associated TCP/IP address/port pairs at the operating system level, and de-allocating networking assignments at the application level if multiple application sessions are using a single, operating system level network connection. Unified Communications Session Managers do not conduct media session; they conduct the session termination signaling. Endpoints and border elements conduct the media sessions and de-allocate those resources. However, sessions that do not receive a response from the far end may require the session manager to request termination of communication sessions.

If MLPP attributes are not associated with the information being transmitted between systems, then access control policies and information flows which depend on these MLPP attributes will not function and unauthorized access may result. Without the implementation of safeguards which allocate network communication resources based on priority, network availability, and particularly high priority traffic, may be dropped or delayed. DOD relies on the implementation of MLPP to ensure that flag officers and senior staff are provided higher priority for communications than other users. For VoIP and videoconferencing systems, Unified Communications Session Managers must communicate using protocols and services that provide expedited packets to users and other systems.

If MLPP attributes are not associated with the information being transmitted between components, then access control policies and information flows which depend on these MLPP attributes will not function and unauthorized access may result. When data is exchanged, the MLPP attributes associated with this data must be validated to ensure the data has not been changed. Without the implementation of safeguards which allocate network communication resources based on priority, network availability, and particularly high priority traffic, may be dropped or delayed. DOD relies on the implementation of MLPP to ensure that flag officers and senior staff are provided higher priority for communications than other users. For VoIP and videoconferencing systems, Unified Communications Session Managers must communicate using protocols and services that provide expedited packets to users and other systems.

Failure to a known safe state helps prevent systems from failing to a state that may cause loss of data or unauthorized access to system resources. Network elements that fail suddenly and with no incorporated failure state planning may leave the hosting system available but with a reduced security protection capability. Preserving information system state information also facilitates system restart and return to the operational mode of the organization with less disruption to mission-essential processes. An example is a firewall that blocks all traffic rather than allowing all traffic when a firewall component fails (e.g., fail closed and do not forward traffic). This prevents an attacker from forcing a failure of the system in order to obtain access. This applies to the configuration of the functionality of the element (e.g., firewall, IDPS, or router). Abort refers to stopping a program or function before it has finished naturally. The term abort refers to both requested and unexpected terminations.

Any Unified Communications Session Manager providing too much information in session records risks compromising the data and security of the application and system. The structure and content of session records must be carefully considered by the organization and development team.

Extension mobility is a feature of a VVoIP system that permits a person to transfer their phone number extension and phone features (or configuration) to a phone that is not in their normal workspace. This is useful when a person is visiting a remote office away from their normal office and typically functions within an established enterprise wide VVoIP system where the system is designed as a contiguous system. In this case, the system is typically a single vendor solution. The system might be within one LAN/CAN may include multiple LAN/CANs at multiple interconnected sites. To activate this feature, the user approaches a phone that is not their regular phone and identifies themselves to the phone system via a username, password, pin, code, or some combination of these. Upon validation, the system configuration manager will configure the temporary phone to match the configuration of the user's regular phone. Minimally, the phone number is transferred and possibly some or all of the user's speed dial numbers and other personal preferences. This capability is dependent upon the capabilities of the temporary phone. Once activated the user's inbound calls are directed to the temporary location. The user's regular phone may or may not maintain its normal capabilities and also may also answer inbound calls. Extension mobility is similar to but not the same as forwarding calls. Forwarding is typically activated from the user's normal phone or their user preferences configuration settings. Forwarding is therefore preset to a known location. Extension mobility is typically activated from the remote location and is activated upon arrival at that location. Extension mobility should be available only to those individuals that need to use the feature.

Extension mobility is a feature of a VVoIP system that permits a person to transfer their phone number extension and phone features (or configuration) to a phone that is not in their normal workspace. This is useful when a person is visiting a remote office away from their normal office and typically functions within an established enterprise wide VVoIP system where the system is designed as a contiguous system. In this case, the system is typically a single vendor solution. The system might be within one LAN/CAN may include multiple LAN/CANs at multiple interconnected sites. To activate this feature, the user approaches a phone that is not their regular phone and identifies themselves to the phone system via a username, password, pin, code, or some combination of these. Upon validation, the system configuration manager will configure the temporary phone to match the configuration of the user's regular phone. Minimally, the phone number is transferred and possibly some or all of the user's speed dial numbers and other personal preferences. This capability is dependent upon the capabilities of the temporary phone. Once activated the user's inbound calls are directed to the temporary location. The user's regular phone may or may not maintain its normal capabilities and also may also answer inbound calls. Extension mobility is similar to but not the same as forwarding calls. Forwarding is typically activated from the user's normal phone or their user preferences configuration settings. Forwarding is therefore preset to a known location. Extension mobility is typically activated from the remote location and is activated upon arrival at that location. Extension mobility should be available only to those individuals that need to use the feature.

In some cases a VVoIP endpoint will be configured with one or more URLs pointing to the locations of various servers with which they are associated such as their call controller. These URLs are translated to IP addresses by a DNS server. The use of URLs in this manner permits an endpoint to find the server it is looking for in the event the server’s IP address is changed. This also permits the endpoint to locate its assigned or home call controller from a remote location on a network that is not their home network. While all of this adds flexibility to the system and the endpoint’s location, it also exposes the endpoint and the home system to DNS vulnerabilities. Additionally, the home VVoIP system must expose critical IP address and domain information to the DNS system. If the DNS system is exposed to the DNS servers that support the enterprise data network or the internet, this information and exposure of the system is, or may be, extended to the world. This provides information that can be used to attack or compromise the VVoIP system. When using DNS within a VVoIP system so that endpoints can find various servers in the network, the DNS server should be dedicated to the VVoIP system. Furthermore, this DNS server should have limited or no interaction with the DNS server used by the data portion of the LAN/CAN or a publicly accessible DNS server. This will protect the VVoIP system’s DNS server from some of the vulnerabilities inherent in DNS servers that serve data endpoints and that are connected to the wider enterprise networks or the internet. While the use of DNS adds IP addressing flexibility to a VVoIP system, it is not necessary to use it for systems within the local LAN. VVoIP servers and infrastructure devices are required to be statically addressed. Therefore, the endpoints can be configured with these known IP addresses rather than URLs. A remote endpoint is required to connect to the home enclave via a VPN. It receives an internal LAN address and therefore becomes a part of the LAN and can directly reach its servers using their IP address. A URL is not required. The only time a URL might be required is in the event the endpoint is required to find a server such as a directory server that is somewhere on the WAN. This is the case in the VoSIP system on SIPRNet. Not using DNS in a VVoIP system eliminates its exposure to DNS vulnerabilities and attacks effected using information obtained from the DNS. NOTE: In the event a DNS server is implemented within the VVoIP system, the DNS STIG must be applied to the server.

Without the capability to generate session records, it is difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible. Session records are generated from several components within the Voice Video system (e.g., session manager, session border control, gateway, gatekeeper, or endpoints). Session record content that may be necessary to satisfy this requirement includes, for example, type of connection, connection origination, time stamps, outcome, user identities, and user identifiers. Additionally, an adversary must not be able to modify or delete session records.

Failure in a known state can address safety or security in accordance with the mission needs of the organization. Failure to a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. Preserving network element state information helps to facilitate network element restart and return to the operational mode of the organization with less disruption to mission-essential processes.

Without the ability to centrally manage the content captured in the audit records, identification, troubleshooting, and correlation of suspicious behavior would be difficult and could lead to a delayed or incomplete analysis of an ongoing attack. The content captured in audit records must be managed from a central location (necessitating automation). Centralized management of audit records and logs provides for efficiency in maintenance and management of records, as well as the backup and archiving of those records. Network components requiring centralized audit log management must have the capability to support centralized management. Session records for Voice Video systems are generally handled in a similar fashion to audit records for other systems and are used for billing, usage analysis, and record support for actions taken. These detailed records are typically produced by the session manager.

Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Off-loading is a common process in information systems with limited audit storage capacity. This requirement only applies to components where this is specific to the function of the device (e.g., IDPS sensor logs, firewall logs). This does not apply to audit logs generated on behalf of the device itself (management).

Attacks against a Unified Communications Session Manager may include DoS, replay attacks, or cross site scripting. A replay attack may enable an unauthorized user to gain access to the application. Authentication sessions between the authenticator and the application validating the user credentials must not be vulnerable to a replay attack. An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. Techniques used to address this include protocols using nonces (e.g., numbers generated for a specific one time use) or challenges (e.g., TLS, WS_Security). Additional techniques include time-synchronous or challenge-response one-time authenticators. A cross site scripting vulnerability was demonstrated on a SIP based IP phone by adding scripting code to the "From" field in the SIP invite. Upon receiving the invite, the embedded code was executed by the IP phone embedded web server to download additional malicious code.

Device registration is a solution enabling an organization to manage devices. It is an additional layer of authentication ensuring only specific preauthorized devices and trunks can access the system. Registration is the process of authorizing endpoints and trunks to communicate with the session manager. Registration occurs with the SIP server in VoIP systems and with a gatekeeper in H.323 systems. Without enforcing registration, an adversary could impersonate a legitimate device or peer on the Voice Video network.

Device registration is a solution enabling an organization to manage devices. It is an additional layer of authentication ensuring only specific preauthorized devices and trunks can access the system. Registration is the process of authorizing endpoints and trunks to communicate with the session manager. Registration occurs with the SIP server in VoIP systems and with a gatekeeper in H.323 systems. Without enforcing registration, an adversary could impersonate a legitimate device or peer on the Voice Video network.

Device registration is a solution enabling an organization to manage devices. It is an additional layer of authentication ensuring only specific preauthorized devices can access the system. Registration is the process of authorizing endpoints to communicate with the session manager. Registration occurs with the SIP server in VoIP systems and with a gatekeeper in H.323 systems. Without enforcing registration, an adversary could impersonate a legitimate device on the Voice Video network.

Device registration is a solution enabling an organization to manage devices. It is an additional layer of authentication ensuring only specific preauthorized devices can access the system. Registration is the process of authorizing endpoints to communicate with the session manager. Registration occurs with the SIP server in VoIP systems and with a gatekeeper in H.323 systems. Without enforcing registration, an adversary could impersonate a legitimate device on the Voice Video network.

Activity under unusual conditions can indicate hostile activity. For example, what is normal activity during operational hours can indicate hostile activity if it occurs during off hours. Depending on mission needs and conditions, usage restrictions based on conditions and circumstances may be critical to limit access to resources and data to comply with operational or mission access control requirements. Thus, the network element must be configured to enforce the specific conditions or circumstances under which application accounts can be used (e.g., by restricting usage to certain days of the week, time of day, or specific durations of time). Limiting access to the voice/video network by work hours and work week mitigates the risk of unauthorized access to the system outside of duty hours, reducing misuse or abuse of the system and its resources. Areas requiring service during other times may be identified. However, it is essential that endpoints be allowed access to emergency services at all times.

Without the enforcement of immediate change to privilege levels, users and devices may not provide the correct level of service. Privileges include access to outside connections, precedence, and preemption capabilities. A user with higher precedence and preemption capability may supplant users authorized higher levels of access. Endpoint users must be limited to the privileges needed to conduct business and changes to privileges must be enforced immediately. Access authorizations should be dynamic to reflect changing conditions; if a revocation is not enforced in a timely manner, users may have inappropriate access. Revocation of access rules may differ based on the types of access revoked. For example, if a subject (i.e., user or process) is removed from a group, access may not be revoked until the next time the object (e.g., file) is opened or until the next time the subject attempts a new access to the object. Revocation based on changes to security labels may take effect immediately. It may be necessary to immediately revoke access in certain circumstances (i.e., a compromised account is being used). This may be mitigated by implementing SRG-NET-000321-VVSM-00008.

Without the enforcement of immediate change to privilege levels, users and devices may not provide the correct level of service. Privileges include access to outside connections, precedence, and preemption capabilities. A user with higher precedence and preemption capability may supplant users authorized higher levels of access. Endpoints must be limited to the privileges needed to conduct business and changes to privileges must be enforced immediately. Access authorizations should be dynamic to reflect changing conditions; if a revocation is not enforced in a timely manner, users may have inappropriate access. Revocation of access rules may differ based on the types of access revoked. For example, if a subject (i.e., user or process) is removed from a group, access may not be revoked until the next time the object (e.g., file) is opened or until the next time the subject attempts a new access to the object. Revocation based on changes to security labels may take effect immediately. It may be necessary to immediately revoke access in certain circumstances (i.e., a compromised account is being used). This may be mitigated by implementing SRG-NET-000321-VVSM-00007.

By limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced. Limits are imposed by locking the account. This applies to network elements that have the concept of a user account (e.g., VPN, ALG, and proxy) as well as devices that can control traffic flow based on access authorizations (firewalls, IDPS).

When network elements do not dynamically reconfigure the data security attributes as data is created and combined, the possibility exists that security attributes will not correctly reflect the data with which they are associated. For the Unified Communications Session Manager, the use of 802.1q tags on media and signaling, and the use of VLANs provides this layer of security. VLANs facilitate access and traffic control for voice video system components and enhanced QoS. Virtualized networking is used to separate voice video traffic from other types of traffic, such as data, management, and other special types. VLANs provide segmentation at layer 2. Virtual Routing and Forwarding (VRF) provides segmentation at layer 3 and works with Multiprotocol Label Switching (MPLS) for enterprise and WAN environments. When VRF is used without MPLS, it is referred to as VRF lite. For Voice Video systems, subnets, VLANs, and VRFs are used to separate media and signaling streams from all other traffic.

When network elements do not dynamically reconfigure the data security attributes as data is created and combined, the possibility exist that security attributes will not correctly reflect the data with which they are associated. For the Unified Communications Session Manager, the use of 802.1q tags on media and signaling, and the use of VLANs provides this layer of security. VLANs facilitate access and traffic control for voice video system components and enhanced QoS. Virtualized networking is used to separate voice video traffic from other types of traffic, such as data, management, and other special types. VLANs provide segmentation at layer 2. Virtual Routing and Forwarding (VRF) provides segmentation at layer 3 and works with Multiprotocol Label Switching (MPLS) for enterprise and WAN environments. When VRF is used without MPLS, it is referred to as VRF lite. For Voice Video systems, subnets, VLANs, and VRFs are used to separate media and signaling streams from all other traffic.

If a user cannot explicitly end a session, the session may remain open and be exploited by an attacker; this is referred to as a zombie session. However, for some types of interactive sessions including, for example, remote login, information systems typically send logout messages as final messages prior to terminating sessions. This applies to network elements that have the concept of a user account and have the login function residing on the network element.

A network element experiencing a DoS attack will not be able to handle the traffic load. The high CPU utilization caused by a DoS attack will also have impact control keep-alives and timers used for neighbor peering, resulting in route flapping and eventually black hole traffic. The network element must be configured to prevent or mitigate the impact on network availability and traffic flow of DoS attacks that have occurred or are ongoing. A variety of technologies and functionality can be leveraged to limit or, in some cases, eliminate the effects of DoS attacks (e.g., load balancing and access control lists). Employing increased capacity and bandwidth, combined with service redundancy, may reduce the susceptibility to some DoS attacks. This requirement applies to the network traffic functionality of the network element as it pertains to handling network traffic. Some types of attacks may be specialized to certain network technology, functions, or services. For each technology, known and potential DoS attacks must be identified and solutions for each type implemented.

Without the implementation of safeguards which allocate network communication resources based on priority, network availability, and particularly high priority traffic, may be dropped or delayed. DOD supporting C2 communications relies on the implementation of MLPP to ensure that flag officers and senior staff are provided higher priority for communications than other users. For VoIP and videoconferencing systems, Unified Communications Session Managers must communicate using protocols and services that provide expedited packets to users and other systems. Additionally, Quality of Service (QoS) is an effective security safeguard used to ensure network communications availability based on priority. Different applications and other network traffic have unique requirements and toleration levels for delay, jitter, bandwidth, packet loss, and availability. To manage the multitude of applications and services, a network requires a QoS framework to differentiate traffic and provide a method to avoid and manage network congestion. When network congestion occurs, all traffic has an equal chance of being dropped. A QoS implementation categorizes network traffic into classes and provides priority treatment based on the classification.

Providing an explicit indication of current participants in videoconferences helps to prevent unauthorized individuals from participating in collaborative videoconference sessions without the explicit knowledge of other participants. videoconferences allow groups of users to collaborate and exchange information. Without knowing who is in attendance, information could be compromised. For videoconferences with large numbers of people present, the identified participant may be listed as the room rather than by each individual attending. Unified Communications Session Managers that provide a videoconference capability must provide a clear indication of who is attending the meeting, thus providing all attendees with the capability to clearly identify users who are in attendance.

If MLPP attributes are not associated with the information being transmitted between systems, then access control policies and information flows which depend on these MLPP attributes will not function and unauthorized access may result. Without the implementation of safeguards which allocate network communication resources based on priority, network availability, and particularly high priority traffic, may be dropped or delayed. DOD relies on the implementation of MLPP to ensure that flag officers and senior staff are provided higher priority for communications than other users. For VoIP and videoconferencing systems, Unified Communications Session Managers must communicate using protocols and services that provide expedited packets to users and other systems.

Untrusted certificate authorities (CA) can issue certificates, but they may be issued by organizations or individuals that seek to compromise DOD systems or by organizations with insufficient security controls. If the CA used for verifying the certificate is not a DOD-approved CA, trust of this CA has not been established. The DOD will only accept PKI certificates obtained from a DOD-approved internal or external certificate authority. Reliance on CAs for the establishment of secure sessions includes, for example, the use of TLS certificates. This requirement focuses on communications protection for the application session rather than for the network packet. This requirement applies to any network element that is an intermediary of individual sessions (e.g., proxy, ALG, or TLS VPN). Network elements that perform these functions must be able to identify which session identifiers were generated when the sessions were established.