A growing body of technical knowledge has been codified and broadly taught to computer science students on how to properly architect a large-scale application or system to meet functional and performance goals. A similar body of security engineering knowledge needs to be developed to architect a corresponding security architecture. A fundamental principle of this knowledge body should be to design for security, not to “bolt on” security after a system has been designed, or worse, deployed. Of particular importance is designing a method by which to measure the security of systems.
The problem of designing for security is exacerbated by the rapid movement of data and files to the public cloud – systems and architectures that are already deployed and used on a large scale. A recent ESG report reveals that many organizations have moved to their sensitive data into the public cloud far faster than they can secure it. A full 81% of respondents believe that on-premises security architecture is more mature and reliable than public cloud security. Yet, more and more data is being migrated to the public cloud. Fifty percent of respondents admitted that they know they’ve lost company data in a public cloud share; and another 22% say they suspect that they’ve lost data.
Therein lies a problem. The cloud has become a core component of modern enterprises, yet all of the security elements typically deployed in traditional, large enterprise networks, such as DLP, proxies, access controls, etc., lose their effectiveness when data moves to the cloud. We saw this illustrated in real time recently, when security researchers stumbled upon 540 million Facebook user records that had been sitting on a public storage server. The two batches of user records were collected and exposed as a result of shoddy security practices by two of Facebook’s third-party partners. But, under certain data privacy laws such as GDPR or the new California privacy law, Facebook could ultimately be held responsible for any data losses.
Compliance with a number of laws and regulations, such as GDPR, complicates the security problem, requiring additional mechanisms for fast reporting when a breach has been detected. But this presumes that data loss from a public cloud architecture is detectable, and that security risks are measurable. In the above example, Facebook didn’t know about these millions of records that were exposed. Sadly, overworked and stressed security personnel and CISOs would rather apply what I call the “Ostrich” defense, and would rather not know when a breach may have occurred. It’s just too difficult to measure and respond to data loss in the public cloud. But in this case, what you don’t know most certainly can hurt you. One cannot be lulled into believing their access controls will protect their data in the cloud when it is trivial to copy and pass along a link to an anonymous remote user. We know that these controls fail. Detecting risks and failures leading to breaches must be detected as quickly as possible if one has properly designed their security architecture in the cloud.
Security Architectures and Best Practices for the Cloud
The user behavior analytics (UBA) security solutions oriented primarily to the insider threat have matured and are commonplace. These systems are largely based upon auditing of users, gathering of data from network and application logs, and analyzing this data to identify indicators of risky behaviors and users. This data is crucial for forensics analyses when a major breach has been detected. There isn’t a comparable mature technology yet for the cloud where users have migrated their work.
The successful UBA technology teaches security professionals how to properly architect new enterprise systems with users’ cloud behaviors in full view. The core approach for the cloud is to gather data from cloud storage logs, extract features and carefully architect sets of indicators that detect likely breaches. Cloud logs can reveal, for example, when file extensions are changed, what documents are downloaded and to where, whether a document has been downloaded to an anonymous user, and when an unusually high number of documents are downloaded to an odd geolocation. These are all early indicators of potential breach activity.
The key to integrating the cloud into an enterprise’s security architecture is design in security. Part of that architecture needs to allow for auditing from cloud storage logs, which give security professionals the ability to extract indicators that measure risk, and continuously measure the cloud behavior of users. Isn’t it better to know? The “Ostrich” strategy shouldn’t be the response by security personnel and CISOs. Instead, they should use tools like cloud storage logs as part of a cloud-based security strategy.
*** This is a Security Bloggers Network syndicated blog from RSAConference Blogs RSS Feed authored by Salvatore J. Stolfo. Read the original post at: http://www.rsaconference.com/blogs/cloud-security-architectures-lifting-the-fog-from-the-cloud