Salesforce Encryption - part 2

August 24, 2015 By Anthony Scotney

In the first section of this two part post on implementing cloud data protection for Salesforce, we looked at identifying an appropriate cloud data protection solution, encrypting application data and how to lock end applications to the cloud data protection gateway. In this second part, we are looking at moving to the next level of cloud protection, threat identification, countermeasures and mitigation.

Continuing the 6 steps to securing your cloud application:

4: Implement stringent security countermeasures

Any cloud data protection platform should utilize some form of countermeasures to protect end data. Countermeasures consist of automated responses to security events. When the gateway detects an in-bound threat, it must have the capability to mitigate this threat.

Countermeasures should operate from a technical standpoint at a firewall level and bubble up to an individual user. This granular focus ensures that there is not a denial of service for the user base. Directed, individually focused countermeasures, should only apply to the user that triggered it, and not disrupt the entire the user base.

An automated countermeasure may be to block the individual request and take no further action. Depending on severity and if other security anomalies have been detected, the response may be to lock a user account, block the footprint and require the suspect user to perform steps to re-establish their authenticity. The severity of response should be able to be adjusted to meet the security condition detected.

Far too often, security analytics (such as behavioural) operate distinctly from threat mitigation. Analysis engines detect anomalies and notify the security team. Depending on work-load, these notifications are investigated or ignored. One case in point is the Target data breach. It is widely accepted that the security team had "notification fatigue" and was thus not acting on all notifications.

Mitigating alert fatigue is done through automated countermeasures. These countermeasures respond to threat conditions without the need for human interaction. This reduces the delay in threat detection and mitigation.

Countermeasures should be able to fingerprint individual users and their machines and determine legitimate users from nefarious ones. If the system is unsure, it should at the very least challenge the authenticity of the user.

Unfortunately, there has been a complete and utter disjoint in the cloud data protection market in terms of the overall threat picture. It is absolutely not enough to simply encrypt data, or study user behaviour. A cloud security solution must incorporate a complete set of security measures, rather than just single individual pieces.

There is no point in encrypting information if an attacker can casually utilize a stolen username and password to transit through the cloud data protection gateway, decrypting the protected data. The cloud security gateway must perform non-hostile user analysis and deploy countermeasures as required.

5: Track and mitigate any anomalies immediately

Anomaly detection, tracking and ultimately mitigation must be performed without delay. Bringing delays into the threat mitigation process is a recipe for disaster.

Cloud data protection gateways should not only be encrypting data going into Salesforce, they should be monitoring your users, establishing user identities and understanding the various behavioral patterns of users. This level of analysis and rigor provides a strong defence against determined adversaries.

Learning as users work with an end system is important in building a one-to-one security footprint. Set countermeasures should respond when a userís footprint changes in any distinct manner, or if they are acting differently from their peers.

Given where cloud data protection gateways sit in the network infrastructure stack, they have access to an incredible amount of useful information on users. This information must be analyzed to ensure that the needle in the haystack is found. The security anomaly is not a myth. Basic analysis can detect often otherwise undetected changes in behaviour that lead to data breaches.

Being able to act on behavioral data without delay is a fundamental piece to ensure that threats do not progress to a critical state. A robust countermeasure system provides a platform to respond immediately to threats as they develop, rather than a typical system that notifies an administrator and requires human intervention, which can impose critical delays.

6: Cloud security analytics, monitoring and visibility

The cloud, and indeed SaaS applications are known as Security Information and Event Management (SEIM) "blind-spots". The reason is, that these architectures do not necessarily expose the low level logs that SIEM consumes. This SIEM blind-spot in itself is a security vulnerability.

Cloud data protection gateways can remove this SIEM blind-spot by providing their own logging and analytical data. This data can typically be consumed by SIEM systems and thus remove the blind-spot that is the cloud.

However, raw data is not enough to provide security coverage for cloud applications. This raw data must be analyzed into meaningful identity aware metrics to ensure that security conditions do not go unnoticed. Some cloud data protection vendors, such as StratoKey, offer an in-built analytics engine that performs much of the processing to make raw data meaningful within a security context.

Conclusion

There are no silver bullets in security. The best an organization can do is to layer appropriate defenses to build Defense in Depth. Raising the level of complexity for attackers ensures that organizations do not fall victim to the vast majority of non-Hollywood style data breaches. The type that are typically opportunistically driven attacks, focused on either application vulnerabilities or user credential theft. By mitigating these attacks and controlling data security with encryption, organizations have a fighting chance to avoid becoming yet another data breach headline.