Modernizing Authentication — What It Takes to Transform Secure Access
Sit down with the IT security team of almost any organization these days and youll probably hear one hot topic come up again and again - cloud-based e-mail. Organizations have used cloud-based anti-malware and spam filters for years, but until recently most have been reluctant to move mail servers, such as Lotus Notes and Microsoft Exchange, out of the enterprise data centers. Concerns about security and control of the servers have outweighed perceived benefits of a cloud or off-premise solution.
No more. Its a new decade and a paradigm shift is in full swing e-mail is moving into the cloud at a rapid pace. The shift to cloud E-mail has been fueled by cost concerns and made possible by the rapidly maturing offerings in rich collaboration and communication suites like BPOS (Business Productivity and Online Standard Suite) and Google Apps. A wide variety of organizations and enterprises have already made the switch: Klamath County Oregon and Swedish Red Cross are BPOS customers, Capgemini, Genentech, Motorola Mobile Devices are using Google Apps for Business, and Northwestern, Notre Dame, and Wesleyan are Google Apps for Education users.
The case studies are compelling and the trend is real, but that doesnt mean moving e-mail to the cloud is a risk-free no-brainer. E-mail and other forms of digital communication including VoIP and IM are the heart of most of todays companies. These conversation threads contain not only critical day-to-day business data, but also contain an ongoing archive and record of documents and historical activity. Without proper security and protection controls in place, this critical information could be at risk. Other security considerations organizations should review before trusting their e-mail and communications to the cloud include availability, compliance, portability, and incident management. Below is a round-up of buyer considerations to help companies make informed, risk-sensitive, purchasing decisions when selecting a cloud-based e-mail solution.
To understand the real cost of the cloud e-mail solution being evaluated, organizations should create a comprehensive calculator that takes into account all costs related with the various solutions. To be accurate from a risk perspective, security-related costs must also be included in this model. To calculate the basic total cost of ownership (TCO), include hardware and software expenses, annualized costs for ongoing maintenance, and human administrator costs. Next, add in any additional security control costs that are required for protection. For example, is there a firewall or patch management system helping to protect the mail server? How much do these cost? Are there compliance-related costs like security event or log monitoring and reporting? What is the price for those? And if there is an on-premise archive solution, how much does it cost to manage the e-mail and message archive? Also, how large is that archive expected to be in the next 3-5 years and will the size of the archive impact cost?
Armed with this comprehensive list of operational and security-related costs, an organization can formalize a cost-benefit analysis of the proposed cloud solution that reflects hidden costs related to security. Some cloud providers include a number of these protections as part of the ongoing operations for their data center at no additional charge. But an organization should get written confirmation from the provider that the controls are actually in place. If the cloud provider is not able to provide proof that the required security controls are there, thats a red-flag.
Additional documents that can help with the pricing analysis work: Should Your Email Live in the Cloud? A Comparative Cost Analysis, by Ted Schadler, Forrester Research (January 5, 2009); Gauging the Real Value of SaaS E-mail and How Much is Your E-mail Worth?: Quantifying the Total Value Investment (TVI) of SaaS E-mail to Small and Medium Businesses, by Karen Hobert and Pete Lindstrom, Collaborative Strategy Guild (July 29, 2009 and April 28, 2010).
If an organizations e-mail resides on servers at a providers data center - who owns it? And how is that ownership expressed over the lifecycle of the data? Consider a company that has a 90-day deletion cycle for old e-mail. Will the provider adhere to this deletion cycle? And not just on the servers that the customer seesbut even for the providers own backups? Alternately, if an organization has a never delete policy, is the cloud provider able to support that? Control can also cover when third-parties are allowed to access the data. During a legal investigation, what is the providers published policy on releasing customer data?
Another aspect of control is who can see the data on the providers cloud? Administrators generally require fairly broad access in order to do their jobs, but what assurance can the provider give that access control is being managed in its own data centers, and that administrators are limited to need-to-know? If a control change is required by the organization what is the process, if any, to make this happen in the cloud? Consider an organization that wishes to enforce encryption on all mail going to a specific address or domain. Can the organization change this control themselves using remote administration tools? And how quickly can this change occur? Does the cloud provider need to be involved in the change management process and, if so, will that add overhead costs or extend the timeline for the change?
One more issue with control is whether or not the data is portable if a company wants to move to another cloud provider. To avoid a data hostage situation, companies should determine what the providers policy is for exporting and moving data.
Backups and archive
As organizations move mail off-premise, they are also moving the storage and archiving of that mail to the cloud. Economies of scale and advances in data storage have made basic archiving quite cheap. But just because everything can be saved, doesnt mean it should be. Cost for storage is one consideration, but dont ignore the security requirements for management of the data at rest. If an organization does not already have a data lifecycle policy in place for e-mail, one should be adopted prior to shifting the archive to the cloud. The lifecycle policy should cover what should be stored, what (if anything) shouldnt be stored, and how long that data should be held for. If there is a spoliation requirement to delete old mail threads, confirm with the provider that complete destruction of the data is an option.
Consider how the e-mail archive will be used to best serve the business. Will the mails and conversations be needed for forensic use in investigations at a later date? If so, there may need to be chain of custody controls and tamper-proofing and tamper-evident protections on the archives. Ability to recover pieces of data or specific conversations is extremely helpful when trying to locate information. Does the provider index and allow for rapid search of the mail archive? Can conversations be searched by date, time, sender, recipient, or key word? When found, is it easy to tie-back any related conversations or threads to the original?
Availability of a service is part of operational fitness, but a denial of service (DoS) is a security concern. Ask the provider what kind of protections they have in place to ensure that mail servers will be available 24/7. If there is a catastrophic shut down in one data center, will activities be transferred to another data center seamlessly? Availability support controls can include, but arent limited to: geographic distribution of data centers, high availability and failover within and between data centers, and network-based protection to eliminate availability interruptions resulting from denial of service attacks and network outages.
An important part of the service level agreement (SLA) process is getting the uptime guarantees in writing. If the provider contracts to deliver 99.999% uptime, this should be called out explicitly in the contract. Also negotiate for remuneration should the provider fail to deliver that uptime. Companies should calculate the cost of being without e-mail per hour and negotiate with the provider to refund that amount if the e-mail servers go down. Something thats often overlooked is the inability to determine cause of outage, which can lead to an e-mail provider claiming the outage was caused by something outside of its control, like a DNS problem on the Internet. To avoid finger-pointing and increase the likelihood of recovering losses during outages, ask the provider to show how they track their server availability metrics.
Policy compliance and enforcement
Ability to implement and enforce policy is another key differentiator when looking at security requirements in cloud-based e-mail. Policy is a fairly broad term and can include both corporate-defined policies and those related to external mandates, such as HIPAA, NERC, and PCI. Policy can mean technical controls like whether or not two-factor authentication is required for login and if the communication channel between the e-mail client and the mail server is encrypted, but can also relate to whether or not a certain user is allowed to send e-mails off-hours or if some user e-mails are scanned for key words and other data leak prevention (DLP) triggers.
Its important to ask the provider not only if they can enforce policy controls, but also the level of granularity within those controls. One way to ease the policy burden is to use existing corporate policy repositories like LDAP or AD for usage enforcement in the cloud. Ask if the provider can leverage the existing policies either via direct communication with corporate policy servers or by exporting policy schema to the provider.
An area where policy comes into play that is often overlooked is in the area of geographic presence. If data centers are housed in a location where the governing policies differ from those of the headquarters, there could be a policy mismatch. Consider a Canadian company that operates under Canadian privacy laws storing e-mail in a US data center that operates under US privacy laws. For this Canadian customer, there may be a requirement that their mail server and archives reside in Canada rather than the US.
Privacy protection mandates and laws call for encryption of sensitive data, including when it is transmitted via e-mail. Is the cloud-provider able to deliver encryption services for e-mail in transit to the server, when stored and archived in the data center, and when being transmitted to third-parties?
Getting a little deeper into the encryption issue, many organizations are finding that granular encryption policy enforcement is paramount for regulatory compliance. Encryption can be accomplished manually by the sender, but a reliable automated encryption solution leaves less room for human error. Ask if the provider can support keyword or key data triggered encryption. For example, if an e-mail contains a 16-digit number and the sender is approved for transmitting credit card numbers, the e-mail forces encryption on the mail or attachment before sending it to the recipient.
Other questions to ask are what type of encryption algorithm is in use for transmission and storage? How is key management handled for stored data and what is the lifecycle for key refreshes? And for encrypted e-mails going to third-parties, what is the key distribution policy? For some organizations, an encrypted tunnel between the client and server is all thats required, but for companies that have more intensive encryption needs, a provider that can deliver may be harder to find. If the provider themselves does not have more granular encryption, investigate a layered approach that incorporates a mail encryption engine (either on or off premise) with the cloud-based e-mail.
No one wants to open a mailbox that is crammed with 100 spam messages. Cloud-based e-mail hygiene solutions have long been in use and can be used in conjunction with a cloud-based e-mail solution or as an integrated component. Google acquired message hygiene vendor Postini in 2007and the filtering service is included with Gmail. Microsofts BPOS comes with ForeFront filtering for message hygiene.
When comparing effectiveness of the filtering service and overall experience of the end-user, consider what kinds of filtering technologies are in use. Technical approaches to reduce unwanted messages include: authentication, reputational awareness, Bayesian filters, keyword scanning, domain and DNS validation, and address or domain white listing and blacklisting. One advantage that cloud providers have is the ability to parse huge volumes of mail to identify and respond to anomalous or suspect activity. For example, if a high volume of e-mails is being sent in a very short amount of time from a single address, this could indicate a spam or phishing attack. Providers can also leverage reports from users that send in unwanted e-mails for further investigation. Ask if the provider is using intelligent monitoring of overall traffic and user reports to increase effectiveness.
Also ask what the overall false positive rate is. False negatives matter, as well if an important e-mail does not get through because it was automatically marked as spam and deleted, what impact would it have on the business? Some filters have a grey option where a portion of the message, such as the sender name and the subject line, are passed through to the user who then must manually decide whether or not the mail is legitimate. This is a very helpful feature for eliminating false negatives, but if the false positive rate is too high, the user will be inundated with checks so there needs to be a balance.
Service Level Agreement (SLA) Negotiation
Assessing the above requirements and features before selecting a vendor may take time, but it provides an excellent roadmap for specifics that should be written down in the SLA. Though some vendors have pre-fabricated SLAs in place and wont modify them, if an organization wants to ensure that what theyve been promised during the sales cycle is adhered to in practice, having it in the SLA is helpful. For companies that are already contracted with a cloud provider, the SLA could be amended during the next round of service negotiations.
Weve already mentioned some points that are best to get in writing before the SLA is signedincluding remuneration for downtime and deleted mail. A couple of other points to consider either for the SLA itself or for an associated policy document: Notification and Right to Audit. When, or if, a breach occurs and data is lost, what is the reporting path for notification to the customer? Is there a designated in-house liaison at the provider who knows who to call if the breach occurs? And how quickly is that call made? What is the escalation path for notification? And if a change event is being entered into the e-mail server (such as a patch, or a new user) what is the notification and approval path for it?
Finally, what if any rights will the provider give the customer for auditing of their cloud data centers? Could the customer visit a data center? Bring in a third-party auditor? Admittedly this is not common practice, but for large, highly sensitive customers, an on-site audit of the provider may be a necessity. More common concerns: does the provider have transparency into how their own centers are run, the access control, hiring practices, and incident response plans? Has the provider been audited for HIPAA, SAS 70 Type II, PCI, or NERC compliance? And what were the results? Does the provider have any certifications like ISO 27001:2005? While certifications and passing audits arent guarantees of security, if a provider cant at least show documentation of security-related operating procedures and successful audits or certifications, thats a red flag.
Microsoft BPOS Audit Status, Source: Frequently Asked Questions: Microsoft Online Services Risk Management, Last Updated: September 28,