The transmission of sensitive information and the execution of sensitive functions must be performed through secure protocols.
A system can send information through a non-encrypted channel using insecure protocols. The use of these protocols makes it easier to perform a man-in-the-middle attack (MitM) to intercept and modify the information. Examples of such insecure protocols are HTTP, FTP, POP3 and Telnet.
Deploy applications using HTTPS in the application server: When using this protocol, the channel used for the deployment of web applications is encrypted. For this, it is necessary to have certificates issued by a valid certifying entity.
Use secure services instead of standard services: When you need to transmit sensitive information using services such as FTP and POP3, you can enable secure versions of each protocol or implement protocols with the same functions but having communication encryption such as SSH, FTPS, POP3S and TLS.
An attacker with access to non-encrypted channels performs a man-in-the-middle (MitM) attack over the vulnerable assets in order to intercept, obtain and/or modify the transmitted information.
Layer: Resource Layer
Asset: Information Assets
Type of Control: Recommendation
CAPEC-12: Choosing Message Identifier. This pattern of attack is defined by the selection of messages distributed over via multicast or public information channels that are intended for another client by determining the parameter value assigned to that client. This attack allows the adversary to gain access to potentially privileged information, and to possibly perpetrate other attacks through the distribution means by impersonation.
CAPEC-31: Accessing/Intercepting/Modifying HTTP Cookies. This attack relies on the use of HTTP Cookies to store credentials, state information and other critical data on client systems. There are several different forms of this attack. The first form of this attack involves accessing HTTP Cookies to mine for potentially sensitive data contained therein. The second form involves intercepting this data as it is transmitted from client to server.
CAPEC-94: Man in the Middle Attack. This type of attack targets the communication between two components (typically client and server). The attacker places themself in the communication channel between the two components. Whenever one component attempts to communicate with the other (data flow, authentication challenges, etc.), the data first goes to the attacker, who has the opportunity to observe or alter it, and it is then passed on to the other component as if it was never observed.
CAPEC-117: Interception. An adversary monitors data streams to or from the target for information gathering purposes. This attack may be undertaken to solely gather sensitive information or to support a further attack against the target. This attack pattern can involve sniffing network traffic as well as other types of data streams (e.g. radio).
CAPEC-148: Content Spoofing. An adversary modifies content to make it contain something other than what the original content producer intended while keeping the apparent source of the content unchanged.
CAPEC-216: Communication Channel Manipulation. An adversary manipulates a setting or parameter on communications channel in order to compromise its security. This can result in information exposure, insertion/removal of information from the communications stream, and/or potentially system compromise.
CAPEC-594: Traffic Injection. An adversary injects traffic into the target’s network connection. The adversary is therefore able to degrade or disrupt the connection, and potentially modify the content.
CIS Controls. 4.5 Use Use Multi-Factor Authentication for All Administrative Access. Use multi-factor authentication and encrypted channels for all administrative account access.
CWE-200: Exposure of Sensitive Information to an Unauthorized Actor. The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
CWE-311: Missing Encryption of Sensitive Data. The software does not encrypt sensitive or critical information before storage or transmission.
CWE-319: Cleartext Transmission of Sensitive Information. The software transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.
CWE-326: Inadequate Encryption Strength. The software stores or transmits sensitive data using an encryption scheme that is theoretically sound, but is not strong enough for the level of protection required.
CWE-598: Use of GET Request Method With Sensitive Query Strings. The web application uses the HTTP GET method to process a request and includes sensitive information in the query string of that request.
Directive 2002/58/EC (amended by E-privacy Directive 2009/136/EC). Art. 4: Security of processing.(1a) The measures referred to in paragraph 1 shall at least protect personal data stored or transmitted against accidental or unlawful destruction, accidental loss or alteration, and unauthorized or unlawful storage, processing, access or disclosure.
ISO 27001:2013. Annex A - 13.2.3 Protect information included in electronic messages appropriately.
ISO 27001:2013. Annex A - 14.1.3 Protect information included in application services transactions to avoid partial transmission, improper routing, unauthorized message modifications, unauthorized disclosure and unauthorized message duplication or replay.
ISO 27001:2013. Annex A - 18.1.3 Protect records against loss, destruction, forgery, unauthorized access and unauthorized release, in accordance with legal, regulatory, contractual and business requirements.
NERC CIP-005-5. B. Requirements and measures. R2.2 For all Interactive Remote Access sessions, utilize encryption that terminates at an Intermediate System.
NERC CIP-011-2. B. Requirements and measures. R1.2 Implement procedure(s)for protecting and securely handling BES Cyber System Information, including storage, transit, and use.
OWASP Top 10 A3:2017-Sensitive Data Exposure. Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.
OWASP-ASVS v4.0.1 Appendix C: Internet of Things Verification Requirements.(C.7) Verify that the firmware apps protect data-in-transit using transport layer security.
OWASP-ASVS v4.0.1 Appendix C: Internet of Things Verification Requirements.(C.8) Verify that the firmware apps validate the digital signature of server connections.
OWASP-ASVS v4.0.1 Appendix C: Internet of Things Verification Requirements.(C.9) Verify that wireless communications are mutually authenticated.
OWASP-ASVS v4.0.1 Appendix C: Internet of Things Verification Requirements.(C.10) Verify that wireless communications are sent over an encrypted channel.
OWASP-ASVS v4.0.1 Appendix C: Internet of Things Verification Requirements.(C.16) Verify the presence of tamper resistance and/or tamper detection features.
OWASP-ASVS v4.0.1 Appendix C: Internet of Things Verification Requirements.(C.29) Verify that inter-chip communication is encrypted (e.g. Main board to daughter board communication).
OWASP-ASVS v4.0.1 V1.9 Client-side Data Protection.(1.9.1) Verify the application encrypts communications between components, particularly when these components are in different containers, systems, sites, or cloud providers.
OWASP-ASVS v4.0.1 V2.2 General Authenticator Requirements.(2.2.5) Verify that where a credential service provider (CSP) and the application verifying authentication are separated, mutually authenticated TLS is in place between the two endpoints.
OWASP-ASVS v4.0.1 V2.5 Credential Recovery Requirements.(2.5.1) Verify that a system generated initial activation or recovery secret is not sent in clear text to the user.
OWASP-ASVS v4.0.1 V3.1 Client-side Data Protection.(3.1.1) Verify the application never reveals session tokens in URL parameters or error messages.
OWASP-ASVS v4.0.1 V8.3 Sensitive Private Data.(8.3.1) 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.
OWASP-ASVS v4.0.1 V9.1 Communications Security Requirements.(9.1.1) Verify that secured TLS is used for all client connectivity, and does not fall back to insecure or unencrypted protocols.
OWASP-ASVS v4.0.1 V9.2 Server Communications Security Requirements.(9.2.2) 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 insecure or unencrypted protocols.
OWASP-ASVS v4.0.1 V9.2 Server Communications Security Requirements.(9.2.3) Verify that all encrypted connections to external systems that involve sensitive information or functions are authenticated.
OWASP-ASVS v4.0.1 V13.2 RESTful Web Service Verification Requirements.(13.2.5) Verify that the message headers and payload are trustworthy and not modified in transit. Requiring strong encryption for transport (TLS only) may be sufficient in many cases as it provides both confidentiality and integrity protection.
OWASP-ASVS v4.0.1 V13.3 SOAP Web Service Verification Requirements.(13.3.2) Verify that the message payload is signed using WS-Security to ensure reliable transport between client and service.
PCI DSS v3.2.1 - Requirement 2.3 Encrypt all non-console administrative access using strong cryptography.
PCI DSS v3.2.1 - Requirement 4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks. The protocol in use only supports secure versions or configurations.
PCI DSS v3.2.1 - Requirement 4.1.1 Ensure wireless networks transmitting cardholder data or connected to the cardholder data environment, use industry best practices to implement strong encryption for authentication and transmission.
PCI DSS v3.2.1 - Requirement 4.2 Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, SMS, chat, etc.).
PCI DSS v3.2.1 - Requirement 6.5.4 Address common coding vulnerabilities in software-development processes such as insecure communications.
PCI DSS v3.2.1 - Requirement 8.2.1 Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components.