by Orlando Scott-Cowley
On-premises email and data archives are a growing challenge to organizations looking to reduce costs and management complexity.
Cloud archiving alternatives offer a compelling opportunity to remove the management headaches and deliver a secure, resilient and highly scalable archive service to meet requirements now and in the future. But concerns remain about the ideal migration strategy that balances effective risk management with new business requirements.
That’s why in this new webinar, I’ve teamed up with Gartner research director Alan Dayley to break down the beneﬁts of the cloud over on-premises email archiving. Together, we also explore the key considerations for migrating to the cloud, and look to the future of email archiving in the cloud.
Hybrid or 100% cloud? Should you migrate everything from legacy systems? How do I know if I even need archiving? We explore the key considerations and review what you need to think about regarding data sovereignty.
For customers thinking about moving to Ofﬁce 365, but concerned about their readiness, we’ll discuss migration strategies. Meanwhile, for those who have already made the move, we’ll discuss how a third party backup archive can make your data in Ofﬁce 365 fully resilient
There has never been a better time to move archives to the cloud.
Take a look at video here.
by Nathaniel Borenstein
I wasn’t there myself, but I heard from colleagues that Tim Berners-Lee (the originator of the WWW) keynoted at London’s IP EXPO Europe show earlier this month. He was asked why security wasn’t considered more in the beginning of the Internet.
This got me thinking back to those days and asking the same question. Why didn’t we early Internet guys predict the need or put the hours in on security from the start? After all, today there’s a whole industry now dedicated to the challenges of securing the Internet, as well as the data and communications carried over the network. Today, companies like Mimecast fight a never-ending struggle to keep the Internet reasonably secure.
Why didn’t we early Internet guys predict the need or put the hours in on security from the start? The good news is that the world runs on the Internet and there are thousands of smart people and companies working hard and fast to secure it and our data.
But many decades ago, there were so few people on the Internet that most of them knew each other by name. My late mentor, Einar Stefferud used to tell people his address was ‘stef @ any machine on the net.’ We mostly just trusted each other, as research colleagues. Besides, doing never-before-done amazing things is a lot more fun than preventing bad things that were, at the time, completely hypothetical.
For me, that’s all the explanation you should need. But I’ve plenty of other explanations and here are some of them:
1. They didn’t know how. When you’ve just built something new, by definition no one will know how to secure it. The people building them were specialists in all sorts of things, but not, with a few exceptions, security. They hoped that the security people could come in later and fix things up.
2. They didn’t want to. The early Internet pioneers tended to have a very egalitarian vision of the Internet. They wanted to open possibilities for everyone, not close them off from some people. While they would have readily said that some security would be needed, it just wasn’t what they wanted to work on. The vision of an Internet open to everyone tended to work against any efforts to secure it. Also, there was a lot of belief that anonymity should be possible on the net, so there was substantial resistance to requiring strong authentication of identity.
3. For most people, security was boring. Those who found it interesting generally wanted to work on something heavily used. Even security researchers — and there were some — generally trusted one another.
4. They feared it might be impossible. It was clear that Internet security would be very complex, and less clear that it would ever be truly possible. For that matter, they weren’t entirely sure that what they were trying to build with the Internet was even possible. Nearly all the protocol designers worried about security, and tried to make wise decisions when they could. But it’s hard to secure something before you’ve designed it.
The good news is that we now know the world loves (even runs) on the Internet and there are thousands of smart people and companies working hard and fast to secure it and our data. Nowadays there are university programs and whole careers to be made in various aspects of the Internet security industry.
It’s still an open question whether we can do so completely. The bad guys are constantly innovating so companies like Mimecast have to be relentless and in it for the long haul. This is a constant battle of cat vs. mouse between the Internet good guys protecting all of us from the bad guys out to steal our data, corrupt our systems or rob us plain and simple.
This is a worthy pursuit for any company, computer science graduate or expert. The world needs more smart, well-educated people worrying about security.
That’s why I’m particularly passionate about the need to get more young people, particularly women, interested in engineering at an early age. It may seem like an uphill battle. But there’s an encouraging shift visible in the emergence of targeted technology clubs and engineering toys designed to appeal to them from companies like Goldieblox, Roominate. Oh, and for the record, I’ve no financial interests in these firms or the toy industry. It’s just clear to me from my own experience as a parent and now grandparent, that if we inspire early, we can create the talent we need tomorrow.
by Orlando Scott-Cowley
Using the cloud to improve business agility is de rigueur but how can IT become more agile without sacrificing the information assurance holy trinity of confidentiality, integrity and availability?
My answer to this perceived quandary is based on the oldest risk management principle of all – one of ‘don’t keep all your eggs in one basket’, or more accurately, having two cloud vendors is better than having just one.
It’s a truism to say all clouds have outages, we must accept that fact, this strategy offers recovery options and alternative ways to continue communicating if the primary cloud provider is not available.
This question seems to have been at the root of a recent V3 Agile Business Roundtable.
Moving large workloads and services to the cloud is a major part of most agile business strategies but participants across a wide range of industries shared concerns about the security, reliability and adoption path to cloud computing. BSkyB enterprise architect Trevor Hackett also made the point that “When using a cloud service provider you have a vested interest in the company as if they go bust you face disaster.”
Before trusting sensitive assets to a cloud service provider, decision makers within an organization need a sound basis on which to evaluate the merits of a service offering. This should include an assessment of each Cloud Service Provider’s (CSP’s) service level agreement (SLA) terms, operational framework, architectural model, organizational history, stature within the industry, and the assurances granted to customers.
We have said many times before; reputable cloud service providers will be only too happy to help you understand how they serve and protect you and your data, and the importance of your own due diligence prior to purchase.
Office 365 adoption is a great example of the opportunity to improve agility and reduced cost of ownership with cloud services. But often CIOs don’t want to run the risk of critical business systems like core email services being outside of their immediate control. Email users have zero tolerance for downtime, and demand their connectivity be restored as quickly and painlessly as possible.
With on-premises Exchange, IT managers have choices about how they deal with planned or unplanned outages, and often put in place full disaster recovery and high availability solutions on-site. But with Office 365 that option no longer exists, and for many organizations, the fact that Office 365 is a single point of failure for such a mission critical service is a major concern, and a common roadblock for cloud migration.
But moving to the cloud doesn’t mean you should do away with a multi-vendor, multi-layered security strategy. A blended-cloud approach allows businesses to distribute important data between multiple vendors. It’s a truism to say all clouds have outages, we must accept that fact, this strategy offers recovery options and alternative ways to continue communicating if the primary cloud provider isn’t available. This exercise in risk management also supports smarter procurement by reducing the possibility of vendor lock-in. In short, you would be replicating the multi-point business continuity strategy you’ve built on the LAN, but in the cloud—a concept often overlooked during a cloud migration.
So in the end, a pragmatic approach to risk management on-premises and in the cloud will allow businesses to avoid the greatest risk of all – inaction and stagnation in increasingly agile business practices.
by Stuart Handley
Mimecast is aware of, and acting on the Poodle vulnerability affecting SSL version 3.0 (SSLv3). While SSLv3 is over 18 years old, support for it still remains very widespread. The Poodle attack is a client side attack (targeting the browser rather than the web server), using the “insecure fallback” behavior of browsers to negotiate the encryption down to SSLv3. The most effective way to prevent the Poodle attack is to disable SSLv3 support on the server side. That way a client cannot negotiate down to SSLv3. More information on Poodle can be found here on Google’s security blog.
Mimecast’s web services do currently support SSLv3, in order to offer maximum compatibility with customer systems, and this unfortunately makes our services potentially vulnerable to Poodle.
While we are working on disabling SSLv3 support on our public services, and expect to complete this soon, customers can immediately act against this vulnerability by disabling SSLv3 support in the browsers in use in their organizations.
This is highly recommended for employees who have Mimecast Administrators accounts on the Mimecast platform. You can find information on how to do this for the most common browsers on the vendor’s blogs or you might find this article helpful.
The Mimecast Security and Development Teams have prioritized the outstanding work required to eliminate SSLv3 support on all of our web applications and expect this to be completed in the short term.