Skip to content
Catalogs
XCCDF
Enterprise Voice, Video, and Messaging Policy Security Requirements Guide
SRG-VOIP-000260
When soft-phones are implemented as the primary voice endpoint in the user's workspace, a policy must be defined to supplement with physical hardware-based phones near all such workspaces.
When soft-phones are implemented as the primary voice endpoint in the user's workspace, a policy must be defined to supplement with physical hardware-based phones near all such workspaces. An XCCDF Rule
When soft-phones are implemented as the primary voice endpoint in the user's workspace, a policy must be defined to supplement with physical hardware-based phones near all such workspaces.
Medium Severity
<VulnDiscussion>This and several other requirements discuss the implementation of PC soft-phones or UC applications as the primary and only communications device in the user's workspace.
While this degrades the protections afforded a hardware-based system, the trend is to use more and more PC-based communications applications due to their advanced features, collaborative benefits, and perceived reduced cost. This soft-phone use case results in the elimination of hardware-based telephones on users' desks in the workplace. This can be seen as, or result in, trading down (from a hardware-based system) with regard to availability, reliability, and quality of service because the data network is generally more susceptible to compromise from many sources inside and outside the local LAN, making the soft-phones more exposed to attack.
This also means no telephone will be available in the workspace if the PC is not powered on, the application is not loaded, or the PC is not fully functional. While this is undesirable from an IA standpoint, a business case can be developed to support it.
NOTE: The recommended relationship between PC soft-phone/UC applications and hardware-based endpoints in the normal work area is that the PC application should augment the functionality of, or be a backup to, the hardware-based instrument in the user's workspace. The implementation of PC soft-phones or UC applications in the user workspace as their only endpoint has several ramifications that must be considered. These include:
- The PC becomes a single point of failure for communications services provided to a user in their workspace. A widespread problem, which affects many PCs or the network infrastructure, may disable all communications for many users at one time. Users may not have a means to report the failure without using an alternate communications system. A fast-spreading worm or power outage could create such a situation. While some may argue that "users can call on their cell phones", service may not be available, or their use may not be permitted in the facility. This translates into the loss of functionality and efficiency, as in lost time, due to the inability to communicate when the PC or soft-phone application is not running or functioning properly.
- The protections afforded hardware-based endpoints by the use of the voice protection zone, such as VoIP VLAN(s) and others, are missing for soft-phones in a widespread use/implementation scenario and, depending on the implementation on the PC, may degrade the protections afforded hardware-based endpoints. Such is the case for all software-based communications endpoints because they are typically implemented on all PCs and therefore will be connected to the data VLANs. Assured service for voice traffic will be degraded from that obtained with hardware-based instruments connected in the voice protection zone. This translates into the following additional IA measures required to protect the VoIP infrastructure (e.g., a firewall between the VoIP and data VLANs):
- The hardware-based endpoint is not available for use in parallel with, or in place of, the PC. This can be a problem if the PC is having performance or operational issues, is turned off, or is unavailable. Accessing help desk services requiring logging on to the PC to use the voice services and work on a problem could be a real challenge. Rebooting the PC to clear a problem would disconnect the call to the helpdesk. Accessing voice mail or answering the phone while the PC is booting is made impossible, reducing efficiency, particularly when the user starts their day. If the user has command and control (C2) responsibilities, the IP equivalent of MLPP cannot function properly if an application or PC is unavailable. Precedence calls will not be received by the user but will be transferred to their designated alternate answering point.
- Emergency communications could be unavailable if the PC is not booted, the communications application is not running, or either is otherwise compromised. Voice communications must be readily available for life safety and medical reasons, as well as other facility security emergencies. A partial mitigation for this in a "soft-phone world" is to place common use hardware telephones within a short distance (e.g., 30 to 50 feet) of every workspace, which is an additional cost. This additional distance, however, could be an issue in a medical emergency where a worker might be alone in their workspace and their PC or voice communications application is not functioning properly. They may not be able to reach the common use instrument depending on the nature of the medical emergency. If the worker was suffering a heart attack or diabetic emergency, they could die. Business cases therefore need to include the cost of insurance and/or lawsuits for this eventuality.
The previous two items translate into the following the addition of common-use hardware-based instruments placed around the facility (for backup and emergency use) along with the additionally required LAN cabling and access switch ports. While some may believe this is not an IA issue, it is because the discussion is about availability, which is one of the prime tenets of IA.
Additionally, the VoIP controllers (i.e., the equipment that controls the telephone system) must be able to be accessed by the PC soft-phones while being protected as they would be in a normal VoIP system using hardware-based instruments.
NOTE: Methods for permitting the necessary PC traffic to, from, and between the voice and data zones while protecting the voice zone will be discussed later in this document.</VulnDiscussion><FalsePositives></FalsePositives><FalseNegatives></FalseNegatives><Documentable>false</Documentable><Mitigations></Mitigations><SeverityOverrideGuidance></SeverityOverrideGuidance><PotentialImpacts></PotentialImpacts><ThirdPartyTools></ThirdPartyTools><MitigationControl></MitigationControl><Responsibility></Responsibility><IAControls></IAControls>