Security Frame: Communication Security | Mitigations

• Secure communication to Event Hub using SSL/TLS

• Check service account privileges and check that the custom Services or ASP.NET Pages respect CRM's security

• Use Data management gateway while connecting On-premises SQL Server to Azure Data Factory

• Ensure that all traffic to Identity Server is over HTTPS connection

• Verify X.509 certificates used to authenticate SSL, TLS, and DTLS connections
• Configure TLS/SSL certificate for custom domain in Azure App Service
• Force all traffic to Azure App Service over HTTPS connection
• Enable HTTP Strict Transport Security (HSTS)

• Ensure SQL server connection encryption and certificate validation
• Force Encrypted communication to SQL server

• Ensure that communication to Azure Storage is over HTTPS
• Validate MD5 hash after downloading blob if HTTPS cannot be enabled
• Use SMB 3.0 compatible client to ensure in-transit data encryption to Azure File Shares

• Implement Certificate Pinning

• Enable HTTPS - Secure Transport channel
• WCF: Set Message security Protection level to EncryptAndSign
• WCF: Use a least-privileged account to run your WCF service

• Force all traffic to Web APIs over HTTPS connection

• Ensure that communication to Azure Cache for Redis is over TLS

• Secure Device to Field Gateway communication

• Secure Device to Cloud Gateway communication using SSL/TLS

The Data Management Gateway (DMG) tool is required to connect to data sources which are protected behind corpnet or a firewall.

1. Locking down the machine isolates the DMG tool and prevents malfunctioning programs from damaging or snooping on the data source machine. (E.g. latest updates must be installed, enable minimum required ports, controlled accounts provisioning, auditing enabled, disk encryption enabled etc.)
2. Data Gateway key must be rotated at frequent intervals or whenever the DMG service account password renews
3. Data transits through Link Service must be encrypted

Applications that use SSL, TLS, or DTLS must fully verify the X.509 certificates of the entities they connect to. This includes verification of the certificates for:

• Domain name
• Validity dates (both beginning and expiration dates)
• Revocation status
• Usage (for example, Server Authentication for servers, Client Authentication for clients)
• Trust chain. Certificates must chain to a root certification authority (CA) that is trusted by the platform or explicitly configured by the administrator
• Key length of certificate's public key must be >2048 bits
• Hashing algorithm must be SHA256 and above

Though Azure already enables HTTPS for Azure app services with a wildcard certificate for the domain *.azurewebsites.net, it do not enforce HTTPS. Visitors may still access the app using HTTP, which may compromise the app's security and hence HTTPS has to be enforced explicitly. ASP.NET MVC applications should use the RequireHttps filter that forces an unsecured HTTP request to be re-sent over HTTPS.

Alternatively, the URL Rewrite module, which is included with Azure App Service can be used to enforce HTTPS. URL Rewrite module enables developers to define rules that are applied to incoming requests before the requests are handed to your application. URL Rewrite rules are defined in a web.config file stored in the root of the application

HTTP Strict Transport Security (HSTS) is an opt-in security enhancement that is specified by a web application through the use of a special response header. Once a supported browser receives this header that browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS. It also prevents HTTPS click through prompts on browsers.

To implement HSTS, the following response header has to be configured for a website globally, either in code or in config. Strict-Transport-Security: max-age=300; includeSubDomains HSTS addresses the following threats:

• User bookmarks or manually types https://example.com and is subject to a man-in-the-middle attacker: HSTS automatically redirects HTTP requests to HTTPS for the target domain
• Web application that is intended to be purely HTTPS inadvertently contains HTTP links or serves content over HTTP: HSTS automatically redirects HTTP requests to HTTPS for the target domain
• A man-in-the-middle attacker attempts to intercept traffic from a victim user using an invalid certificate and hopes the user will accept the bad certificate: HSTS does not allow a user to override the invalid certificate message

All communications between SQL Database and a client application are encrypted using Transport Layer Security (TLS), previously known as Secure Sockets Layer (SSL), at all times. SQL Database doesn't support unencrypted connections. To validate certificates with application code or tools, explicitly request an encrypted connection and do not trust the server certificates. If your application code or tools do not request an encrypted connection, they will still receive encrypted connections

However, they may not validate the server certificates and thus will be susceptible to "man in the middle" attacks. To validate certificates with ADO.NET application code, set Encrypt=True and TrustServerCertificate=False in the database connection string. To validate certificates via SQL Server Management Studio, open the Connect to Server dialog box. Click Encrypt connection on the Connection Properties tab

Windows Azure Blob service provides mechanisms to ensure data integrity both at the application and transport layers. If for any reason you need to use HTTP instead of HTTPS and you are working with block blobs, you can use MD5 checking to help verify the integrity of the blobs being transferred

This will help with protection from network/transport layer errors, but not necessarily with intermediary attacks. If you can use HTTPS, which provides transport level security, then using MD5 checking is redundant and unnecessary.

Certificate pinning defends against Man-In-The-Middle (MITM) attacks. Pinning is the process of associating a host with their expected X509 certificate or public key. Once a certificate or public key is known or seen for a host, the certificate or public key is associated or 'pinned' to the host.

Thus, when an adversary attempts to do TLS MITM attack, during TLS handshake the key from attacker's server will be different from the pinned certificate's key, and the request will be discarded, thus preventing MITM Certificate pinning can be achieved by implementing ServicePointManager's ServerCertificateValidationCallback delegate.

• EXPLANATION: If an application handles sensitive information and does not use message-level encryption, then it should only be allowed to communicate over an encrypted transport channel.
• RECOMMENDATIONS: Ensure that HTTP transport is disabled and enable HTTPS transport instead. For example, replace the <httpTransport/> with <httpsTransport/> tag. Do not rely on a network configuration (firewall) to guarantee that the application can only be accessed over a secure channel. From a philosophical point of view, the application should not depend on the network for its security.

From a practical point of view, the people responsible for securing the network do not always track the security requirements of the application as they evolve.

• EXPLANATION: When Protection level is set to "none" it will disable message protection. Confidentiality and integrity is achieved with appropriate level of setting.
• RECOMMENDATIONS:
  • when Mode=None - Disables message protection
  • when Mode=Sign - Signs but does not encrypt the message; should be used when data integrity is important
  • when Mode=EncryptAndSign - Signs and encrypts the message

Consider turning off encryption and only signing your message when you just need to validate the integrity of the information without concerns of confidentiality. This may be useful for operations or service contracts in which you need to validate the original sender but no sensitive data is transmitted. When reducing the protection level, be careful that the message does not contain any personal data.

• EXPLANATION: Do not run WCF services under admin or high privilege account. in case of services compromise it will result in high impact.
• RECOMMENDATIONS: Use a least-privileged account to host your WCF service because it will reduce your application's attack surface and reduce the potential damage if you are attacked. If the service account requires additional access rights on infrastructure resources such as MSMQ, the event log, performance counters, and the file system, appropriate permissions should be given to these resources so that the WCF service can run successfully.

If your service needs to access specific resources on behalf of the original caller, use impersonation and delegation to flow the caller's identity for a downstream authorization check. In a development scenario, use the local network service account, which is a special built-in account that has reduced privileges. In a production scenario, create a least-privileged custom domain service account.