Protecting voice communications that carry Controlled Unclassified Information (CUI) is a required part of NIST SP 800‑171 Rev.2 / CMMC 2.0 Level 2 compliance for many DoD contractors and organizations handling CUI—Control SC.L2‑3.13.14 expects cryptographic protection for information in transit and logging to provide auditable evidence; this post shows how to implement SRTP/TLS for VoIP and a logging approach that meets compliance and practical operations needs for small businesses.
\n\nSC.L2‑3.13.14 mandates use of cryptographic mechanisms to protect the confidentiality and integrity of non‑public information in transit and to generate evidence of protection and system behavior. For VoIP this specifically means: encrypt signaling (SIP) with TLS, encrypt media (RTP) with SRTP (preferably negotiated using DTLS or ZRTP rather than insecure key exchange), and log appropriate metadata and events that demonstrate encryption was in place and functioning.
\n\nStep 1 — inventory and architecture: enumerate all SIP endpoints (phones, softphones), PBX/gateways, SIP trunks, SBCs (Session Border Controllers), and cloud VoIP providers. Identify which devices support SRTP and TLS, and which require firmware/firmware upgrades or replacement. For a 20–100 person small business this often means upgrading older SIP phones or configuring softphones (e.g., Linphone, Zoiper) and ensuring your PBX (Asterisk, FreePBX, 3CX) or SBC supports TLS 1.2+ and DTLS‑SRTP.
\n\nStep 2 — signaling: enable SIP over TLS on your PBX/SBC and enforce it on trunks and endpoints. Use port 5061 for SIP/TLS. Configure your PBX certificate using a trustworthy CA (public or internal PKI) with subjectAltName entries for the SIP host names, and enable strong TLS settings (minimum TLS 1.2; TLS 1.3 preferred). Example OpenSSL test command to validate TLS on a SIP host: openssl s_client -connect sip.example.com:5061 -tls1_2 -servername sip.example.com
\n\nOn Asterisk (chan_pjsip) you would:
\n\n\n; pjsip.conf (excerpt)\n[transport-tls]\ntype=transport\nprotocol=tls\nbind=0.0.0.0\n\n[my-phone]\ntype=endpoint\ntransport=transport-tls\ncontext=from-internal\nmedia_encryption=dtls\ndtls_verify=fingerprint\ndtls_cert_file=/etc/asterisk/keys/asterisk.pem\nrtp_symmetric=yes\nforce_rport=yes\ndirect_media=no\n\n\n
Step 3 — media encryption: prefer DTLS‑SRTP (RFC 5764) or ZRTP for keying; avoid plain SDES unless you can ensure SDP is only exchanged over TLS and within a fully trusted boundary. Configure SRTP to use AEAD ciphers (AES‑GCM) where supported (e.g., AEAD_AES_128_GCM, AEAD_AES_256_GCM). If only AES_CM/HMAC_SHA1 is available, document compensating controls and schedule upgrades because SHA‑1 based HMAC is weak for long‑term security.
\n\nUse an organizational PKI or well‑managed public CA for server certificates; ensure private keys on gateways/PBXs are protected with file system ACLs, hardware security modules (HSM) or TPM where possible. Implement certificate lifecycle processes: automated renewal (ACME where supported), monitoring for expirations, and alerts for certificate errors. For SRTP keying with DTLS, ensure the DTLS keypair is rotated with certificate rotation practices and that ephemeral keys provide Perfect Forward Secrecy (PFS) wherever supported (DTLS/TLS cipher suites that provide ECDHE).
\n\nDesign logs to show that TLS and SRTP were negotiated and in use, without storing audio (which is rarely required and introduces high risk). Required log types for audit evidence include: SIP/TLS handshake success/failure, SRTP negotiation events (DTLS handshake success/failure), certificate validation errors, endpoint configuration changes, and session metadata: caller/callee IDs, call start/stop times, call duration, media codec, and SRTP cipher used. Forward these logs to a central log server / SIEM over TLS (syslog‑tls) and protect logs at rest (AES‑256 encryption, role‑based access).
\n\nSmall businesses should define retention aligned to contract and policy — common choices are 1–3 years for metadata. Store logs in a tamper‑evident manner (write‑once storage, WORM buckets or append‑only SIEM indices) and use structured JSON logs where possible so evidence is easy to extract for assessment. Create a standard evidence package for assessors: configuration snippets, cert chain outputs, SIEM search results showing SRTP/TLS negotiates, and periodic test call captures that prove encryption in production.
\n\nExample: a 40-person engineering firm under a DoD subcontract runs a cloud PBX and a small on‑prem SBC for PSTN. Implementation steps they took: (1) forced SIP/TLS on trunk and endpoints, (2) enabled DTLS‑SRTP on the SBC and issued a SAN certificate from the internal CA for the SBC, (3) configured softphones to require SRTP and reject fallback to RTP, (4) forwarded SIP and DTLS logs to the company Splunk instance over TLS and built a dashboard for failed handshakes and expired certs, and (5) kept 18 months of metadata logs in immutably‑configured cloud storage for audit. That setup stopped PSTN eavesdropping attempts and provided assessors with clear evidence of encryption and event logging.
\n\nFailing to encrypt VoIP and maintain logs risks exposure of CUI (voice calls can contain technical data and contractual info), lead to compromise via SIP/VoIP interception, and result in compliance failures during CMMC/NIST assessments. Operationally, lack of logging makes incident detection slow — a breached SIP trunk or an unencrypted call can go unnoticed. Contract penalties, lost business, and reputational damage are realistic outcomes for organizations that leave voice channels unprotected.
\n\nSummary: implement SIP/TLS for signaling, DTLS‑SRTP (or equivalent secure SRTP keying) for media, enforce strong cipher suites (TLS 1.2+/1.3, AES‑GCM SRTP), maintain robust certificate and key management, and centralize encrypted logs (SIP/DTLS/SRTP events and call metadata) with defined retention and tamper‑evidence. For small businesses, priorities are inventory, firmware/capability upgrades, PBX/SBC configuration, SIEM log collection, and producing a clear evidence package to demonstrate compliance with SC.L2‑3.13.14.
", "plain_text": "Protecting voice communications that carry Controlled Unclassified Information (CUI) is a required part of NIST SP 800‑171 Rev.2 / CMMC 2.0 Level 2 compliance for many DoD contractors and organizations handling CUI—Control SC.L2‑3.13.14 expects cryptographic protection for information in transit and logging to provide auditable evidence; this post shows how to implement SRTP/TLS for VoIP and a logging approach that meets compliance and practical operations needs for small businesses.\n\nWhat SC.L2‑3.13.14 requires and how it maps to VoIP\n\nSC.L2‑3.13.14 mandates use of cryptographic mechanisms to protect the confidentiality and integrity of non‑public information in transit and to generate evidence of protection and system behavior. For VoIP this specifically means: encrypt signaling (SIP) with TLS, encrypt media (RTP) with SRTP (preferably negotiated using DTLS or ZRTP rather than insecure key exchange), and log appropriate metadata and events that demonstrate encryption was in place and functioning.\n\nPractical implementation steps (small business workflow)\n\nStep 1 — inventory and architecture: enumerate all SIP endpoints (phones, softphones), PBX/gateways, SIP trunks, SBCs (Session Border Controllers), and cloud VoIP providers. Identify which devices support SRTP and TLS, and which require firmware/firmware upgrades or replacement. For a 20–100 person small business this often means upgrading older SIP phones or configuring softphones (e.g., Linphone, Zoiper) and ensuring your PBX (Asterisk, FreePBX, 3CX) or SBC supports TLS 1.2+ and DTLS‑SRTP.\n\nStep 2 — signaling: enable SIP over TLS on your PBX/SBC and enforce it on trunks and endpoints. Use port 5061 for SIP/TLS. Configure your PBX certificate using a trustworthy CA (public or internal PKI) with subjectAltName entries for the SIP host names, and enable strong TLS settings (minimum TLS 1.2; TLS 1.3 preferred). Example OpenSSL test command to validate TLS on a SIP host: openssl s_client -connect sip.example.com:5061 -tls1_2 -servername sip.example.com\n\nExample Asterisk SIP/TLS + SRTP snippet\n\nOn Asterisk (chan_pjsip) you would:\n\n\n; pjsip.conf (excerpt)\n[transport-tls]\ntype=transport\nprotocol=tls\nbind=0.0.0.0\n\n[my-phone]\ntype=endpoint\ntransport=transport-tls\ncontext=from-internal\nmedia_encryption=dtls\ndtls_verify=fingerprint\ndtls_cert_file=/etc/asterisk/keys/asterisk.pem\nrtp_symmetric=yes\nforce_rport=yes\ndirect_media=no\n\n\nStep 3 — media encryption: prefer DTLS‑SRTP (RFC 5764) or ZRTP for keying; avoid plain SDES unless you can ensure SDP is only exchanged over TLS and within a fully trusted boundary. Configure SRTP to use AEAD ciphers (AES‑GCM) where supported (e.g., AEAD_AES_128_GCM, AEAD_AES_256_GCM). If only AES_CM/HMAC_SHA1 is available, document compensating controls and schedule upgrades because SHA‑1 based HMAC is weak for long‑term security.\n\nKey/certificate management and key security\n\nUse an organizational PKI or well‑managed public CA for server certificates; ensure private keys on gateways/PBXs are protected with file system ACLs, hardware security modules (HSM) or TPM where possible. Implement certificate lifecycle processes: automated renewal (ACME where supported), monitoring for expirations, and alerts for certificate errors. For SRTP keying with DTLS, ensure the DTLS keypair is rotated with certificate rotation practices and that ephemeral keys provide Perfect Forward Secrecy (PFS) wherever supported (DTLS/TLS cipher suites that provide ECDHE).\n\nLogging and evidence collection for compliance\n\nDesign logs to show that TLS and SRTP were negotiated and in use, without storing audio (which is rarely required and introduces high risk). Required log types for audit evidence include: SIP/TLS handshake success/failure, SRTP negotiation events (DTLS handshake success/failure), certificate validation errors, endpoint configuration changes, and session metadata: caller/callee IDs, call start/stop times, call duration, media codec, and SRTP cipher used. Forward these logs to a central log server / SIEM over TLS (syslog‑tls) and protect logs at rest (AES‑256 encryption, role‑based access).\n\nRetention and log format guidance\n\nSmall businesses should define retention aligned to contract and policy — common choices are 1–3 years for metadata. Store logs in a tamper‑evident manner (write‑once storage, WORM buckets or append‑only SIEM indices) and use structured JSON logs where possible so evidence is easy to extract for assessment. Create a standard evidence package for assessors: configuration snippets, cert chain outputs, SIEM search results showing SRTP/TLS negotiates, and periodic test call captures that prove encryption in production.\n\nReal‑world example scenario\n\nExample: a 40-person engineering firm under a DoD subcontract runs a cloud PBX and a small on‑prem SBC for PSTN. Implementation steps they took: (1) forced SIP/TLS on trunk and endpoints, (2) enabled DTLS‑SRTP on the SBC and issued a SAN certificate from the internal CA for the SBC, (3) configured softphones to require SRTP and reject fallback to RTP, (4) forwarded SIP and DTLS logs to the company Splunk instance over TLS and built a dashboard for failed handshakes and expired certs, and (5) kept 18 months of metadata logs in immutably‑configured cloud storage for audit. That setup stopped PSTN eavesdropping attempts and provided assessors with clear evidence of encryption and event logging.\n\nRisks and consequences of not implementing\n\nFailing to encrypt VoIP and maintain logs risks exposure of CUI (voice calls can contain technical data and contractual info), lead to compromise via SIP/VoIP interception, and result in compliance failures during CMMC/NIST assessments. Operationally, lack of logging makes incident detection slow — a breached SIP trunk or an unencrypted call can go unnoticed. Contract penalties, lost business, and reputational damage are realistic outcomes for organizations that leave voice channels unprotected.\n\nSummary: implement SIP/TLS for signaling, DTLS‑SRTP (or equivalent secure SRTP keying) for media, enforce strong cipher suites (TLS 1.2+/1.3, AES‑GCM SRTP), maintain robust certificate and key management, and centralize encrypted logs (SIP/DTLS/SRTP events and call metadata) with defined retention and tamper‑evidence. For small businesses, priorities are inventory, firmware/capability upgrades, PBX/SBC configuration, SIEM log collection, and producing a clear evidence package to demonstrate compliance with SC.L2‑3.13.14." }, "metadata": { "description": "Practical step‑by‑step guidance to secure VoIP (SIP/RTP) with SRTP and TLS and implement compliant logging to meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 Control SC.L2-3.13.14.", "permalink": "/how-to-configure-secure-voip-encryption-srtptls-and-logging-for-nist-sp-800-171-rev2-cmmc-20-level-2-control-scl2-31314.json", "categories": [], "tags": [] } }