Back

Establish trusted paths to transmit restricted data or restricted information over public networks or wireless networks.


CONTROL ID
00568
CONTROL TYPE
Technical Security
CLASSIFICATION
Preventive

SUPPORTING AND SUPPORTED CONTROLS



This Control directly supports the implied Control(s):
  • Use strong data encryption to transmit in scope data or in scope information, as necessary., CC ID: 00564

There are no implementation support Controls.


SELECTED AUTHORITY DOCUMENTS COMPLIED WITH



  • When personal data is being transmitted, the organization should establish a secure environment by checking for unauthorized connected devices and using dedicated optical fiber cables. (T29.1, FISC Security Guidelines on Computer Systems for Banking and Related Financial Institutions, 7th Edition)
  • Particularly in the case when personal data are transmitted, encryption, password setting, and other proper precautions should be taken to protect data contents from being read out even if data are intercepted through wiretapping. (P4.1. ¶ 2, FISC Security Guidelines on Computer Systems for Financial Institutions, Ninth Edition, Revised March 2020)
  • It is necessary to specify the methods for transmission/receipt, storing and managing data files according to their importance. (P28.1. ¶ 1, FISC Security Guidelines on Computer Systems for Financial Institutions, Ninth Edition, Revised March 2020)
  • When financial institutions register templates in computers, it is necessary to define proper procedures for the secure transfer and transmission of templates from the location of creation to the saving location. (Example: Use of encryption, etc.) (P140.1.(2) 1)b., FISC Security Guidelines on Computer Systems for Financial Institutions, Ninth Edition, Revised March 2020)
  • It is necessary to implement security measures for data transmissions. It is recommended that lines separate from the main convenience store lines be used. (P129.2. ¶ 1, FISC Security Guidelines on Computer Systems for Financial Institutions, Ninth Edition, Revised March 2020)
  • For the purpose of exchanging confidential information between the FI and its external parties, the FI should take utmost care to preserve the confidentiality of all confidential information. For this purpose, the FI should at all times take appropriate measures including sending information through… (§ 9.1.5, Monetary Authority of Singapore: Technology Risk Management Guidelines)
  • The FI should not use unsafe internet services such as social media sites, cloud-based internet storage sites, and web-based emails to communicate or store confidential information. The FI should implement measures to prevent and detect the use of such services within the FI. (§ 9.1.4, Monetary Authority of Singapore: Technology Risk Management Guidelines)
  • Where sensitive cryptographic keys need to be transmitted, the FI should ensure these keys are not exposed during transmission. The keys should be distributed to the intended recipient via an out-of-band channel or other secure means to minimise the risk of interception. (§ 10.2.5, Technology Risk Management Guidelines, January 2021)
  • Apply secure connection technologies or protocols, such as TLS, to websites and web applications that handle personal data. (Annex A2: Websites and Web Application Security 29, Singapore(PDPC) Guide to Securing Personal Data in Electronic Medium, Revised 20 January 2017)
  • Trusted sources are limited to people and systems that have been authorised as such by an organisation's CISO. (Security Control: 0665; Revision: 5, Australian Government Information Security Manual, March 2021)
  • In addition to any encryption already in place, an AACP is used to protect AUSTEO and AGAO information when communicated across network infrastructure. (Security Control: 0469; Revision: 3, Australian Government Information Security Manual, March 2021)
  • using a VPN connection to encrypt all mobile device communications (Control: ISM-1299; Revision: 3; Bullet 7, Australian Government Information Security Manual, June 2023)
  • using encrypted messaging apps for communications instead of using foreign telecommunication networks (Control: ISM-1299; Revision: 3; Bullet 8, Australian Government Information Security Manual, June 2023)
  • consider using a VPN connection to encrypt all cellular and wireless communications (Control: ISM-1299; Revision: 4; Bullet 12, Australian Government Information Security Manual, September 2023)
  • consider using encrypted email or messaging apps for all communications. (Control: ISM-1299; Revision: 4; Bullet 13, Australian Government Information Security Manual, September 2023)
  • e-mail that is to be sent via the centralized e-mail gateway from users outside the network must use an authenticated and encrypted channel. (Control: 0571, Australian Government Information Security Manual: Controls)
  • The organization must ensure system authentication data is protected while it is transiting over the networks. (Control: 0419, Australian Government Information Security Manual: Controls)
  • Counter mode with Cipher Block Chaining Message Authentication Code protocol must be used for protecting the integrity and confidentiality of all wireless network traffic. (Control: 1332, Australian Government Information Security Manual: Controls)
  • Member States shall ensure that each CSIRT has at its disposal an appropriate, secure, and resilient communication and information infrastructure through which to exchange information with essential and important entities and other relevant stakeholders. To that end, Member States shall ensure that … (Article 10 3., DIRECTIVE (EU) 2022/2555 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 14 December 2022 on measures for a high common level of cybersecurity across the Union, amending Regulation (EU) No 910/2014 and Directive (EU) 2018/1972, and repealing Directive (EU) 2016/1148 (NIS 2 Directive))
  • Measures for the protection of transferred contents against unauthorized access are implemented. (5.1.2 Requirements (must) Bullet 3, Information Security Assessment, Version 5.1)
  • (§ 4.2, OGC ITIL: Security Management)
  • Service providers need to ensure that all management requests which could have a security impact are performed over secure and authenticated channels. If users are not strongly authenticated then an imposter may be able to successfully perform privileged actions, undermining the security of the serv… (9.1 ¶ 3, Cloud Security Guidance, 1.0)
  • Exchange sensitive transaction data only over a trusted path or medium with controls to provide authenticity of content, proof of submission, proof of receipt and non-repudiation of origin. (DS5.11 Exchange of Sensitive Data, CobiT, Version 4.1)
  • Verify that inbound and outbound traffic is limited to that which is necessary for the cardholder data environment, and that the restrictions are documented. (§ 1.2.1.a, Payment Card Industry (PCI) Data Security Standard Self-Assessment Questionnaire C and Attestation of Compliance Payment Application Connected to Internet, No Electronic Cardholder Data Storage, Version 2.0)
  • Verify that inbound Internet traffic and outbound network traffic is limited to that which is necessary for the cardholder data environment, and that the restrictions are documented. (§ 1.2.1.a, Payment Card Industry (PCI) Data Security Standard Self-Assessment Questionnaire D and Attestation of Compliance All other Merchants and all SAQ-Eligible Service Providers, Version 2.0)
  • Identify all locations where cardholder data is transmitted over open, public networks and examine the configurations to verify each location is using strong cryptography and security protocols for the transmissions. (Testing Procedures § 4.1.a, Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures - Testing Procedures, 3)
  • Verify that inbound and outbound traffic is limited to that which is necessary for the cardholder data environment, and that the restrictions are documented. (§ 1.2.1.a Testing Procedures, Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, 2.0)
  • Strong cryptography and security protocols that only accept trusted keys and certificates must be used to safeguard sensitive cardholder data during transmission over open, public networks. (PCI DSS Requirements § 4.1 Bullet 1, Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, 3.0)
  • Security protocols that only support secure versions or configurations must be used to safeguard sensitive cardholder data during transmission over open, public networks. (PCI DSS Requirements § 4.1 Bullet 2, Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, 3.0)
  • Wireless networks that transmit cardholder data or connected to the cardholder data environment must use industry best practices for implementing strong encryption. (PCI DSS Requirements § 4.1.1, Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, 3.0)
  • For TLS implementations, is TLS enabled whenever cardholder data is transmitted or received? (4.1(e), Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire A-EP and Attestation of Compliance, Version 3.2)
  • For TLS implementations, is TLS enabled whenever cardholder data is transmitted or received? (4.1(e), Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire B-IP and Attestation of Compliance, Version 3.2)
  • For TLS implementations, is TLS enabled whenever cardholder data is transmitted or received? (4.1 (e), Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire C and Attestation of Compliance, Version 3.1)
  • For TLS implementations, is TLS enabled whenever cardholder data is transmitted or received? (4.1(e), Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire C and Attestation of Compliance, Version 3.2)
  • For TLS implementations, is TLS enabled whenever cardholder data is transmitted or received? (4.1(e), Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire C-VT and Attestation of Compliance, Version 3.2)
  • For TLS implementations, is TLS enabled whenever cardholder data is transmitted or received? (4.1(e), Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire D and Attestation of Compliance for Merchants, Version 3.2)
  • Are industry best practices (for example, IEEE 802.11i) used to implement strong encryption for authentication and transmission for wireless networks transmitting cardholder data or connected to the cardholder data environment? (4.1.1, Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire D and Attestation of Compliance for Service Providers, Version 3.1)
  • For TLS implementations, is TLS enabled whenever cardholder data is transmitted or received? (4.1(e), Payment Card Industry (PCI) Data Security Standard, Self-Assessment Questionnaire D and Attestation of Compliance for Service Providers, Version 3.2)
  • Are industry best practices (for example, IEEE 802.11i) used to implement strong encryption for authentication and transmission for wireless networks transmitting cardholder data or connected to the cardholder data environment? (PCI DSS Question 4.1.1, PCI DSS Self-Assessment Questionnaire B-IP and Attestation of Compliance, Version 3.0)
  • Are industry best practices (for example, IEEE 802.11i) used to implement strong encryption for authentication and transmission for wireless networks transmitting cardholder data or connected to the cardholder data environment? (PCI DSS Question 4.1.1, PCI DSS Self-Assessment Questionnaire C and Attestation of Compliance, Version 3.0)
  • Are industry best practices (for example, IEEE 802.11i) used to implement strong encryption for authentication and transmission for wireless networks transmitting cardholder data or connected to the cardholder data environment? (PCI DSS Question 4.1.1, PCI DSS Self-Assessment Questionnaire C-VT and Attestation of Compliance, Version 3.0)
  • Are industry best practices (for example, IEEE 802.11i) used to implement strong encryption for authentication and transmission for wireless networks transmitting cardholder data or connected to the cardholder data environment? (PCI DSS Question 4.1.1, PCI DSS Self-Assessment Questionnaire D and Attestation of Compliance for Merchants, Version 3.0)
  • Are industry best practices (for example, IEEE 802.11i) used to implement strong encryption for authentication and transmission for wireless networks transmitting cardholder data or connected to the cardholder data environment? (PCI DSS Question 4.1.1, PCI DSS Self-Assessment Questionnaire D and Attestation of Compliance for Service Providers, Version 3.0)
  • Access to the network should be restricted to devices that meet minimum security configuration requirements, which includes verifying that devices are connecting over an encrypted network (e.g., a Virtual Private Network). (CF.09.03.04d, The Standard of Good Practice for Information Security)
  • Critical wireless access connections should be subject to additional security controls, such as Virtual Private Networks. (CF.09.06.07, The Standard of Good Practice for Information Security)
  • Access to the network should be restricted to devices that meet minimum security configuration requirements, which includes verifying that devices are connecting over an encrypted network (e.g., a Virtual Private Network). (CF.09.03.04d, The Standard of Good Practice for Information Security, 2013)
  • Critical wireless access connections should be subject to additional security controls, such as Virtual Private Networks. (CF.09.06.07, The Standard of Good Practice for Information Security, 2013)
  • Verify that the out of band authenticator and verifier communicates over a secure independent channel. (2.7.4, Application Security Verification Standard 4.0.3, 4.0.3)
  • Verify that sensitive data is sent to the server in the HTTP message body or headers, and that query string parameters from any HTTP verb do not contain sensitive data. (8.3.1, Application Security Verification Standard 4.0.3, 4.0.3)
  • Verify that TLS is used for all client connectivity, and does not fall back to insecure or unencrypted communications. (9.1.1, Application Security Verification Standard 4.0.3, 4.0.3)
  • Verify that encrypted communications such as TLS is used for all inbound and outbound connections, including for management ports, monitoring, authentication, API, or web service calls, database, cloud, serverless, mainframe, external, and partner connections. The server must not fall back to insecu… (9.2.2, Application Security Verification Standard 4.0.3, 4.0.3)
  • Verify that if the application has a client or server auto-update feature, updates should be obtained over secure channels and digitally signed. The update code must validate the digital signature of the update before installing or executing the update. (10.3.1, Application Security Verification Standard 4.0.3, 4.0.3)
  • The organization should use client certificates to validate and authenticate systems before the system is connected to the private network. (Critical Control 1.10, Twenty Critical Security Controls for Effective Cyber Defense: Consensus Audit Guidelines, Version 4.0)
  • Data related to electronic commerce (e-commerce) that traverses public networks shall be appropriately classified and protected from fraudulent activity, unauthorized disclosure, or modification in such a manner to prevent contract dispute and compromise of data. (DSI-03, Cloud Controls Matrix, v3.0)
  • Secured and encrypted communication channels shall be used when migrating physical servers, applications, or data to virtualized servers and, where possible, shall use a network segregated from production-level networks for such migrations. (IVS-10, Cloud Controls Matrix, v3.0)
  • Use secure and encrypted communication channels when migrating servers, services, applications, or data to cloud environments. Such channels must include only up-to-date and approved protocols. (IVS-07, Cloud Controls Matrix, v4.0)
  • A trusted path should be used for security-relevant interactions between a user and the system and it should be used for security-relevant interactions between the system and trusted IT products. The trusted path should prevent the transmitted data from being modified or disclosed. The system, local… (§ 18.1, § 18.2, § M.1, § M.2, ISO 15408-2 Common Criteria for Information Technology Security Evaluation Part 2, 2008)
  • the communication means and channels. Communication should use dedicated means and channels, to make sure that the message is official and bears the appropriate authority. Communication channels should address any needs for the protection of the confidentiality and integrity of the information trans… (§ 7.4 Guidance ¶ 3(o), ISO/IEC 27003:2017, Information technology — Security techniques — Information security management systems — Guidance, Second Edition, 2017-03)
  • The organization should provide the ability to return, transfer and/or disposal of PII in a secure manner. It should also make its policy available to the customer. (§ 8.4.2 Control, ISO/IEC 27701:2019, Security techniques - Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management - Requirements and guidelines)
  • The transmission, movement, and removal of information is restricted to authorized internal and external users and processes and is protected during transmission, movement, or removal, enabling the entity to meet its commitments and system requirements as they relate to [insert the principle(s) addr… (CC5.7, TSP 100A - Trust Services Principles and Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy)
  • An inpatient rehabilitation facility must transmit complete, accurate, and encoded data electronically for a Medicare Part A fee-for-service and a Medicare Part C inpatient in accordance with the specified data format and use electronic communications software that provides a direct telephone connec… (§ 412.614(b), 42 CFR Parts 412, 413, 422 et al., Medicare and Medicaid Programs; Electronic Health Record Incentive Program, Final Rule)
  • CSR 2.3.3: The organization must establish a trusted communications path between the security functionality and the user. CSR 10.10.2: The organization must use authorized VPN client software to enable remote and wireless access sessions through VPN links. (CSR 2.3.3, CSR 10.10.2, Pub 100-17 Medicare Business Partners Systems Security, Transmittal 7, Appendix A: CMS Core Security Requirements CSR, March 17, 2006)
  • An ICAP is required to mitigate vulnerabilities and risks associated with implementing a commercial CSP's CSO infrastructure on-premises (i.e., located inside the B/C/P/S physical or virtual "fence-line.") when, as expected, that infrastructure is managed by the CSP from their off-premises corporate… (Section 5.10.1.2 ¶ 3, Department of Defense Cloud Computing Security Requirements Guide, Version 1, Release 3)
  • The MPE user must establish a VPN connection to NIPRNet or the application itself. (Section 5.10.1.5 ¶ 1 Bullet 1, Department of Defense Cloud Computing Security Requirements Guide, Version 1, Release 3)
  • Implement a secure (encrypted) connection or path (i.e., encrypted VPN) between the implemented systems/applications and the DoD OCSP responders on NIPRNet or SIPRNet as applicable (Section 5.10.6 ¶ 1 Bullet 16, sub-bullet 3, Department of Defense Cloud Computing Security Requirements Guide, Version 1, Release 3)
  • Good engineering practices, such as cyclic redundancy checks and parity checks, must be implemented for incoming files and outgoing files to ensure the integrity mechanisms of commercial off the shelf products, government off the shelf products, and custom developed solutions. (ECTM-1, DoD Instruction 8500.2 Information Assurance (IA) Implementation)
  • Good engineering practices, such as cyclic redundancy checks and parity checks, must be implemented for incoming files and outgoing files to ensure the integrity mechanisms of commercial off the shelf products, government off the shelf products, and custom developed solutions. (ECTM-2, DoD Instruction 8500.2 Information Assurance (IA) Implementation)
  • High-robustness commercial off the shelf products or government off the shelf products, products that have been evaluated by National Security Agency or with National Security Agency-approved processes, must be used for protecting classified information that transits networks at a lower classificati… (DCSR-3, DoD Instruction 8500.2 Information Assurance (IA) Implementation)
  • Transport-level. Use a trusted connection in accordance with the standards specified in §170.210(a)(2) and (c)(2). (§ 170.315 (d) (9) (ii), 45 CFR Part 170 Health Information Technology Standards, Implementation Specifications, and Certification Criteria and Certification Programs for Health Information Technology, current as of January 2024)
  • Establish a secure and trusted connection with an application that requests data for patient and user scopes in accordance with the implementation specifications adopted in § 170.215(b)(1) and (c). (§ 170.315 (g) (10) (iv) (A), 45 CFR Part 170 Health Information Technology Standards, Implementation Specifications, and Certification Criteria and Certification Programs for Health Information Technology, current as of January 2024)
  • Establish a secure and trusted connection with an application that requests data for system scopes in accordance with the implementation specification adopted in § 170.215(d). (§ 170.315 (g) (10) (iv) (B), 45 CFR Part 170 Health Information Technology Standards, Implementation Specifications, and Certification Criteria and Certification Programs for Health Information Technology, current as of January 2024)
  • Transport-level. Use a trusted connection in accordance with the standards specified in §170.210(a)(2) and (c)(2). (§ 170.315 (d) (9) (ii), 45 CFR Part 170, Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, current as of July 14, 2020)
  • Establish a secure and trusted connection with an application that requests data for patient and user scopes in accordance with the implementation specifications adopted in §170.215(a)(2) and (3). (§ 170.315 (g) (10) (iv) (A), 45 CFR Part 170, Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, current as of July 14, 2020)
  • Establish a secure and trusted connection with an application that requests data for system scopes in accordance with the implementation specification adopted in §170.215(a)(4). (§ 170.315 (g) (10) (iv) (B), 45 CFR Part 170, Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, current as of July 14, 2020)
  • The information shared through communication mediums shall be protected with appropriate security safeguards. The agreements established by entities sharing information across systems and communications mediums are vital to ensuring all parties fully understand and agree to a set of security standar… (§ 5.1 ¶ 1, Criminal Justice Information Services (CJIS) Security Policy, CJISD-ITS-DOC-08140-5.8, Version 5.8)
  • Protection includes safeguards (e.g., acoustic, electric, electromagnetic, and physical) and if feasible countermeasures (e.g., alarms, notifications) to permit its use for the transmission of unencrypted information through an area of lesser classification or control. (§ 5.10.1.2.1 ¶ 1 ¶ 1(2)(d), Criminal Justice Information Services (CJIS) Security Policy, CJISD-ITS-DOC-08140-5.8, Version 5.8)
  • Verifiers shall use approved encryption and an authenticated protected channel when requesting passwords to protect against eavesdropping and Man-in-the-Middle (MitM) attacks. (§ 5.6.2.1.1.2 ¶ 1(8), Criminal Justice Information Services (CJIS) Security Policy, CJISD-ITS-DOC-08140-5.8, Version 5.8)
  • CJI transmitted via a single or multi-function device over a standard telephone line is exempt from encryption requirements. CJI transmitted external to a physically secure location using a facsimile server, application or service which implements email-like technology, shall meet the encryption req… (§ 5.10.2 ¶ 1, Criminal Justice Information Services (CJIS) Security Policy, CJISD-ITS-DOC-08140-5.8, Version 5.8)
  • Medium terminates within physically secure locations at both ends with no interconnections between. (§ 5.10.1.2.1 ¶ 1 ¶ 1(2)(b), Criminal Justice Information Services (CJIS) Security Policy, CJISD-ITS-DOC-08140-5.8, Version 5.8)
  • Verifiers shall use approved encryption and an authenticated protected channel when requesting passwords to protect against eavesdropping and Man-in-the-Middle (MitM) attacks. (§ 5.6.2.1.1.2 ¶ 1 8., Criminal Justice Information Services (CJIS) Security Policy, CJISD-ITS-DOC-08140-5.9.1, Version 5.9.1)
  • The information shared through communication mediums shall be protected with appropriate security safeguards. The agreements established by entities sharing information across systems and communications mediums are vital to ensuring all parties fully understand and agree to a set of security standar… (§ 5.1 ¶ 1, Criminal Justice Information Services (CJIS) Security Policy, CJISD-ITS-DOC-08140-5.9.1, Version 5.9.1)
  • Obtained directly from a trusted entity (e.g. trusted broker) using a protocol where the trusted entity authenticates to the relying party using a secure protocol (e.g. transport layer security [TLS]) that cryptographically authenticates the verifier and protects the assertion. (§ 5.6.4 ¶ 1 2., Criminal Justice Information Services (CJIS) Security Policy, CJISD-ITS-DOC-08140-5.9.1, Version 5.9.1)
  • The organization should ensure a trusted path is being used from the time the customer enters his/her personal banking information until the final transmission of data is completed. (Pg 34, FFIEC IT Examination Handbook - Retail Payment Systems, March 2004)
  • The identity and the authority of the sender should be authenticated prior to transferring funds. (Pg 32, FFIEC IT Examination Handbook - Wholesale Payment Systems, July 2004)
  • The service provider must define the security functions that require a trusted path. (Column F: SC-11, FedRAMP Baseline Security Controls)
  • The joint authorization board must approve and accept the list of security functions that require a trusted path. (Column F: SC-11, FedRAMP Baseline Security Controls)
  • Communication between the claimant and verifier (using the primary channel in the case of an out-of-band authenticator) SHALL be via an authenticated protected channel to provide confidentiality of the authenticator output and resistance to man-in-the-middle (MitM) attacks (4.1.2 ¶ 2, Digital Identity Guidelines: Authentication and Lifecycle Management, NIST SP 800-63B)
  • Communication between the claimant and verifier (the primary channel in the case of an out-of-band authenticator) SHALL be via an authenticated protected channel to provide confidentiality of the authenticator output and resistance to MitM attacks. (4.2.2 ¶ 2, Digital Identity Guidelines: Authentication and Lifecycle Management, NIST SP 800-63B)
  • Communication between the claimant and verifier SHALL be via an authenticated protected channel to provide confidentiality of the authenticator output and resistance to MitM attacks. All cryptographic device authenticators used at AAL3 SHALL be verifier impersonation resistant as described in Sectio… (4.3.2 ¶ 1, Digital Identity Guidelines: Authentication and Lifecycle Management, NIST SP 800-63B)
  • The out-of-band authenticator SHALL establish a separate channel with the verifier in order to retrieve the out-of-band secret or authentication request. This channel is considered to be out-of-band with respect to the primary communication channel (even if it terminates on the same device) provided… (5.1.3.1 ¶ 1, Digital Identity Guidelines: Authentication and Lifecycle Management, NIST SP 800-63B)
  • The authenticator SHALL accept transfer of the secret from the primary channel which it SHALL send to the verifier over the secondary channel to associate the approval with the authentication transaction. The claimant MAY perform the transfer manually or use a technology such as a barcode or QR code… (5.1.3.1 ¶ 5 Bullet 1, Digital Identity Guidelines: Authentication and Lifecycle Management, NIST SP 800-63B)
  • Establish an authenticated protected channel to the verifier using approved cryptography. The key used SHALL be stored in suitably secure storage available to the authenticator application (e.g., keychain storage, TPM, TEE, secure element). (5.1.3.1 ¶ 3 Bullet 1, Digital Identity Guidelines: Authentication and Lifecycle Management, NIST SP 800-63B)
  • A verifier impersonation-resistant authentication protocol SHALL establish an authenticated protected channel with the verifier. It SHALL then strongly and irreversibly bind a channel identifier that was negotiated in establishing the authenticated protected channel to the authenticator output (e.g.… (5.2.5 ¶ 2, Digital Identity Guidelines: Authentication and Lifecycle Management, NIST SP 800-63B)
  • The entire proofing transaction, including transactions that involve a third party, SHALL occur over an authenticated protected channel. (4.2 ¶ 1.9, Digital Identity Guidelines: Enrollment and Identity Proofing, NIST SP 800-63A)
  • The CSP SHALL ensure that all communications occur over a mutually authenticated protected channel. (5.3.3.2 ¶ 2.7, Digital Identity Guidelines: Enrollment and Identity Proofing, NIST SP 800-63A)
  • Communications between the IdP and the RP SHALL be protected in transit using an authenticated protected channel. Communications between the subscriber and either the IdP or the RP (usually through a browser) SHALL be made using an authenticated protected channel. (7.3 ¶ 1, Digital Identity Guidelines: Federation and Assertions, NIST SP 800-63C)
  • Conveyance of the assertion from the IdP to the subscriber, as well as from the subscriber to the RP, SHALL be made over an authenticated protected channel. (7.2 ¶ 6, Digital Identity Guidelines: Federation and Assertions, NIST SP 800-63C)
  • Conveyance of the assertion reference from the IdP to the subscriber, as well as from the subscriber to the RP, SHALL be made over an authenticated protected channel. Conveyance of the assertion reference from the RP to the IdP, as well as the assertion from the IdP to the RP, SHALL be made over an … (7.1 ¶ 9, Digital Identity Guidelines: Federation and Assertions, NIST SP 800-63C)
  • When assertions are passed through third parties, such as a browser, the actual assertion SHALL be encrypted. For example, a SAML assertion can be encrypted using XML-Encryption, or an OpenID Connect ID Token can be encrypted using JSON Web Encryption (JWE). For assertions that are passed directly b… (6.2.3 ¶ 3, Digital Identity Guidelines: Federation and Assertions, NIST SP 800-63C)
  • Calls for Access Control (AC): Organizations must limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems) and to the types of transactions and functions that authorized users are permitted to exercise. The … (§ 3, FIPS Pub 200, Minimum Security Requirements for Federal Information and Information Systems, March 2006)
  • The protection of data transmitted over public or shared data networks is called for. The ISF Standard requires the protection and integrity of sensitive information. It explains that the transfer of sensitive information should be protected from unauthorized disclosure by encrypting the information… (§ 3.12.1, Generally Accepted Principles and Practices for Securing Information Technology Systems, NIST SP 800-14, September 1996)
  • Organizational records and documents should be examined to ensure a trusted path exists between the user and the security functions, the trusted path is continuously in use, and specific responsibilities and actions have been defined for the implementation of the trusted path control. Any problems d… (AC-18(1), AC-18.10, SC-11, SC-11.2, Guide for Assessing the Security Controls in Federal Information Systems, NIST SP 800-53A)
  • Bluetooth users should establish connections only with trusted sources. Bluetooth users should accept transmissions, including messages, files, and images, only from trusted devices. (Table 4-2 Item 29, Guide to Bluetooth Security, NIST SP 800-121, September 2008)
  • Handheld devices with Bluetooth should be able to define a list of the devices that it can connect to via Bluetooth. (§ 4.1.6, Guidelines on Cell Phone and PDA Security, NIST SP 800-124, October 2008)
  • The organization may protect the confidentiality of Personally Identifiable Information that is electronically transmitted by encrypting the communications or encrypting the information before transmitting it. (§ 4.3 Bullet Transmission Confidentiality (SC-9), NIST SP 800-122 Guide to Protecting the Confidentiality of Personally Identifiable Information (PII))
  • The smart grid Information System must use authentication and encryption to protect wireless access. (SG.AC-15 Requirement Enhancements 3, NISTIR 7628 Guidelines for Smart Grid Cyber Security: Vol. 1, Smart Grid Cyber Security Strategy, Architecture, and High-Level Requirements, August 2010)
  • The smart grid Information System must establish a trusted communications path between the system and the user. (SG.SC-10 Requirement, NISTIR 7628 Guidelines for Smart Grid Cyber Security: Vol. 1, Smart Grid Cyber Security Strategy, Architecture, and High-Level Requirements, August 2010)
  • The Information System must use trusted paths for authentication and reauthentication between the user and a defined list of security functions. (App F § SC-11, Recommended Security Controls for Federal Information Systems, NIST SP 800-53)
  • The information system establishes a trusted communications path between the user and the following security functions of the system: {organizationally documented security functions to include at a minimum, information system authentication and re-authentication}. (SC-11 Control, Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53, Deprecated, Revision 4, Deprecated)
  • The information system provides a trusted communications path that is logically isolated and distinguishable from other paths. (SC-11(1), Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53, Deprecated, Revision 4, Deprecated)
  • The information system provides a trusted communications path that is logically isolated and distinguishable from other paths. (SC-11(1) ¶ 1, Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53, Revision 4)
  • The information system establishes a trusted communications path between the user and the following security functions of the system: [Assignment: organization-defined security functions to include at a minimum, information system authentication and re-authentication]. (SC-11 Control, Security and Privacy Controls for Federal Information Systems and Organizations, NIST SP 800-53, Revision 4)
  • Provide a [Selection: physically; logically] isolated trusted communications path for communications between the user and the trusted components of the system; and (SC-11a., Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53, Revision 5)
  • Permit users to invoke the trusted communications path for communications between the user and the following security functions of the system, including at a minimum, authentication and re-authentication: [Assignment: organization-defined security functions]. (SC-11b., Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53, Revision 5)
  • Initiate the trusted communications path for communications between the [Assignment: organization-defined security functions] of the system and the user. (SC-11(1)(b), Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53, Revision 5)
  • Provide a trusted communications path that is irrefutably distinguishable from other communications paths; and (SC-11(1)(a), Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53, Revision 5)
  • Provide a [Selection: physically; logically] isolated trusted communications path for communications between the user and the trusted components of the system; and (SC-11a., Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53, Revision 5.1.1)
  • Permit users to invoke the trusted communications path for communications between the user and the following security functions of the system, including at a minimum, authentication and re-authentication: [Assignment: organization-defined security functions]. (SC-11b., Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53, Revision 5.1.1)
  • Initiate the trusted communications path for communications between the [Assignment: organization-defined security functions] of the system and the user. (SC-11(1)(b), Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53, Revision 5.1.1)
  • Provide a trusted communications path that is irrefutably distinguishable from other communications paths; and (SC-11(1)(a), Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53, Revision 5.1.1)