Monthly Archives: January 2011

Defeating the Facebook Hack

This week, Facebook fell victim to hackers who managed to deface Mark Zuckerberg’s page, no doubt earning the perpetrators tremendous props within their own social community. Facebook quickly closed the door on that particular exploit, but by then of course the Internets were abuzz and the damage was done. The company quickly followed up with some unrelated security distractions: HTTPS, good for countering Firesheep (I love that name); social authentication instead of CAPTCHAs (this is actually interesting and plays to their strengths); and an announcement that this Friday is “Data Privacy Day” (Ouch).

Their aren’t many details available on the hack (the Guardian has a great investigation examining some of the clues that were left behind), but it appears that one particular API didn’t perform sufficient authorization on a POST. This is a common problem when you don’t make the configuration of basic security functions like AAA highly visible, auditable, and tunable. Leave security to the developers, and rigor is often overlooked because of a coder’s naturally intense focus on functionality. Decouple security out of the API, promoting security management to a first class citizen administered by internal experts—well, then you have a much greater chance to avoid embarrassing gaffs like this one. Consistency is the soul of good security, and the decoupling strategy makes consistency an achievable goal across all of an organization’s APIs. Specialize where necessary, but make everything highly visible to the experts so they can easily move from big picture to necessary minutia. Make security configuration highly declarative both to advance understanding and facilitate rapid change in response to evolving threats. This is how API management must be in 2011.

Facebook has its pick of the best and brightest these days—and they still face these problems. As other, less privileged organizations attempt to create APIs—and this is very much the trend of the day—we can expect to see many more such attacks. Having the CEO’s page defaced is certainly embarrasing. But in the long run, it’s a lot less expensive than a real privacy breach, or cleaning up from massive sustained fraud.

The time for do-it-yourself security and management of APIs has passed. This is the time to deploy professional solutions to the problem that have been proven out by the military, intelligence community, and health care—groups that have come to understand the best practices around API security out of absolute necessity.

To learn more, take a look at Layer 7 Technologies solutions for securing and managing APIs.


How to Choose a SOA Gateway

Dana Crane, Product Marketing Manager for Layer 7, is delivering a webinar this Thursday January 27 that tells you what you should consider when choosing a SOA Gateway. The SOA gateway category is a little like an iceberg, in that there is a lot more to it than first meets the eye. Here at Layer 7, we find that customers first become interested in SOA Gateways as a means to solve their security and transaction management problems. But they quickly discover that SOA Gateways can easily function as an Enterprise Service Bus (ESB), a service orchestration engine, a lightweight PKI system, a Security Token Service (STS), and even a service host for applications. We have a number of customers who have been able to discontinue expensive maintenance contracts on basic infrastructure applications simply because their SOA Gateway was able to meet all of their needs.

I hope you can join my colleague Dana later this week and learn more about what you need to look for in an SOA Gateway solution. Dana is one of the best product guys I know. He really understands the needs of the marketplace, and he keeps all of us here at Layer 7 honest. You can sign up for Dana’s webinar on the Layer 7 web site right here.

Hacking the Cloud

I’m not sure who is more excited about the cloud these days: hackers or venture capitalists. But certainly both groups smell opportunity. An interesting article published by CNET a little while back nicely illustrates the growing interest the former have with cloud computing. Fortify Software sponsored a survey of 100 hackers at last month’s Defcon. They discovered that 96% of the respondents think that the cloud creates new opportunities for hacking, and 86% believe that “cloud vendors aren’t doing enough to address cyber-security issues.”

I don’t consider myself a hacker (except maybe in the classical sense of the word, which had nothing to do with cracking systems and more about solving difficult problems with code), but I would agree with this majority opinion. In my experience, although cloud providers are fairly proficient at securing their own basic infrastructure, they usually stop there. This causes a break in the security spectrum for applications residing in the cloud.

Continuity and consistency are important principles in security. In the cloud, continuity breaks down in the hand-off of control between the provider and their customers, and potential exploits often appear at this critical transition.  Infrastructure-as-a-Service (IaaS) provides a sobering demonstration of this risk very early in the customer cycle. The pre-built OS images that most IaaS cloud providers offer are often unpatched and out-of-date. Don’t believe me? Prove it to yourself the next time you bring up an OS image in the cloud by running a security scan from a SaaS security evaluation service like CloudScan. You may find the results disturbing.

IaaS customers are faced with a dilemma. Ideally, a fresh but potentially vulnerable OS should first be brought up in a safe and isolated environment. But to effectively administer the image and load patch kits, Internet accessibility may be necessary. Too often, the solution is a race against the bad guys to secure the image before it can be compromised. To be fair, OS installations now come up in a much more resilient state than in the days of Windows XP prior to SP2 (in those days, the OS came up without a firewall enabled, leaving vulnerable system services unprotected). However, it should surprise few people that exploits have evolved in lock step, and these can find and leverage weaknesses astonishingly fast.

The world is full of ex-system administrators who honestly believed that simply having a patched, up-to-date system was an adequate security model. Hardening servers to be resilient when exposed to the open Internet is a discipline that is  time-consuming and complex. We create DMZs at our security perimeter precisely so we can concentrate our time and resources on making sure our front-line systems are able to withstand continuous and evolving attacks. Maintaining a low risk profile for these machines demands significant concentrated effort and continual ongoing monitoring.

The point so many customers miss is that cloud is the new DMZ. Every publicly accessible server must address security with the same rigor and diligence of a DMZ-based system. But ironically, the basic allure of the cloud—that it removes barriers to deployment and scales rapidly on demand—actually conspires to work against the detail-oriented process that good security demands. It is this dichotomy that is the opportunity for system crackers. Uneven security is the irresistible low-hanging fruit for the cloud hacker.

CloudProtect is a new product from Layer 7 Technologies that helps reconcile the twin conflicts of openness and security in the cloud.  CloudProtect is a secure, cloud-based virtual appliance based on RedHat Enterprise Linux (RHEL). Customers use this image as a secure baseline to deploy their own applications. CloudProtect features the hardened OS image that Layer 7 uses in its appliances. It boots in a safe and resilient mode from first use. This RHEL distribution includes a fully functioning SecureSpan Gateway – that governs all calls to an application’s APIs hosted on the secured OS. CloudProtect offers a secure console for visual policy authoring and management, allowing application developers, security administrators, and operators to completely customize the API security model based to their requirements. For example, need to add certificate-based authentication to your APIs? Simply drag and drop a single assertion into the policy and you are done. CloudProtect also offers the rich auditing features of the SecureSpan engine, which can be the input to a billing process or be leveraged in a forensic investigation.

More information about the full range of Layer 7 cloud solutions, including Single Sign-On (SSO) using SAML for SaaS applications such as and Google Apps, can be found here on the Layer 7 cloud solutions page.

Using SecureSpan Gateways for Traffic Distribution into Oracle OSB

The SERPLand blog talks about Layer 7 deployment as a load balancer in front of Oracle’s OSB product. We introduced a fully integrated OSB+SecureSpan appliance a couple of year’s ago for customers who want an easy way to deploy OSB securely into the DMZ.

Dilbert on Cloud Computing

Scott Adams nails it once again:

From January 7, 2011 Dilbert.


Over to You, Rush

Last week’s New York Times article on hacking the new gadgets, including Web-enabled HDTVs, generated an enormous amount of interest. An AM radio station in Tampa Bay, 970 WFLA AM, invited me onto their morning commuter show, AM Tampa Bay with Tedd Webb and Mark Larsen (standing in for Jack Harris). This was a great opportunity to reach a much wider audience than I usually speak to. So I woke up at 4am to an icy-cold Vancouver morning, and tried my best to imagine the sunshine and palm trees in far away Tampa.

It was a great, fast paced discussion. Tedd and Mark are the real thing—listening to the interview makes me wish I was born with that radio voice. Those guys are total pros.

After my five minutes of fame, the station filled the air for the rest of the day with the giants of conservative talk radio, including Glenn Beck, Rush Limbaugh, Sean Hannity, and Mark Levin.

You can listen to the interview here.

Is Web-connected TV the New Power Play for Hackers?

Over the holidays I had the fortune of being quoted in the New York Times. This came out of an interview I had with NYT writer Ashlee Vance about the recent discovery of security weaknesses in Web-connected HDTVs. Researchers at Mocana, a security services company in the Bay Area, identified a number of  vulnerabilities in one of the most popular Internet-enabled televisions. This is the first major security incident for a product category that is very likely to become wildly popular, but I doubt it will be the last.

In the hacking community, cracked systems equal power. Such power may be tangible, such as a botnet available for hire, or simply the social power derived from compromising a particularly high profile target. But as more interesting devices appear on the Internet—such as smart phones, TVs, and even refrigerators—there will be an inevitable shift in focus within the hacking community toward these. This is because these new devices represent enormous potential for the consolidation of new power.

The motivation to attack connected devices isn’t simply to target a new platform that might contain trivial vulnerabilities (though for some, this may be enough). The real attraction here is the sheer number of nodes; this, fundamentally, is about volume. It is estimated that  by the end of 2010, Apple will have shipped around 75 million iPhones. (To put this number into perspective, by July 2010, Microsoft announced it had shipped 150M units of Windows 7.) The iPhone alone represents an enormous injection of computing power onto the Internet, delivered over the course of only 3 1/2 years.

Now, the iPhone happens to be a remarkably stable and secure platform, thanks in part to Apple’s rigid curation of the hardware, software, and surrounding app eco-system. But what is interesting to note is how quickly a new Internet platform can spread, and how much of the total global computing horsepower this can represent. The consumer world, by virtue of its size, its fads and caprice,  its unprecendented spending power, can shift the balance of computing power in months (iPads, anyone?). Today the connected-device explosion centers around mobile phones, but tomorrow it can easily be web-connected TVs, smart power meters, or iToilets. This radical change to Internet demographics—from the servers and desktop, to things and mobile—will prove irresistible to the hacking community.

What is troubling about the vulnerabilities Mocona found is how simplistic these were. Device manufacturers must place far greater emphasis on basic system security. What will happen when the next wildly-popular consumer device is exposed to the full cutting-torch of hacker attention? It is going to be an interesting decade…