Page 40

EETE JULAUG 2014

DATA ENCRYPTION & SECURITY Ethereal encryption: Key management in the Cloud By James Parry Hyper-conected enterprises are seeing data being made more accessible over multiple devices supported and synchronised from the Cloud. The hosting of data provides significant benefits in the form of economic and operational advantages, however security and privacy concerns remain regarding the utilisation of Cloud services. In a bid to address these and reassure customers post-PRISM, Cloud Service Providers (CSPs) are now offering Cloud encryption tools with Google, Amazon and Microsoft all recently adding serverside encryption capability to their existing cloud services. Yet encryption can be a double-edged sword. Yes, it provides data protection by creating a barrier but at the same time it can become a barrier that impedes business if badly managed. As with many security projects, the problem lies in the perception of Cloud security. Encryption tends to be offered as a solution by IT with little regard for how it will mesh with the business process. All Cloud deployments are fundamentally about empowering the business but this focus can become blurred during discussions about security. When evaluating encryption options, there are many factors that must be considered so as not to impede access, breach governance requirements or disrupt other business functions. Easy to get wrong It is far easier to get cloud encryption wrong than it is to get it right. There are a number of areas which pose substantial risk to an organisation’s data and their required cloud encryption strategy. The more complex the cloud infrastructure becomes, the more thought and consideration needs to be applied to the encryption strategy. Getting it wrong can result in catastrophic consequences, ultimately impacting any solution’s integration capability, speed and search-ability as well as having dire consequences on maintaining confidentiality and the integrity of stored and processed data. Getting it right demands careful design and the correct application of encryption around the business life-cycle: this requires understanding the business life-cycle in detail, understanding the data and developing comprehensive requirements before working with the CSP to develop an encryption system – but more importantly, don’t forget the keys! This may seem obvious but many organisations do exactly this. Consumed by the need to ensure the systems have access, they endanger the keys by design. Key derivation, storage and management must be carefully considered. Technology can provide the most robust encryption mechanisms available, but if access and storage of keys are not controlled in an appropriate manner, it all goes to waste. Similarly, if your keys are inherently weak, transmitted insecurely or not rotated properly, any encryption used is immediately flawed and provides an organisation with a false sense of security. Too many organisations continually underestimate the importance of sensible key management, which is very often left until the end of a project, as an afterthought. By this stage it is often too late, leading to significant impact and a need to redesign, incurring an increase in cost. In addition, if an organisation does not fully understand the entire business life-cycle and required data sets, it cannot ensure the right type of encryption mechanisms are applied to the data in the right way. For example, an organisation which has decided to encrypt sensitive Human Resources (HR) data may not realise that its finance department interfaces with the data set for payroll purposes on a monthly basis. This could have serious consequences if the encryption mechanisms have not been applied correctly. If the infrastructure architect does not realise that sensitive personal records such as Criminal Record declarations are held in the HR system, they may not apply the correct type of encryption. What about system integration? How will they know what can and cannot be done to the data and at what points in its life, if integration requirements are not understood? Transparent encryption Providers have become conscious of the scenario where the payroll clerk in the HR may be more preoccupied with doing his/her job efficiently and effectively than with the “latest and greatest” encryption engine deployed on the backend. For this reason, many engines are designed to operate in the background. Making it transparent to the end user means “letting the machines do the work” and this includes the requirement to provide key retrieval, tokenising or reversing queries to access data as quickly and securely as possible. While many system providers have proactively integrated encryption capabilities, early adopters being storage and database providers, CSPs have been late to the party, offering traditional protection for data at rest but treating everything else as an afterthought or out of the scope of their delivery. Because of this, it is essential to closely examine exactly what is on offer and how it will be managed. When it comes to assessing cloud encryption key management providers, look at their credentials. If they are using a product, what is it, how is it built and to what standards? Some standards such as NIST FIPS 140-2 also include key management mechanism considerations and may provide a suitable level of assurance for the majority of cases. Does the provider abide by or is certified against ISO27001? And if so, how widely does the scope of its certification apply? What clearance James Parry is Senior Consultant and Technical Architect at data, ICT and security consultancy Auriga – www.auriga.com - He can be contacted at james.parry@auriga.com 40 Electronic Engineering Times Europe July/August 2014 www.electronics-eetimes.com


EETE JULAUG 2014
To see the actual publication please follow the link above