In the last part of this series on Data Security we’ll tackle the subject of the Cloud – the relatively ‘new kid on the block’. Actually “cloud computing” has been around for a long time, but the concept and naming was ‘repackaged’ along the way. The early foundation for the Cloud was ARPANET (1969), followed by several major milestones: Salesforce.com – the first major enterprise app available on the web (1999); Amazon Web Services (2002); Amazon EC2/S3 (2006); Web 2.0 (2009). The major impediment to mass use of the cloud (aka remote data centers) was cheap bandwidth. In parallel with massive bandwidth [mainly in the US, western Europe and Pacific Rim (APAC)] the development of fast and reliable web-based apps allowed concepts such as SaaS (Software as a Service) and other ‘remote’ applications to be viable. The initial use of the term “Cloud Computing” or “Cloud Storage” was intended to describe (in a buzzword fashion) the rather boring subject of remote data centers, hosted applications, storage farms, etc. in a way that mass consumers and small business could grasp.
Unfortunately this backfired in some corporate circles, leading to a fragmented and slow adoption of some of the potential power of cloud computing. Part of this was PR and communication, another was the fact that the security of early (and still many today unfortunately!) cloud centers was not very good. Concerns over security of assets, management and other access and control issues led many organizations – particularly media firms – to shun ‘clouds’ for some time, as they feared (perhaps rightly so early on) that their assets could be compromised or pirated. With a generally poor communication about cloud architecture, and the difference between ‘public clouds’ and ‘private clouds’ not being effectively communicated, widespread confusion existed for several years concerning this new technology.
Like most things in the IT world, very little was actually “new” – but incremental change is often perceived as boring so the marketing and hype around gradual improvements in remote data center capability, connectivity and features tended to portray these upgrades as a new and exciting (and perhaps untested!) entity.
The Data Security Model
To understand the security aspects of the Cloud, and more importantly to recognize the strategic concepts that apply to this computational model, it is important to know what a Cloud is, and what it is not. Essentially a cloud is a set of devices that host services in a remote location in relation to the user. Like most things in the IT world, there is a spectrum of capability and complexity… little clouds and bigger clouds… For instance, a single remote server that hosts some external storage that is capable of being reached by your cellphone can be considered a ‘cloud’… and on the other extreme the massive amount of servers and software that is known as AWS (Amazon Web Services) is also a cloud.
In both cases, and everything in between, all of the same issues we have discussed so far apply to the local cloud environment: Access Control, Network Security, Application Security and Data Compartmentalization. Every cloud provider must ensure that all these bits are correctly implemented – and it’s up to the due diligence of any cloud user/subscriber to verify that in fact these are in place. In addition to all these security features, there are some unique elements that must be considered in cloud computing.
The two main additional elements, in terms of security to both the cloud environment itself and the ‘user’ (whether that be an individual user or an entire organization that utilizes cloud services) are Cloud Access Control and Data Transport Control. Since the cloud is by its very nature remote from the user, almost always a WAN (Wide Area Network) connection is used to connect users to the cloud. This type of access is more difficult to secure, and as has been shown repeatedly by recent history, is susceptible to compromise. Even if the access control is fully effective, thereby allowing only authorized users to enter and perform operations, the problem of unauthorized data transport remains: again, recent reports demonstrate that ‘inside jobs’ often result in users that have access to data (or if the user’s credentials are compromised or stolen) can therefore move or delete data, often with serious results.
An extra layer of security protocols and procedures are necessary to ensure that data transport or editing operations are appropriate and authorized.
- Cloud Access Control (CAC) – Since the cloud environment (from an external user persepective) is ‘anonymous and external’ [i.e. neither the cloud nor the user can directly authenticate each other, nor is either contained within physical proximity] the possibility of unauthorized access (by a user) or spoofing (misdirecting a user to a cloud site other than which they intended to connect) is much greater. Both users and cloud sites must take extra precautions to ensure these scenarios do not take place.
- Two-factor authentication is even more important in a cloud environment than in a ‘normal’ network. The best form of such authentication is where one of the factors is a Real Time Key (RTK). Essentially this means that one of the key factors is either generated in real time (or revealed in real time) and this shared knowledge between the user and the cloud is used to help authenticate the session.
- One common example of RTK is where a short code is transmitted (often as a text message to the user’s cellphone) after the user completes the first part of a signon process using a username/password or some other single-factor login procedure.
- Another form of RTK could be a shared random key where the user device is usually a small ‘fob’ that displays a random number that changes every 30 seconds. The cloud site contains a random number generator that has the same seed as the user fob so the random numbers will be the same within the 30 second window.
- Either of these methods secures against both unauthorized user access (as is obvious) and protects the user against spoofing (in the first method, the required prior knowledge of the user’s cellphone number by the cloud site; in the second the requirement of matching random number generators).
- With small variations to the above procedures, such authentication can apply to M2M (Machine to Machine) sessions as well.
- Data Transport Control (DTC) – Probably the most difficult aspect of security to control is unauthorized movement, copying, deletion, etc. of data that is stored in a cloud environment. It’s the reason that even up until today many Hollywood studios prohibit their most valuable motion picture assets from being stored or edited in public cloud environments. Whether from external ‘hackers’ or internal network admins or others who have gone ‘rogue’ – protection must be provided to assets in a cloud even from users/machines that have been authenticated.
- One method is to encrypt the assets, whereby the users that can effect the movement, etc. of an asset do not have the decryption key, so even if data is copied it will be useless without the decryption key. However, this does not protect against deletion or other edit functions that could disrupt normal business. There are also times where the encryption/decryption process would add complexity and reduce efficiency of a workflow.
- Another method (offered by several commercial ‘managed transport’ applications) is a strict set of controls over which endpoints can receive or send data to/from a cloud. With the correct process controls in place (requiring for example that the defined lists of approved endpoints cannot be changed on the fly, and requires at least two different users to collectively authenticate updates to the endpoint list), a very secure set of transport privileges can be set up.
- Tightly integrating ACL (Access Control List) actions against users and a set of rules can again reduce the possibility of rogue operations. For instance, the deletion of more than 5 assets within a given time period by a single user would trigger an authentication request against a second user – this would prevent a single user from wholesale data destruction operations. You might lose a few assets but not hundreds or thousands.
One can see that the art of protection here is really in the strategy and process controls that are set up – the technical bits just carry out the strategies. There are always compromises, and the precise set of protocols that will work for one organization will be different for another: security is absolutely not a ‘one size fits all’ concept. There is also no such thing as ‘total security’ – even if one wanted to sacrifice a lot of usability. The best practices serve to reduce the probability of a serious breach or other kind of damage to an acceptable level.
In this final section on Data Security we’ve discussed the special aspects of cloud security at a high level. As cloud computing becomes more and more integral to almost every business today, it’s vital to consider the security of such entities. As the efficiency, ubiquity and cost-saving features of cloud computing continue to rise, many times a user is not even consciously aware that some of the functionality they enjoy during a session is being provided by one or more cloud sites. To further add to the complexity (and potentially reduce security) of cloud computing in general, many clouds talk to other clouds… and the user may have no knowledge or control over these ‘extended sessions’. One example (that is currently the subject of large-scale security issues) is mobile advertising placement.
When a user launches one of their ‘free’ apps on their smartphone, the little ads that often appear at the bottom are not placed there by the app maker, rather that real estate is ‘leased’ to the highest bidder at that moment. The first ‘connection’ to the app is often an aggregator who resells the ‘ad space’ on the apps to one or more agencies that put this space up for bidding. Factors such as the user’s location, the model of phone, the app being used, etc. all factor in the price and type of ad being accepted. The ads themselves are often further aggregated by mobile ad agencies or clearing houses, many of which are scattered around the globe. With the speed of transactions and the number of layered firms involved, it’s almost impossible to know exactly how many companies have a finger in the pie of the app being used at that moment.
As can be seen from this brief introduction to Data Security, the topic can become complex in the details, but actually rather simple at a high level. It takes a clear set of guidelines, a good set of strategies – and the discipline to carry out the rules that are finally adopted.
Further enquires on this subject can be directed to the author at firstname.lastname@example.org