Q: Tal, Adallom was named by "CRN" as one of the "10 Coolest Security Startups of 2013." That's quite a compliment. As a newcomer to the space, what makes Adallom so "cool." What differentiates you from the other security firms?
Tal Klein: I think there are really three factors that play into the attention we've been getting.
The first is that companies are moving from the exploratory phase of their cloud strategies into the adoption phase. What we're seeing is CIOs officially sanctioning cloud applications like Office 365, Google Apps, Box, Successfactors, Salesforce, and even Dropbox and Evernote. So the evolution of the IT philosophy towards SaaS has shifted from treating something like Salesforce as "Shadow IT" into "Sanctioned IT." This is important because up until now I think IT was still trying to grapple with problems like provisioning (and more importantly deprovisioning) access to applications that it did not control. But that problem was solved by the IAM people (like Okta, Ping, Centrify, and OneLogin). So now that SaaS applications are becoming sanctioned, IT has a really urgent need for extending its purview into these applications – and what I mean by that is today when you use an app like Salesforce, the administrator has very little visibility into the actual usage of the application. There are both security and regulatory ramifications for this lack of visibility and control which fall under the "shared responsibility model." Salesforce is responsible for the security of their platform and the customer is responsible for the security of the users using the platform and, more specifically, the security of the data which is accessible and controlled by the customer's users. So if a Salesforce user is compromised -- say, phished -- how would you know? Salesforce has no accountability nor liability for informing you that the entity with a user's credentials is not in fact that user. So you are accountable for whatever happens in that context, and your company is liable for any data exfiltration or regulatory infraction. But you don't have the visibility or control to do anything about it. So that's what we call the "SaaS security gap" and it's precisely where Adallom helps. We extend IT purview to SaaS applications without getting in the end-user's way.
The second factor which we attribute to our success is the acceptance among IT leaders that BYOD, mobility, and cloud are all part of a single trend that requires an operational pivot. Forcing all users to interact with corporate data exclusively through a virtual desktop, VPN, or managed device has been proven to be untenable. So IT is coming to terms with the fact that users are interacting with corporate data on unmanaged devices over insecure networks. Sounds obvious, but it's actually been a battle of sorts within IT. We all know at least one IT ops guy who thinks end-users must follow corporate policy because, if they don't, they'll get fired. But the person is wrong, because the first people to violate policy are executives, and nobody is going to fire the VP of sales for violating IT policy -- say, sending a contract over Google Drive on their phone in order to close a deal. So there's been this trickle-down acceptance of essentially treating every user as an executive – accepting that VDI, MDM, EMM, VPN are all ineffective controls for mobile users on unmanaged devices accessing corporate data in cloud applications over insecure networks. Some people have been calling this "user-centric IT," but I think the users are not what IT needs to worry about. Our approach complements "data-centric IT" since IT needs to focus on protecting data wherever it lives and however people interact with it. So, as corporate data moves to the cloud, Adallom is nicely positioned to help IT satisfy the company's needs for information governance in the cloud without endpoint agents or devices in the data center.
Lastly -- and this is probably the biggest factor for the attention we've been getting -- existing perimeter (Firewalls, IPS) and endpoint protections (AV, Sandboxes) are completely useless when it comes to protecting privileged data in cloud services. Perimeter controls fail because, as I mentioned, users are interacting with data outside of the perimeter. A firewall cannot see what is not in its path. AV and Sandboxes look for things like malware and APTs but can't do anything against a garden-variety phishing attack. Protection-wise, we are entering the age of context. The technology Adallom was built on was originally designed to detect online behavioral patterns associated with terrorist activity. We have several pending patents in machine-learning and anomaly detection and are essentially repurposing tech that was designed to save lives into a solution that protects enterprise data. Once we establish a user's behavioral standard deviation, we can tell whether they are compromised in less than five clicks (or transactions). We can also detect for behavioral anomalies associated with intentional or unintentional data exfiltration -- for example, if a user is sharing all of their corporate files on Box with their personal email address.
Together these three factors give us an innovative edge over other players in what Gartner's been calling the "Cloud Access Security Broker" market. And they gave us the Cool Vendor nod in the Infrastructure Protection category because they recognize that the boundaries of infrastructure now must include cloud services.
Q: Ami, just a few months ago, Adallom discovered and reported a token hijacking vulnerability bug in Microsoft Office 365. The identity theft vulnerability in Office 365, found in the wild, allowed attackers to grab user identities and steal e-mail and documents. How was Adallom able to detect the bug … and what sort of solution do you provide your clients to keep them safe?
Ami Luttwak: Yes, the "Ice Dagger" attack, MS13-104. I'm glad you chose this one to ask about because it was the first exploit we found in the wild – it's a token hijack with extra cruft. We caught it in our very first customer last year, so there was a lot of second guessing because we wanted to be absolutely sure that what we found was a real live attack. Basically, what we saw was an Office 365 user requesting a document from a TOR hidden service under the onion.to TOR gateway. While we monitor and flag all requests performed against known TOR gateways, this specific request was performed by an Office component (Word) rather than the user. The Adallom engine freaked us out a bit because it reacted by disabling ALL corporate user access to Office 365, not just the affected user. In retrospect, we realized the reason was that the malicious behavior was being attributed to the application rather than the user, so it was doing the right thing – but, at the time, it looked like a giant false positive. To put things in context, it's the only time we've ever seen the engine react to an event by blocking access to an entire SaaS application rather than an individual user. It's a credit to our R&D team for designing a heuristics engine that assumes humans and applications are equally susceptible to flaw. By the way, I want to give a shout to the Microsoft Security Response Team; they were great to work with, and upon confirmation of the attack and resolution, they added us to their advanced protections program (MAPP) because we were the only vendor who they identified as being capable of thwarting this class of attacks. Noam Liran, our chief security architect, wrote a great blog about the work that went into deconstructing this attack.
Q: You are sponsoring a workshop at Black Hat USA 2014. Tell me a little about the topic and what will be the biggest takeaway for attendees?
Luttwak: Yes, it's a very hands-on workshop designed by Adallom Labs, our R&D forensics team. We're going to show attendees some real-life attacks against enterprise Software-as-a-Service applications in order to explore the nooks and crannies of the shared responsibility model. The ubiquitous accessibility and extensibility of SaaS applications has unveiled many new attack vectors. We will explore and contrast "SaaS attacks" vs. traditional attacks, and cover various attack vectors, from application exploits, to protocol vulnerabilities, and, of course, end-user attacks. For example, we'll show attendees why the mechanics of the recent Google data URI scheme which allows attackers to include data in-line in Web pages as if they were external resources merits a lot more attention than it's been getting. The scheme uses Base64 encoding to represent file contents, in this case supplying the content of the fake Web page in an encoded string within the data URI; the attack is invisible even to Google itself. That's just one example. We'll also be covering token hijacks, Oauth MIMs, and more. The goal is to arm infosec pros with the right tools to assess the security postures of SaaS vendors their companies do business with. I think it's going to be a lot of fun.
Join us in our workshops and visit our booth to see a live demonstration and how these solutions can help enable a secure enterprise.