Skip to main content
NetStable
Level 2 SC.L2-3.13.14

Control and monitor the use of VoIP technologies

📖 What This Means

This control requires organizations to actively manage and oversee Voice over Internet Protocol (VoIP) systems to ensure they are used securely. VoIP technologies, which allow voice calls over the internet, can be vulnerable to eavesdropping, call hijacking, or malware if not properly secured. The practice means implementing measures like encryption, access controls, and monitoring to protect sensitive conversations, especially those involving Controlled Unclassified Information (CUI). For example, a defense contractor using VoIP for daily team calls must ensure calls are encrypted and only authorized personnel can join. Another example: monitoring VoIP traffic for unusual patterns that might indicate a cyberattack.

🎯 Why It Matters

Unsecured VoIP systems can expose sensitive conversations to interception, leading to data breaches or espionage. In 2020, a VoIP-based attack compromised a defense supplier's network, leaking discussions about contract bids. The average cost of a VoIP-related breach is $200,000+ in remediation and reputational damage. The DoD requires this control because VoIP is often used for mission-critical communications containing CUI. Without proper controls, adversaries can exploit VoIP vulnerabilities to gain intelligence or disrupt operations. CMMC emphasizes this to protect the DoD supply chain's communications integrity.

How to Implement

  1. 1. Enable end-to-end encryption for VoIP services (e.g., Microsoft Teams, Zoom for Government) using TLS/SRTP.
  2. 2. Configure identity-based access controls in your cloud VoIP solution (e.g., Azure AD integration for Teams).
  3. 3. Deploy cloud-native monitoring tools (e.g., AWS CloudTrail for call logs, Azure Sentinel for anomalies).
  4. 4. Segment VoIP traffic in a dedicated VPC/VNet separate from other data.
  5. 5. Regularly audit VoIP user permissions and disable unused accounts.
⏱️
Estimated Effort
2-3 days for initial setup (mid-level network admin), 1-2 hours/week for ongoing monitoring.

📋 Evidence Examples

VoIP Security Policy

Format: PDF/DOCX
Frequency: Annual review or after major changes.
Contents: Encryption standards, access control rules, monitoring procedures.
Collection: Export from document management system.

SIP/TLS Configuration Screenshot

Format: PNG/JPEG
Frequency: After configuration changes.
Contents: Enabled encryption settings from PBX/SBC admin console.
Collection: Screenshot with timestamp.

Call Detail Records (CDRs)

Format: CSV/Log
Frequency: Monthly.
Contents: Call timestamps, parties, duration, IP addresses.
Collection: Export from VoIP system monthly.

VoIP Penetration Test Report

Format: PDF
Frequency: Annual.
Contents: Results of SIP vulnerability scanning (e.g., using SIPVicious).
Collection: Third-party or internal test.

VoIP User Access Review

Format: Spreadsheet
Frequency: Quarterly.
Contents: List of authorized users with justification for access.
Collection: HR/VoIP admin collaboration.

📝 SSP Guidance

Use this guidance when writing the System Security Plan (SSP) narrative for this control.

How to Write the SSP Narrative

For SC.L2-3.13.14 ("Control and monitor the use of VoIP technologies"), your SSP narrative should specifically describe: (1) the tools and technologies you use to implement this control, (2) the configuration or process that enforces it, (3) who is responsible for maintaining it, and (4) what evidence proves it's working. Describe your network security architecture, including segmentation, encryption standards, VPN configuration, session management, key management, and monitoring capabilities. Be specific -- name your actual products, settings, and responsible personnel.

Example SSP Narratives

Cloud (Azure/AWS)

"SC.L2-3.13.14 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to control and monitor the use of voip technologies. The configuration is managed through [Azure Policy/AWS Config/Terraform] and monitored via [SIEM tool]. Responsible party: [IT Security Manager]. Evidence: [specific artifact, e.g., 'Azure AD Conditional Access policy screenshot, CloudTrail logs']."

On-Premise

"SC.L2-3.13.14 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to control and monitor the use of voip technologies. Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."

Hybrid

"SC.L2-3.13.14 is implemented across both cloud and on-premise environments. [Organization] uses [Azure AD Connect/hybrid tool] to ensure consistent enforcement. Cloud resources are managed via [cloud tool] and on-premise systems via [on-prem tool]. Both environments report to [centralized SIEM]. Responsible party: [IT Director]. Evidence: [artifacts from both environments]."

System Boundary Considerations

  • Document network architecture with CUI boundary clearly marked
  • Identify all encryption mechanisms (at rest and in transit)
  • Specify network monitoring and IDS/IPS deployment
  • Ensure this control covers all systems within your defined CUI boundary where control and monitor the use of voip technologies applies
  • Document any systems where this control is not applicable and explain why

Key Documentation to Reference in SSP

  • 📄 System and Communications Protection Policy
  • 📄 Network architecture diagram
  • 📄 Firewall rule documentation
  • 📄 Encryption configuration documentation
  • 📄 Evidence artifacts specific to SC.L2-3.13.14
  • 📄 POA&M entry if control is not fully implemented

What the Assessor Looks For

The assessor will review network diagrams for proper segmentation, test encryption settings, verify VPN split tunneling is disabled, and check FIPS 140-2 validation of cryptographic modules.

💬 Self-Assessment Questions

Use these questions to assess your compliance. Each "NO" answer provides specific remediation guidance.

Question 1: Is all VoIP traffic encrypted in transit (TLS/SRTP)?

✅ YES → Proceed to Q2.
❌ NO → GAP: Enable TLS/SRTP on PBX/SBC within 14 days. Reference NIST SP 800-52 for guidance.
Remediation:
Configure encryption per vendor documentation.

Question 2: Are VoIP systems segregated from general data networks (VLAN/VPC)?

✅ YES → Proceed to Q3.
❌ NO → GAP: Network segmentation required within 30 days. Create a VoIP-specific VLAN.
Remediation:
Work with network team to implement VLAN tagging.

Question 3: Are call logs (CDRs) retained for at least 90 days?

✅ YES → Proceed to Q4.
❌ NO → GAP: Configure logging retention in VoIP system within 7 days.
Remediation:
Set log rotation policies in PBX/SBC settings.

Question 4: Is there a process to review and remove unused VoIP accounts?

✅ YES → Proceed to Q5.
❌ NO → GAP: Implement quarterly access reviews starting next month.
Remediation:
Create a procedure tying VoIP access to HR onboarding/offboarding.

Question 5: Have VoIP systems been tested for SIP vulnerabilities in the last year?

✅ YES → COMPLIANT.
❌ NO → GAP: Schedule a penetration test within 60 days.
Remediation:
Use SIPVicious or hire a third-party tester.

⚠️ Common Mistakes (What Auditors Flag)

1. Using default SIP credentials on VoIP devices.

Why this happens: Vendors ship devices with admin/admin credentials.
How to avoid: Change defaults immediately after deployment; enforce strong passwords.

2. Missing encryption for VoIP traffic.

Why this happens: Encryption is often disabled by default for compatibility.
How to avoid: Explicitly enable TLS/SRTP and disable plain SIP/RTP.

3. No monitoring for unusual call patterns (e.g., international calls).

Why this happens: Focus on functionality over security monitoring.
How to avoid: Configure alerts for abnormal call volumes/destinations in SIEM.

4. VoIP phones with outdated firmware.

Why this happens: Lack of patch management for VoIP devices.
How to avoid: Monthly firmware checks; subscribe to vendor security bulletins.

5. Incomplete documentation of VoIP security controls.

Why this happens: Assuming VoIP is 'just another network service'.
How to avoid: Include VoIP-specific sections in network security policies.

📚 Parent Policy

This practice is governed by the System and Communications Protection Policy

View SC Policy →

📚 Related Controls