RSA Conference 2017 officially kicks off Monday, and once again it will bring several topics, trends and potential controversies to the center of attention of the information security industry. Unlike previous RSA conferences, this year it’s been harder to identify one or two major themes heading into the show. But there are several storylines I’ll be following closely at RSA Conference 2017, starting with these five:
1. Rise of the machine learning model
Machine learning has been a persistent buzzword in the infosec industry recently, and that should continue at this year’s RSA Conference. Vendors big and small have moved away from signature-based antivirus and antimalware products to embrace machine learning models that no longer rely on existing malware definitions to detect threats. The antivirus software market has come under heavy scrutiny lately, thanks to head-scratching security flaws and persistent questions about the software’s effectiveness. But it remains to be seen if advanced threat detection products leveraging machine learning will be the true heir apparent. There’s also considerable confusion around the differences between machine learning and artificial intelligence, thanks to vendors using the terms interchangeably. Hopefully this year’s show will provide some clarity.
2. DDoS denial
Distributed denial of services (DDoS) attacks have long been a thorn in the sides of many enterprises, but until recently DDoS attacks have typically been viewed as minor nuisances rather as than major threats. That may be changing in the wake of the powerful Mirai botnet attacks last year. Several vendors and service providers are poised to deliver new mitigation products to combat these potent DDoS attacks. But the attacks have also led to growing concerns about the insecurity of internet of things (IoT) devices as well as potential legal or regulatory actions that may follow those concerns; both subjects will be addressed at the conference. And it’s unclear whether the infosec industry as a whole will be ready when the next wave of record-setting DDoS attacks takes aim at critical internet infrastructure.
3. The Trump effect
RSA Conference has been home to controversies in the past, and this year’s show is likely to host yet another one. A number of technology companies, organizations and conferences have spoken out in recent days against President Trump’s controversial executive order barring entry into the U.S. for people from seven Muslim-majority Middle Eastern countries. In the week before RSAC 2017 several technology companies, including Microsoft, Google and Intel, signed an amicus brief opposing Trump’s executive order; RSA, however, was not on the list. RSA Conference said last week it has not been impacted by the executive order. But the conference will feature Rep. Michael McCaul (R-Tex.) as a keynote speaker Tuesday; McCaul, chairman of the Homeland Security Committee, was initially a strong supporter of Trump’s action, though he later qualified that support, and reportedly contributed to the executive order. McCaul has appeared at previous RSA Conferences and has spoken out against encryption backdoors, but his support of the controversial executive order could earn him criticism from some attendees.
4. RSA’s direction
RSA itself has undergone major changes recently. Not only has the security vendor done an about face with its product portfolio, leaving behind its legacy encryption business in favor of identity and access management, but it experienced another executive leadership change recently. Former RSA President Amit Yoran departed the company in December, just weeks before this year’s show, to take the CEO position at Tenable Network Security. Yoran was named RSA president in 2014 and took over from former RSA head Art Coviello during a turbulent period for the vendor (RSA was criticized over reported ties to the U.S. National Security Agency). While RSA quickly tapped Rohit Ghai, formerly president of Dell EMC’s Enterprise Content Division, to fill the void, Yoran’s departure comes at a time when RSA is still trying to establish its new identity and questions about the company’s future with Dell EMC (or as an independent entity or acquisition target) persist.
5. Cloud security shakeup
Setting aside recent activity from cloud giants like Amazon Web Services and Microsoft Azure, the cloud security market has been in rut in terms of innovation and excitement. Cloud access security brokers have dominated much of the attention in the market, but after a flurry of investments and acquisitions in 2015 and early 2016, even the CASB market has been quiet lately. But that may be changing as several CASBs have broadened their scope beyond protecting major SaaS applications and are now moving to address IaaS security. And that’s good news, considering the growing number of attacks either targeting cloud services or using them as command & control infrastructure for other targets. With the rush of cloud-focused products from traditional security vendors waning over the last year, a shot in the arm from CASBs could be just what the cloud security market needs.
In the past, the simple sharing of a Microsoft Word document with a colleague over email wasn’t cause for alarm. It wasn’t the kind of event that was regularly reviewed or even recorded by a security operations center.
Maybe it should’ve been. Regardless, in the age of rapid cloud adoption, such document sharing – even over email – is exactly the kind of event that, at least in theory, is monitored by today’s security operations centers (SOCs). And that’s become yet another problem on the growing list of security concerns for enterprises in the age of decentralized and mobilized IT environments.
Skyhigh Networks, a cloud access security broker, released its Q4 2016 Cloud Adoption and Risk Report earlier this month, and it included many data points one might expect: the number of cloud services used by the average enterprise, according to Skyhigh’s customer survey, continues to climb (1,427 services, currently); many of these cloud services still lack proper security controls (just 8.1% of those services meet Skyhigh’s Enterprise-Ready rating); and a growing percentage of files uploaded to cloud file sharing or collaboration services contain sensitive information (18.1%).
But the report also included surprising data on just how much cloud sharing and collaboration services are taxing security teams – even when there are no actual security incidents occurring. For example, according to Skyhigh’s survey, the average enterprise generates 2.7 billion cloud events per month (which includes everything from a file upload/download, document share and user logins).
But just 2,542 of those events on average are anomalous events, and an even smaller number – 23.2 – end up being actual security incidents. The Skyhigh report also states “Security teams widely report inaccurate breach notifications, resulting in alert fatigue and missed incidents.” In other words, the rapid growth of cloud file sharing and collaboration has sent the number of cloud events snowballing down a hill, and security teams are getting buried at the bottom.
“We hear a lot about alert fatigue. There are just so many cloud events and activities per month to monitor,” said Kamal Shah, senior vice president of products and marketing at Skyhigh. “All of those events go to the SOC, which just gets bombarded. They can’t keep up.”
The good news, of course, is just 23.2 of these monthly events constitute actual risks or threats to an enterprise (and even then, the incidents in question may be something as relatively simple as an accidental file exposure). The bad news is that even when things are working smoothly, security teams still struggle to stay above the water line because of the sheer volume of data they must monitor.
There are ways to address the problem, Shah said. User behavior analytics, for example, can help security teams better identify a potential threat and separate pertinent data from the rest of the noise. But, Shad said, companies need to start addressing the problem before they become paralyzed by the mountain of cloud events piling up on them.
“The number of cloud events is growing every quarter, and that makes it harder on enterprises because it’s just too much data,” he said. “And the number is only going to go up.”
There is certainly no shortage of infosec headlines mentioning some new Android malware threat. There are banking Trojans, malware that can root your phone, monitor your communication or steal your data. Given the frequency and bombast of the headlines, you might even think that Android is completely insecure and overrun by malicious apps. But this isn’t true for most in the Google world.
If you live in North America, Europe, Japan or Australia, your Android device almost certainly uses the Google Play Store for app discovery and installation. Malicious apps are sometimes found in the Play Store, but those are usually apps with little usage. Plus, Google often will have removed a malicious app from the Play Store by the time you see the news story about the risk.
Google’s statistics claim that 0.16% of the apps that users attempted to install from the Play Store in 2015 were found to be malicious. And various studies show that the average Android user only installs about one app per month. Basically, you really need to be unlucky to install a malicious app out of the 2.4 million available in the Play Store.
Going outside of the Play Store does bump up your risk factor, but there is still a process to installing a malicious app that news about Android malware tends to gloss over. The vast majority of Android malware is delivered to devices via “side loading,” which is to say the app has to be actively installed by the user outside of the Google Play Store environment. This is not a simple process.
In order to be able to side load an app, a user must first go into the device settings and turn on the option to install apps from “Unknown Sources” and tap OK on the dialog that pops up warning the user that side loading apps makes “your phone and personal data more vulnerable to attack.”
Then it is a matter of getting the malicious app onto a user’s device. Often, malware is hidden inside hacked versions of popular apps that are hosted on pirate download sites. So if a user wants to get a paid app for free, they might accidentally get malware as well. However, when a user attempts to install a malicious app, Google’s Verify Apps feature kicks in. Verify Apps will present the user with a warning at the time of install (which requires two taps to bypass) and even if a user confirms the installation, Verify Apps can remove apps that register as device admins or disable apps that “compromise the device security model.”
Of course, all of this assumes the user has an Android device with Google apps and services on it. Many devices sold in Russia, China and India do not have Google apps and services, which is why Android malware is far more prevalent in those regions.
But imagine the process of delivering malware to an Android device when needing to trick the user into downloading it: First, the user is deceived into downloading the malicious app. Then the user would have to find the app on the device (which could even require a file explorer app that is not always present on the device by default), attempt to install it and be warned that the installation cannot happen without changing the “Unknown Sources” setting. The user would have to change the setting, bypass that warning, attempt to install the app again, likely be warned again, bypass that warning and complete the install. At this point, depending on what version of Android the user has, this might mean approving the app permissions at the time of install; or, it might mean opening the app and approving permissions for the app to access the device storage. Even after all of that, Google’s Verify Apps might still step in and kill the app for you or Google’s Safety Net might catch the app attempting to contact a command and control server to download malicious code and shut that down.
That’s a complicated process that often gets ignored in the rush to put up a headline about some “dangerous” new Android malware. Just remember: a malicious app can’t appear on your device by magic. So, if you stick with established apps in the Google Play Store and avoid side loading apps, your chances of being infected by a malicious app are close to zero.
The cloud access security broker market has been keeping the U.S. Patent and Trademark Office busy.
SkyHigh Networks recently announced it obtained another patent for its CASB platform, the third such patent the company has been awarded since it was founded in 2011. SkyHigh’s announcement came shortly after rival Netskope announced it had been awarded a second patent for its own CASB platform.
SkyHigh’s most recent patent covers an “encryption key management system and method” for “an enterprise using encryption for cloud-based services.” The company’s technology features a hosted encryption service or gateway that can handle clients’ encrypted data as it moves to and from cloud services. Rather than enterprises having to send user traffic to cloud applications through an on premise encryption gateway, SkyHigh’s platform handles the process in the cloud.
From the patent abstract: “The network intermediary receives the encryption key material from the enterprise and stores the encryption key material in temporary storage and uses the received encryption key material to derive a data encryption key to perform the encryption of the enterprise’s data. In this manner, the enterprise can be provided with the added security assurance of maintaining and managing its own encryption key while using cloud-based data storage services.”
SkyHigh’s approach for securely managing the encryption keys involves several steps, according to the patent, including the generation of original key material using a key agent deployed within the enterprise network; storing the original key material on the key agent in a temporary memory; using the key agent to request a hardware security module to encrypt the original key material, which the HSM does using the using an enterprise owned and managed encryption key that is available only within the enterprise data network, and so on (for the full process, read the patent description).
If that sounds like a complicated process, that’s because it is. So why is it beneficial to have the encryption gateway hosted in the cloud rather than on the enterprise’s own network? Kaushik Narayan, co-founder and CTO of Skyhigh Networks, said there are operational hurdles to that method. “Previously, enterprises would have to use on premise encryption and key management for data in the cloud,” he said. “But if you’re on the road or outside the corporate network, you would need a VPN to get access to that data. That can make using cloud services a lot more difficult.”
Narayan stressed that SkyHigh’s patented approach doesn’t involve taking ownership of encryption keys from enterprises. “The keys are still owned and kept by the customers,” he said. “The idea behind the patent is to cover the acquisition and distribution of those keys.”
Other CASBs such as CipherCloud use similar hosted encryption approaches, so it remains to be seen if there will be any overlap or potential friction with SkyHigh’s patent. But the flurry of patents awarded to competing startups in the CASB space show just how quickly the market is evolving, and how valuable intellectual property in the CASB market can be.
The patent also further demonstrates how crucial encryption is to the CASB model in particular and cloud security in general. Narayan said SkyHigh, which last month announced $40 million in series D financing, has put greater focus on encryption because of customer demand.
“Encryption is a core component of the CASB model. Fundamentally where this all started is with customers in certain verticals like financial services and healthcare, as well as businesses in certain regions with strict regulatory concerns,” Narayan said. “When these customers put third party customer or citizen data in the cloud, they have to — for a variety of compliance reasons — protect that data.”
The struggling antivirus software industry has been in the news lately for all the wrong reasons.
To recap, Google’s Project Zero has discovered and disclosed a flurry of head-scratching vulnerabilities in many leading antivirus products. The most serious of these included critical flaws in the core engine of Symantec’s flagship antivirus software. To add insult to injury, the discovery of these Symantec vulnerabilities revealed a shocking design flaw in its products: the antivirus engine was loading itself in the Windows kernel to scan malware.
Bringing potentially malicious code in the Windows kernel is like putting Ozzy Osborne in a roomful of doves and hoping he’ll be on best behavior. The Symantec episodes were a sad reminder of the woeful state of the antivirus industry.
And now the beleaguered antivirus industry is back in the spotlight once again. This time, however, it’s not the fault of the security vendors.
Many top antivirus programs have been rendered useless on Microsoft systems that installed the Windows 10 Anniversary update. Users have reported problems with Kaspersky Lab, Intel Security, Avast and others, ranging from features being disabled in the AV programs to systems crashes and blue screens of death. Microsoft confirmed that the problem is with the Windows 10 Anniversary update’s compatibility checks, and expects a patch to be issued in September (Kaspersky has released its own temporary fix for the problem).
While the antivirus industry has been on the decline lately, Microsoft depends heavily on these products to protect Windows systems from the waves of malware flooding cyberspace. No enterprise worth its salt would allow its employees to rely solely on Windows’ own embedded security features to protect their systems. So one would expect that Microsoft would take extra care in making sure its update would be compatible with programs and not leave systems without proper security protection.
But apparently that didn’t happen. And the reason, according to Intel Security’s advisory, is pretty upsetting:
“The intent was to have upgrade and installation checks implemented in the Windows 10 Anniversary Update to ensure that no incompatible McAfee product versions could be installed or present. Because of time constraints, these checks could not be implemented prior to the release of the Windows 10 Anniversary Update on August 2, 2016.”
Time constraints? I find it hard to believe that Microsoft didn’t have the resources available to implement these checks and avert this headache. Antivirus vendors have had a hard enough time fighting threat actors and their own lackluster product quality. They really don’t need a third adversary in the ring with Microsoft.
Netskope recently obtained a second cloud security patent for its CASB platform, one that could prove extremely beneficial in an increasingly competitive cloud security market that puts a premium on intellectual property.
The CASB startup was awarded another patent earlier this year for technology that “steers” enterprise traffic to cloud applications and provides real time visibility for those apps.
The new patent covers Netskope’s technology that provides granular data governance and security policy enforcement on cloud applications. Netskope CEO Sanjay Beri called it a “broad patent” that covers the ability to set policies for cloud app usage based on a number of variables, including device type, user profile, behavioral analytics and, perhaps most importantly, what data is being accessed in that cloud app and what is being done with it.
“This is the other side to the approach,” Beri said. “The first patent was about steering traffic to control points. That’s how you get the traffic to the cloud services. The second patent is about what you do with the traffic when it gets there.”
Netskope’s policies, which customers themselves set, are able to distinguish between downloading, modifying and viewing data within cloud apps. For example, Beri said a retail customer concerned about cloud data being accessed by unmanaged personal devices could create a policy for an app’s data that allows users to view the data but not download it.
Beri said the power of the new patent is the technology’s ability to give enterprises the proper context in how their cloud apps can and will be used. Most web application firewalls use basic “block or allow” policies, he said, but CASBs like Netskope can provide more insight and control around how a cloud app and the corporate data tied to it are being used.
Technology patents don’t usually make for exciting news, but in the case of the CASB market, they provide insight into how startups have evolved – and how they’re being valuated by investors and suitors. CASBs have evolved from offering basic visibility into shadow cloud usage to providing secure gateways to cloud apps as well as access control, data protection and threat monitoring. As these CASBs have evolved and matured, they’ve patented their unique approach and developed intellectual property (IP) for those sets of services.
And those patents have proven to be valuable – perhaps more so than customer base or revenue – to potential suitors. Blue Coat Systems’ recent S1 filing for a potential IPO revealed that Perspecsys, a CASB startup acquired by Blue Coat last summer for $45.5 million, had posted revenue of just $2 million for the first half of 2015. But Michael Fey, then Blue Coat’s president and COO, said the Perspecsys deal was about obtaining the startup’s patent for tokenization technology in the cloud.
Similarly, Blue Coat acquired another CASB last November in Elastica, which, according the Blue Coat’s S1, generated just $395,000 in revenue between January and November of 2015. Yet Elastica was able to command a purchase price of $280 million, thanks in large part to its IP and patent-pending tech.
Beri said Netskope recognizes how valuable IP and patents are in the security industry, which is why they’re doubling down on research and development. “We have the largest R&D team in the CASB market,” he said. “So you’ll see more patents for us in the future.”
Outside of command line tutorials for Linux, the term “environment variable” increasingly appears right next to “security vulnerability.” Consider Shellshock — one of the worst exploitable flaws ever — which requires little more work than attaching malicious code onto an environment variable. More recently, the httpoxy vulnerability also leverages access through the HTTP_PROXY environment variable.
Are environment variables for suckers? Do we even need them anymore? Can we afford them?
SearchSecurity asked several experts whether it might be time to ditch environment variables, given that they enable vulnerabilities like Shellshock and httpoxy, or whether there are benefits to keeping them on hand.
“Environment variables are an essential part of how things run under unix/linux systems,” explained John Bambenek, manager of threat systems at Fidelis Cybersecurity in Waltham, Mass. Many environment variables are innocuous — for example, the PATH environment variable lists the directories in which the shell looks for binaries when a command is entered at the command line.
However, Bambenek said, “The problem is allowing the open internet to modify environment variables of significance — like HTTP_PROXY — that have real impact on those running applications. Accepting unauthenticated input from the world is always a very dangerous thing, reading that data into an environment variable that has real impact on the system is extremely dangerous,” and that’s what happened with the httpoxy vulnerability.
“I’m not sure how we do things without environment variables,” said Jacob Williams, founder of consulting firm Rendition InfoSec LLC, in Augusta, Ga. “They are a source of vulnerabilities, but not having them creates a whole new class of problems we’ll have to account for in the long run. I don’t know what the solution will be, but it will also create new vulnerabilities. It’s not the variables themselves, it’s the insecure use of the variables that creates problems.”
Deciding on whether it’s time to stop using environment variables depends on where they are used, according to Bill Berutti, president, performance & analytics and cloud management/data center automation, at business service management software firm BMC, based in Houston.
“For an enterprise application, it is always a good practice to pass on variables for the session of the process and not set in the environmental variables. This is a much better approach,” Berutti explained. “Nevertheless, environmental variables are useful in case of test/stage applications where there are a lot of clone applications being run on the same box to test out applications in parallel and/or it’s something standardized for all the applications running on that node.”
“There is nothing inherently wrong with environmental variables,” said Christopher Robinson, manager at Red Hat’s product security program management. Cloud services, for example, often use environment variables to distribute configuration data, though Robinson warned “programmers should always be cautious as to what data their programs accept and use for subsequent processing/directives.”
There’s no real security benefit to using environment variables, according to Lane Thames, security researcher at Tripwire Vulnerability and Exposures Research Team (VERT). “Regardless of where the data comes from (environment variable, database query, et cetera), it is up to the application that uses the data in the variables to ensure correctness and compliance.”
“I don’t know that we can without boiling the ocean,” said Dominic Scheirlinck, principal engineer at Auckland, New Zealand e-commerce firm Vend. “They’re in every new [platform as a service] and [continuous integration] system because they work well for simple, easy-to-use configuration.”
Scheirlinck, who is also the lead for the httpoxy disclosure team, added “I think it’s more likely that we should be much more careful, in the future, about accepting specs,” like the common gateway interface (CGI) specification, “that allow environment variables to be controlled by remote users.”
It’s becoming harder and harder for me to read about the glaring security holes, the bafflingly risky behaviors and the all-around worst practices of the healthcare industry and still maintain some semblance of composure and mental health. It feels as if each new study or research paper on healthcare security is pushing me closer to the point where I’ll be more terrified of seeing doctors using an outdated Windows XP client than watching them approach me with a scalpel or six-inch hypodermic needle. Or both.
Case in point: a study from researchers at Dartmouth College, the University of Pennsylvania and the University of Southern California has garnered media attention recently, as it shows the lengths doctors, nurses and clinicians will go to bypass security controls and authentication measures, which many view as impediments to their jobs. “Workarounds to computer access in healthcare are sufficiently common that they often go unnoticed,” the study reads. “Clinicians focus on patient care, not cybersecurity.”
The title of the paper – “Workarounds to Computer Access in Healthcare Organizations: You Want My Password or a Dead Patient?” – offers a big hint about the mentality of medical professionals when it comes to the topic of information security. The study, in which researchers interviewed and observed hundreds of medical workers, at different hospitals and medical centers, showed how doctors, nurses and other medical professionals are so desperate to avoid cumbersome login and authentication processes that they will resort to almost absurd practices to get around them.
But in case the title and summary aren’t enough, here are some points from the study:
- “Clinicians share passwords with others so that they can read the same patients’ charts even though they might have access in common. A misbehaving hospital technician used a physician’s PIN code to create fake reports for patients.”
- The study documented “physicians ordering medications for the wrong patient because a computer was left on and the doctors didn’t realize it was open for a different patient.”
- “Nurses would circumvent the need to log out of COWs [computers on wheels] by placing “sweaters or large signs with their names on them” or hiding them or simply lowering laptop screens.”
- The study cited a previous report about how “clever clinicians at one hospital defeated proximity sensor-based timeouts by putting Styrofoam cups over the detectors, and how (at another hospital) the most junior person on a medical team is expected to keep pressing the space bar on everyone’s keyboard to prevent timeouts.”
- “One vendor even distributed stickers touting ‘to write your username and password and post on your computer monitor.’ A newspaper found a discarded computer from a practice contained a Word document of the employees’ passwords — conveniently linked from a desktop icon.”
Medical professionals, however, don’t bear the full blame for these terrible healthcare security practices. The study points out how some of the inadequate IT systems used in hospitals can promote this kind of delinquency. For example, the paper cites an example of a physician who uses the clinic’s dictation system – which has a five-minute session timeout and requires users to re-authenticate (which takes approximately one minute) to log back in; the physician told the researchers he spent nearly an hour-and-a-half logging in one day.
Another example involved a large city hospital, which required a digital thumbprint to authenticate each death certificate. But only one of the doctors on staff had thumbs that could be read by the digital reader. “Consequently, only that one doctor signs all of the death certificates, no matter whose patient the deceased was,” the report stated.
Still, however dysfunctional the technology and legacy systems at hospitals are, these access and authentication workarounds are just more examples of how easy the healthcare industry makes it for attackers to breach their networks. Attacks on hospitals and healthcare organizations are on the rise, and we’ve seen repeated examples of how vulnerable hospitals are to such attacks. It’s time the healthcare industry to address these counterproductive behaviors and woeful technology before the medical records and personally identifiable information of every U.S. citizen becomes public domain — if they aren’t already.
Symantec’s surprise announcement this week that it had agreed to acquire Blue Coat Systems for a whopping $4.65 billion in cash led to much discussion about how the purchase will affect the beleaguered antivirus giant, which has experienced well-documented struggles and setbacks in recent years. But there’s been much less focus on Blue Coat — how the company arrived at this point, and how much its investments in cloud security, specifically the cloud access security broker space, have benefited Blue Coat.
First, let’s go back in time and look at some numbers. During Blue Coat’s last full fiscal year as a public company (ended April 30th, 2011), the company posted was $487 million in revenue. In the announcement for its FY 2011 financials, then-CEO Mike Borman didn’t mince words about the disappointment around those results. “I am not satisfied with our revenue performance, as we did not deliver the top-line results that I believe we are capable of,” he said.
Later that year, private equity firm Thoma Bravo acquired Blue Coat for $1.3 billion. At that point, Blue Coat’s focus was on the WAN optimization market (Borman highlighted the company’s MACH5 technology and PacketShaper products as bright spots in the otherwise lackluster FY 2011 results) rather than cloud security. Fast forward to March of 2015, and Thoma Bravo sold Blue Coat to Bain Capital for $2.4 billion (Thoma Bravo reportedly had talks to sell the company to Raytheon the previous year).
Fast forward again to this month, and Bain sold Blue Coat for almost twice what it had paid for the company about a year earlier. So what changed over those 15 months? Blue Coat has obviously strengthened its presence in the web security gateway market in recent years (the company is routinely listed as a market leader by analyst firms such as Gartner and IDC). But the vendor also made some aggressive acquisitions of its own last year in the CASB market, starting with the purchase of Perspecsys, a startup based in McLean, Va., in July (terms of the deal were not disclosed). And just a few months later, Blue Coat acquired another CASB startup, paying $280 million for San Jose-based Elastica. And Blue Coat isn’t the only company getting in on the CASB market, as Microsoft bought Adallom for a reported $320 million.
Why did Blue Coat acquire two CASBs? As Blue Coat COO Michael Fey explained to SearchCloudSecurity last year, Elastica and Perspecsys had distinctly different approaches to the CASB model. Perspecsys offered patented tokenization technology to protect corporate data moving to and from cloud applications, while Elastica’s platform concentrates on SaaS monitoring and usage analysis. Blue Coat began integrating both CASB offerings with its web security gateway products under the company’s “Cloud Generation Gateway” strategy.
Both acquisitions appear to have benefited the company, which is now seen as a leader in the CASB space. Several analysts have applauded the move as a way to bolster Symantec’s presence in the cloud security market. Barron’s, for example, noted that while 80% of Blue Coat’s revenue comes from the slower-growing web security gateway market while the remaining 20% comes from the “more promising” CASB space.
It’s impossible to determine how much value the CASB deals have added to Blue Coat, as the company is privately held. But clearly Blue Coat has become a hotter commodity than it was when the company changed owners last year; it’s worth noting that less than two week before Symantec paid $4.65 billion for the company, Blue Coat announced plans for an IPO (according to Business Insider, the company filed its IPO plans under the JOBS Act, which allows smaller businesses to file for IPOs privately with the SEC). But Symantec — apparently sensing some urgency — snatched up Blue Coat before the IPO could take place.
Time will tell if the acquisition turns out to be a success, let alone the transformational move Symantec needs to move beyond its legacy antivirus business. For now, however, it looks like the CASB acquisitions were lucrative investments Blue Coat, and I’d expect interest in the market from IT vendors and enterprises alike to continue to grow.
Last week, Google showed off a new messaging app called Allo. The reaction to that announcement was either extremely positive or negative, depending on who was speaking. General consumers liked the product because it built Google smarts into a messaging app, while privacy proponents decried the fact that end-to-end encryption was not a default feature of the app.
Edward Snowden even weighed in on the matter:
Google’s decision to disable end-to-end encryption by default in its new #Allo chat app is dangerous, and makes it unsafe. Avoid it for now.
— Edward Snowden (@Snowden) May 19, 2016
Yes, the way that Allo is designed does leave a small point of access for a court order — Google servers can read messages in order to offer smart replies and contextual search data before immediately deleting the message. But Snowden’s assertion that this somehow makes the app “dangerous” and “unsafe” is hyperbolic at best, and at worst it makes it clear that Snowden has forgotten that not everyone on Earth is a fugitive from the law.
The choice doesn’t need to be a strict binary of safe/unsafe depending on if encryption is the default, because if that becomes true there’s no way to evolve messaging services. Google is in a unique position where the company is pushing artificial intelligence and machine learning, features that simply don’t work without access to data. Google may only want to add search results and suggestions to chat, and enterprise security relies on AI and machine learning for behavioral analytics and advanced malware detection. These features cannot exist in a world where encryption is the default.
Aside from that, the idea that a lack of encryption is the same as a lack of security ignores the fact that encryption was never designed to be the default. The aim of encryption was always to protect sensitive data, not to protect every word communicated between two parties. In this vein, Allo is the true expression of encryption — when you’re talking about restaurants, you can get Google suggestions because the chat is unencrypted, but when you’re talking about something sensitive (the definition of which is personal to everyone), you can switch to Incognito mode in order to be “safe” (as Snowden defines it) from the government’s prying eyes.
The aim of the encryption debate should be to make users aware of how to protect themselves and the ways that security is vulnerable either to legal orders or hackers. Pushing the idea that encryption is the only form of safety is both antithetical to how the technology is supposed to work and a gross simplification of what users want and need from that technology.