Research

As we have mentioned throughout this series, the purpose of a WAF is to protect web facing applications from attacks. We can debate build-security-in versus bolt-security-on ad infinitum, but ultimately the answer is both. In the last post we discussed how to build and maintain WAF policies to protect applications, but you also need to adapt your development process to incorporate knowledge of typical attack tactics into code development practices to address application vulnerabilities over time. This involves a two-way discussion between WAF administrators and developers. Developers do their part helping security folks understand applications, what input values should look like, and what changes are expected in upcoming releases. This ensures the WAF rules remain in sync with the application. Granted, not every WAF user will want to integrate their application development and WAF management processes. But separation limits the effectiveness of both the WAF and puts the application at risk. At a minimum, developers (or the DevOps group) should have ongoing communications with WAF managers to avoid having the WAF complicate application deployment and to keep the WAF from interfering with normal application functions. This collaboration is critical, so let’s dig into how this lifecycle should work. Web applications change constantly, especially given increasingly ‘agile’ development teams – some pushing web application changes multiple times per week. In fact many web application development teams don’t even attempt to follow formal release cycles – effectively running an “eternal beta cycle”. The team’s focus and incentives are on introducing new features as quickly as possible to increase customer engagement. But this doesn’t help secure applications, and poses a serious challenge efforts to keep WAF policies current and effective. The greater the rate of application change, the harder it is to maintain WAF policies. This simple relationship seriously complicates one of the major WAF selling points: its ability to implement positive security policies based on acceptable application behavior. As we explained in the last post, whitelist policies enumerate acceptable commands and their associated parameters. The WAF learns about the web applications it protects by monitoring user activity and/or by crawling application pages, determining which need protection, which serve static and/or dynamic content, the data types and value ranges for page variables, and other aspects of user sessions. If the application undergoes constant change, the WAF will always be behind, introducing a risky gap between learning and protecting. New application behavior isn’t reflected in WAF policies, which means some new legitimate requests will blocked, and some illegal requests will be ignored. That makes WAF much less useful. To mitigate these issues we have identified a set of critical success factors for integrating with the SDLC (software development lifecycle). When we originally outlined this process, we mentioned the friction between developers and security teams and how this adversely effects their working relationship. Our goal here is to help set you on the right path and prevent the various groups from feuding like the Hatfields and McCoys – trust us, it happens all to often. Here’s what we recommend: Executive Sponsorship: If, as an organization, you can’t get developers and operations in the room with security, the WAF administrators are stuck on a deserted island. It’s up to them to figure out what each application is supposed to do and how it should be protected, and cannot keep up without sufficient insight or visibility. Similarly, if the development team can say ‘no’ to the security team’s requests, they usually will – they are paid to ship new features, not to provide security. _So either security **is* important, or it isn’t._ To move past a compliance-only WAF, security folks need someone up the food chain – the CISO, the CIO, or even the CEO – to agree that the velocity of feature evolution must give some ground to address operational security. Once management has made that commitment, developers can justify improving security as part of their job. It is also possible – and in some organizational cultures advisable – to include some security into the application specification. This helps guarantee code does not ship until it meets minimum security requirements – either in the app or in the WAF. Establish Expectations: Here all parties learn what’s required and expected to get their jobs done with minimum fuss and maximum security. We suggest you arrange a sit-down with all stakeholders (operations, development, and security) to establish some guidelines on what really needs to happen, and what would be nice to have. Most developers want to know about broken links and critical bugs in the code, but they get surly when you send them thousands of changes via email, and downright pissed when all requests relate to the same non-critical issue. It’s essential to get agreement on what constitutes a critical issue and how critical issues will be addressed among the pile of competing critical requirements. Set guidelines in advance so there are no arguments when issues arise. Similarly, security people hate it when a new application enters production on a site they didn’t know existed, or significant changes to the network or application infrastructure break the WAF configuration. Technically speaking, each party removes work the other does not want to do, or does not have time to do, so position these discussions as mutually beneficial. A true win-win – or at least a reduction in aggravation and wasted time. Security/Developer Integration Points: The integration points define how the parties share data and solve problems together. Establish rules of engagement for how DevOps works with the WAF team, when they meet, and what automated tools will be used to facilitate communication. You might choose to invite security to development scrums, or a member of the development team could attend security meetings. You need to agree upon a communication medium that’s easy to use, establish a method for getting urgent requests addressed, and define a means of escalation for when they are not. Logical and documented notification processes need to be integrated in the application development lifecycle to ensure

To get value out of your WAF investment – which means blocking threats, keeping unwanted requests and malware from hitting applications, and virtually patching known vulnerabilities in the application stack – the WAF must be tuned regularly. As we mentioned in our introduction, WAF is not a “set and forget” tool – it’s a security platform which requires adjustment for new and evolving threats. To flesh out the process presented in the WAF Management Process, let’s dig into policy management – specifically how to tune policies to defend your site. But first it’s worth discussing the different types of polices at your disposal. Policies fall into two categories, blacklists of stuff you don’t want – attacks you know about – and whitelists of activities that are permissible for specific applications. These negative and positive security models complement one another to fully protect applications. Negative Security Negative security models should be familiar – at least from Intrusion Prevention Systems. The model works by detecting patterns of known malicious behavior. Things like site scraping, injection attacks, XML attacks, suspected botnets, Tor nodes, and even blog spam, are universal application attacks that affect all sites. Most of these policies come “out of the box” from vendors, who research and develop signatures for their customers. Each signature explicitly describes an attack, and they are typically used to identify attacks such as SQL injection and buffer overflows. The downside of this method is its fragility – any variation of the attack will no longer match the signature, and will thus bypass the WAF. So signatures are only suitable when you can reliably and deterministically describe an attack, and don’t expect the signature to immediately become invalid. So vendors provide a myriad of other detection options, such as heuristics, reputation scoring, detection of evasion techniques, and several proprietary methods used to qualitatively detect attacks. Each method has its own strengths and weaknesses, and use cases for which it is more or less well suited. They can be combined with each other to provide a risk score for incoming requests, in order to block requests that look too suspicious. But the devil is in the details, there are literally thousands of attack variations, and figuring out how to apply policies to detect and stop attacks is quite difficult. Finally, fraud detection, business logic attack detection, and data leakage policies need to be adapted to the specific use models of your web applications to be effective. The attacks are designed to find flaws in the way application developers code, targeting gaps in the ways they enforce process and transaction state. Examples include issuing order and cancellation requests in rapid succession to confuse the web server or database into revealing or altering shopping cart information, replaying attacks, and changing the order of events. You generally need to develop your own fraud detection policies. They are constructed with the same analytic techniques, but rather than focusing on the structure and use of HTTP and XML grammars, they examine user behavior as it relates to the type of transaction being performed. These policies require an understanding of how your web application works, as well as appropriate detection techniques. Positive Security The other side of this coin is the positive security model: ‘whitelisting’. Yes, this is the metaphor implemented in firewalls. First catalog legitimate application traffic, ensure you do not include any attacks in your ‘clean’ baseline, and set up policies to block anything not on the list of valid behaviors. The good news is that this approach is very effective at catching malicious requests you have never seen before (0-day attacks) without having to explicitly code signatures for everything. This is also an excellent way to pare down the universe of all threats into a smaller, more manageable subset of specific threats to account for with a blacklist – basically ways authorized actions such as GET and POST can be gamed. The bad news is that applications are dynamic and change regularly, so unless you update your whitelist with each application update, the WAF will effectively disable new application features. Regardless, you will use both approaches in tandem – without both approaches workload goes up and security suffers. People Manage Policies There is another requirement that must be addressed before adjusting polices: assigning someone to manage them. In-house construction of new WAF signatures, especially at small and medium businesses, is not common. Most organizations depend on the WAF vendor to do the research and update policies accordingly. It’s a bit like anti-virus: companies could theoretically write write their own AV signatures, but they don’t. They don’t monitor CERT advisories or other source for issues to protect applications against. They rarely have the in-house expertise to write these policies even if they wanted to. And if you want your WAF to perform better than AV, which generally addresses about 30% of viruses encountered, you need to adjust your policies to your environment. So you need someone who can understand the rule ‘grammars’ and how web protocols work. That person must also understand what type of information should not leave the company, what constitutes bad behavior, and the risks your web applications pose to the business. Having someone skilled enough to write and manage WAF policies is a prerequisite for success. It could be an employee or a third party, or you might even pay the vendor to assist, but you need a skilled resource to manage WAF policies on an ongoing basis. There is really no shortcut here – either you have someone knowledgable and dedicated to this task, or you depend on the canned policies that come with the WAF, and they just aren’t good enough. So the critical success factor in managing policies is to find at least one person who can manage the WAF, get them training if need be, and give them enough time to keep the policies up to date. What does this person need to do? Let’s break it down: Baseline Application Traffic The first step

This Summary is a short rant on how most firms appear baffled about how to handle mobile and cloud computing. Companies tend to view the cloud and mobile computing as wonderful new advancements, but unfortunately without thinking critically about how customers want to use these technologies – instead they tend to project their own desires onto the technology. Just as I imagine early automobiles were saddled with legacy holdovers from horse-drawn carriages, when they were in fact something new. We are in that rough transition period, where people are still adjusting to these new technologies, and thinking of them in old and outmoded terms. My current beef is with web sites that block users who appear to be coming from cloud services. Right – why on earth would legitimate users come from a cloud? At least that appears to be their train of thought. How many of you ran into a problem buying stuff with PayPal when connected through a cloud provider like Amazon, Rackspace, or Azure? PayPal was blocking all traffic from cloud provider IP addresses. Many sites simply block all traffic from cloud service providers. I assume it’s because they think no legitimate user would do this – only hackers. But some apps route traffic through their cloud services, and some users leverage Amazon as a web proxy for security and privacy. Chris Hoff predicted in The Frogs Who Desired a King that attackers could leverage cloud computing and stolen credit cards to turn “The mechanical Turk into a maniacal jerk”, but there are far more legitimate users doing this than malicious ones. Forbidding legitimate mobile apps and users from leveraging cloud proxies is essentially saying, “You are strange and scary, so go away.” Have you noticed how may web sites, if they discover you are using a mobile device, screw up their web pages? And I mean totally hose things up. The San Jose Mercury News is one example – after a 30-second promotional iPad “BANG – Get our iPad app NOW” page, you get locked into an infinite ‘django-SJMercury’ refresh loop and you can never get to the actual site. The San Francisco Chronicle is no better – every page transition gives you two full pages of white space sandwiching their “Get our App” banner, and somewhere after that you find the real site. That is if you actually scroll past their pages of white space instead of giving up and just going elsewhere. Clearly they don’t use these platforms to view their own sites. Two media publications that cover Silicon Valley appear incapable of grasping media advances that came out of their own back yard. I won’t even go into how crappy some of their apps are (looking at you, Wall Street Journal) at leveraging the advantages of the new medium – but I do need to ask why major web sites think you can only use an app on a mobile device or a browser from a PC? Finally, I have a modicum of sympathy for Mat Honan after attackers wiped out his data, and I understand my rant in this week’s Incite rubbed some the wrong way. I still think he should have taken more personal responsibility and done less blame-casting. I think Chris Hoff sees eye to eye with me on this, but Chris did a much better job of describing how the real issues in this case were obfuscated by rhetoric and attention seeking. I’d go one step further, to say that cloud and mobile computing demonstrate the futility of passwords. We have reached a point where we need to evolve past this primitive form of authentication for mobile and cloud computing. And the early attempts, a password + a mobile device, are no better. If this incident was not proof enough that passwords need to be dead, wait till Near Field Payments from mobile apps hit – cloned and stolen phones will be the new cash machines for hackers. I could go on, but I am betting you will notice if you haven’t already how poorly firms cope with cloud and mobile technologies. Their bumbling does more harm than good. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian quoted in CIO. Adrian in SIEM replacement video available this week. Rich’s Dark Reading post on Black Hat’s Future Rich quoted on iOS Security. Favorite Securosis Posts Adrian Lane: The TdF edition of the Friday Summary.. Just because that would be friggin’ awesome! Mike Rothman: Friday Summary, TdF Edition. It’s not a job, it’s an adventure. As Rich experienced with his Tour de France trip. But the message about never getting complacent and working hard, even when no one is looking, really resonated with me. Rich: Mike slams the media. My bet is this is everyone’s favorite this week. And not only because we barely posted anything else. Other Securosis Posts Endpoint Security Management Buyer’s Guide: Periodic Controls. Incite 8/8/2012: The Other 10 Months. Pragmatic WAF Management: the WAF Management Process. Favorite Outside Posts Adrian Lane: Software Runs the World. I’m not certain we can say software is totally to blame for the Knight Capital issue, but this is a thought-provoking piece in mainstream media. I am certain those of you who have read Daemon are not impressed. Mike Rothman: NinjaTel, the hacker cellphone network. Don’t think you can build your own cellular network? Think again – here’s how the Ninjas did it for Defcon. Do these folks have day jobs? Rich: How the world’s larget spam botnet was brought down. I love these success stories, especially when so many people keep claiming we are failing. Project Quant Posts Malware Analysis Quant: Index of Posts. Malware Analysis Quant: Metrics – Monitor for Reinfection. Malware Analysis Quant: Metrics – Remediate. Malware Analysis Quant: Metrics – Find Infected Devices. Malware Analysis Quant: Metrics – Define Rules and Search Queries. Malware Analysis Quant: Metrics – The Malware Profile. Malware Analysis Quant: Metrics – Dynamic Analysis. Research Reports and Presentations Evolving Endpoint Malware

We kicked off the Pragmatic WAF series by setting the stage in the last post, highlighting the quandary WAFs represent to most enterprises. On one hand, compliance mandates have made WAF the path of least resistance for application security. Plenty of folks have devoted a ton of effort to making WAF work, and they are now looking for even more value, above and beyond the compliance checkbox. On the other hand, there is general dissatisfaction with the technology, even from folks who use WAFs extensively. Before we get into an operational process for getting the most out of your WAF investment, it’s important to understand why security folks often view WAF with a jaundiced eye. The opposing viewpoints between security, app developers, operations, and business managers help pinpoint the issues with WAF deployments. These issues must be addressed before the technology can reach the adoption level of other security technologies (such as firewalls and IPS). The main arguments against WAF are: Pen-tester Abuse: Pen testers don’t like WAFs. There is no reason to beat around the bush. First, the technology makes a pen tester’s job more difficult because a WAF blocks (or should block) the kind of tactics they use to attack clients via their applications. That forces them to find their way around the WAF, which they usually manage. They are able to reach the customer’s environment despite the WAF, so the WAF must suck, right? More often the WAF is not set up to block or conceal the information pen testers are looking for. Information about the site, details about the application, configuration data, and even details on the WAF itself leak out, and are put to good use by pen testers. Far too many WAF deployments are just about getting that compliance checkbox – not stopping hackers or pen testers. So the conclusion is that the technology sucks – rather than pointing at the implementation. WAFs Breaks Apps: The security policies – essentially the rules that tell what a WAF should either block or allow to pass through to the application – can (and do) block legitimate traffic at times. Web application developers are used to turning code – basically pushing changes and new functionality to web applications several times per week, if not more often. Unless the ‘whitelist’ of approved application requests gets updated with every application change, the WAF will break the app, blocking legitimate requests. The developers get blamed, they point at operations, and nobody is happy. Compliance, Not Security: A favorite refrain of many security professionals is, “You can be compliant and still not be secure.” At least the ones who know what they’re talking about. Regulatory and industry compliance initiatives are desgined to “raise a very low bar” on security controls, but compliance mandates inevitably leave loopholes – particularly in light of how often they can realistically be updated. Loopholes attackers can exploit. Even worse, the goal of many security programs become to pass compliance audits – not to actually protect critical corporate data. The perception of WAF as a quick fix for achieving PCI-DSS compliance – often at the expense of security – leaves many security personnel with a negative impression of the technology. WAF is not a ‘set-and-forget’ product, but for compliance it is often used that way – resulting in mediocre protection. Until WAF proves its usefulness in blocking real threats or slowing down attackers, many remain unconvinced of WAF’s overall value. Skills Gaps: Application security is a non-trivial endeavor. Understanding spoofing, fraud, non-repudiation, denial of service attacks, and application misuse are skills rarely all possessed by any one individual. But all those skills are needed by an effective WAF administrator. We once heard of a WAF admin who ran the WAF in learning mode while a pen test was underway – so the WAF thought bad behavior was legitimate! Far too many folks get dumped into the deep waters of trying to make a WAF work, without a fundamental understanding of the application stack, business process, or security controls. The end result is that rules running on the WAF miss something – perhaps not accounting for current security threats, not adapted to changes in the environment, or not reflecting the current state of the application. All too often, the platform lacks adequate granularity to detect all variants of a particular threat, or essential details are not coded into policies, leaving an opening to be exploited. But is this an indictment of the technology, or how it is utilized? Perception and Reality: Like all security products, WAFs have undergone steady evolution over the last 10 years. But their perception is still suffering because original WAFs were themselves subject to many of the attacks they were supposed to defend against (WAF management is through a web application, after all). Early devices also had high false positive rates and ham-fisted threat detection at best. Some WAFs bogged down under the weight of additional policies, and no one ever wanted to remove policies for fear of allowing an attacker to compromise the site. We know there were serious growing pains with WAF, but most of the current products are mature, full-featured, and reliable – despite persistent perception. But when you look at these complaints critically, much of the dissatisfaction with WAFs comes down to poor operational management. Our research shows that WAF failures are far more often a result of operational failure than of fundamental product failure. Make no mistake – WAFs are not a silver bullet – but a correctly deployed WAF makes it much harder to attack the app or to completely avoid detection. The effectiveness of WAF is directly related to the quality of people and processes used to keep it current. The most serious problems with WAF are not about technology, but with management. So that’s what we will present. A pragmatic process to manage Web Application Firewalls, in a way that overcomes the management and perception issues which plague this technology. As usual we will start at

Outside our posts on ROI and ALE, nothing has prompted as much impassioned debate as Web Application Firewalls (WAFs). Every time someone on the Securosis team writes about Web App Firewalls, we create a mini firestorm. The catcalls come from all sides: “WAFs Suck”, “WAFs are useless”, and “WAFs are just a compliance checkbox product.” Usually this feedback comes from pen testers who easily navigate around the WAF during their engagements. The people we poll who manage WAFs – both employees and third party service providers – acknowledge the difficulty of managing WAF rules and the challenges of working closely with application developers. But at the same time, we constantly engage with dozens of companies dedicated to leveraging WAFs to protect applications. These folks get how WAFs impact their overall application security approach, and are looking for more value from their investment by optimizing their WAFs to reduce application compromises and risks to their systems. A research series on Web Application Firewalls has been near the top of our research calendar for almost three years now. Every time we started the research, we found a fractured market solving a limited set of customer use cases, and our conversations with many security practitioners brought up strong arguments, both for and against the technology. WAFs have been available for many years and are widely deployed, but their capability to detect threats varies widely, along with customer satisfaction. Rather than our typical “Understanding and Selecting” approach research papers, which are designed to educate customers on emerging technologies, we will focus this series on how to effectively use WAF. So we are kicking off a new series on Web Application Firewalls, called “Pragmatic WAF Management.” Our goal is to provide guidance on use of Web Application Firewalls. What you need to do in order to make WAFs effective for countering web-borne threats, and how a WAF helps mitigate application vulnerabilities. This series will dig into the reasons for the wide disparity in opinions on the usefulness of these platforms. This debate really frames WAF management issues – sometimes disappointment with WAF due to the quality of one specific vendor’s platform, but far more often the problems are due to mismanagement of the product. So let’s get going, delve into WAF management, and document what’s required to get the most for your WAF. Defining WAF Before we go any farther, let’s make sure everyone is on the same page for what we are describing. We define Web Application Firewalls as follows: A Web Application Firewall (WAF) monitors requests to, and responses from, web based applications or services. Rather than general network or system activity, a WAF focuses on application-specific communications and protocols – such as HTTP, XML, and SOAP. WAFs look for threats to application – such as injection attacks and malicious inputs, tampering with protocol or session data, business logic attacks, or scraping information from the site. All WAFs can be configured purely to monitor activity, but most are used to block malicious requests before they reach the application; sometimes they are even used to return altered results to the requestor. WAF is essentially a peer of the application, augmenting its behavior and providing security when and where the application cannot. Why Buy For the last three years WAFs have been selling at a brisk pace. Why? Three words: Get. Compliant. Fast. The Payment Card Industry’s Data Security Standard (PCI-DSS) prescribes WAF as an appropriate protection for applications that process credit card data. The standard offers a couple options: build security into your application, or protecting it with a WAF. The validation requirements for WAF deployments are far less rigorous than for secure code development, so most companies opt for WAFs. Plug it in and get your stamp. WAF has simply been the fastest and most cost-effective way to satisfy the PCI-DSS standard. The reasons WAFs existed in the first place, and these days the second most common reason customers purchase them, is that Intrusion Detection Systems (IDS) and general-purpose network firewalls are ineffective for application security. They are both poorly suited to protecting the application layer. In order to detect application misuse and fraud, a device must understand the dialogue between the application and the end user. WAFs were designed to fill this need, and they ‘speak’ application protocols so they can identify when an application is under attack. But our research shows a change over the last year: more and more firms want to get more value out of their WAF investment. The fundamental change is motivated by companies which need to reign in the costs of securing legacy applications under continuing budget pressure. These large enterprises have hundreds or thousands of applications, built before anyone considered ‘hacking’ a threat. You know, those legacy applications that really don’t have any business being on the Internet, but are now “business critical” and exposed to every attackers on the net. The cost to retroactively address these applications’ exposures within the applications themselves are often greater than the worth of the applications, and the time to fix them is measured in years – or even decades. Deep code-level fixes are not an option – so once again WAFs are seen as a simpler, faster, and cheaper way to bolt security on rather than patching all the old stuff. This is why firms which originally deployed WAFs to “Get compliant fast!” are now trying to make their WAFs “Secure legacy apps for less!” Series Outline We plan 5 more posts, broken up as follows: The Trouble with WAFs: First we will address the perceived effectiveness of WAF solutions head-on. We will talk about why security professionals and application developers are suspicious of WAFs today, and the history behind those perceptions. We will discuss the “compliance mindset” that drove early WAF implementations, and how compliance buyers can leverage their investment to protect web applications from general threats. We will address the missed promises of heuristics, and close with a discussion of how companies which want to “build

You remember agents, right? Those ‘lightweight’ pieces of code vendors provided to install on all your servers? The code you pushed out to endpoints? The stuff that gathered all sorts of data and provided analysis without any impact on server performance? Agents monitored activity, enforced policies, killed viruses, and foiled botnets, all from a central location, while making you a steaming espresso? Yeah, marketing hyperbole aside, agents are the ubiquitous pieces of code that got installed on every server to perform any and all security tasks on the local hosts. For tasks where network-based intelligence and protection were inappropriate – which are more common than not – agents do much of the heavy lifting. They’re installed on endpoints and servers. And they are a pain in the ass – many enterprises instituted “no more agents” moratoria when they were multiplying like rabbits, and once you get to say 20 or so agents on a machine, things get out of hand… In terms of cloud services, what does that all mean? For the last two years we have been hearing security vendors say, “Yes, we offer a cloud solution.” When we dug in, it always seemed to be the same old agent, deployed the same as before, now on an Amazon AWS instance. Best case you get the same agent proliferation/performance/management problem in your shiny new IaaS cloud; worst case you cannot deploy these agents because the PaaS or SaaS service provider won’t let you. So where does that leave customers, who have embraced SaaS far more than IaaS? Security is largely a bolt-on proposition, so where exactly do you bolt it on in the cloud? We go back to the network. I see a proliferation of vendors announcing, or about to announce, proxy-based security implementations. Delivered – surprise, surprise – as SaaS to secure other SaaS services. One cloud secures another. The proxy model seems to have (finally?) caught hold – because it gives security vendors a suitable deployment model. The vendors insert themselves into the network stream, essentially by redirecting network traffic through their cloud-based security service, to filter and monitor activity before it gets to your cloud service. For those of you familiar with programmable shells (csh, bash, etc.), it’s like linking two commands with pipes (‘|’): the output of one service is passed into the next in the chain for further processing. Anti-spam vendors have been doing this for years. Anti-DDoS, IAM, and WAF vendors are gaining traction, and now stuff like content masking and DLP for mobile devices is popping up. Rich talked about some of the downsides of this approach last year with Proxies and the Cloud, but that was specifically addressing some solutions that just don’t work in this model, such as proxy-based encryption for SaaS applications. The issues Rich raised by hold for some products, especially as they pertain to SaaS-based services, and I expect to see other problems. That said, there are significant advantages to proxies beyond the a viable deployment model. You’re not installing and managing agents on your virtual platforms. You’re not opening holes in or across your network to allow them to communicate – instead the service is in line with the business process. And you’re not scaling by adding a bunch of appliances to your data center – in fact you get many of the standard cloud services advantages: self service, elasticity, metered, and pay as you go. And some evolutionary changes jump-started by cloud computing make some security products obsolete – such as AV proxies for smartphones. Just because the model enables a service to exist does not mean that service is necessary. Share:

At the Cloud Identity Summit last week, Craig Burton stated the SAML – the security assertion language that helps thousands of enterprises address single sign-on – is unequivocably dead. Kaput. He presented the following data points to support his argument (I will link to his presentation when available): Proliferation of APIs: There are so many APIs, billions in fact, and we have thousands popping up every second, that we cannot ever hope to integrate them with SAML. The effort is too great, and integration is too complex, for all the services to address the scope of the problem. Scalability: SAML cannot scale to solve the cloud’s many-to-many problems, and is too cumbersome to address such a large problem. Lack of support: His final point is that all the major backers have stopped financial support for SAML 2.0, and it appears that no one is driving advancement of the standard. Without more support fundamental limitations in the standard simply cannot be addressed, and support is shifting to OpenID Connect. Three solid points. But do they mean SAML is dead? And what the heck does ‘dead’ mean for a product anyway? One the first point, I disagree. There are different ways to scale solutions like SAML, and there are indeed billions of APIs, but we do not we want or need SAML to give us SSO to all of – or even a significant fraction – of them. That’s a rather silly utopian dream. And the lack of support for revising a standard does not mean that it is obsolete – or that we should stop using it. That’s my take and I’m sticking with it. I was originally going to title this post is “SAML IS Dead”, but that’s not what we should be talking about. SAML’s longevity, and how much faith customers should put into technologies called ‘dead’, are only part of the problem. This most recent claim is only one instance in a long-running series. We have seen people – no, let’s call this one correctly – analysts – say stuff is dead. All the freakin’ time. IDS, anyone? How many people have said Windows is dead? It’s like any limerick that starts out “There once was a man from Nantucket …” – after the first few you know the pattern. To an analyst there is value to doing this. Advising customers when a technology has been superseded, or will likely be obsolete within a few years, is useful. It helps companies avoid selection of suboptimal technologies, and investment in inferior choices when better options exist. But labeling something ‘dead’ has become every analyst’s favorite way to be a drama queen. It’s to get attention, and to exaggerate a point when you don’t think your audience is paying attention. I understand why it happens, but it’s not helpful. It fails to capture the essence of the slow evolutionary replacement of technologies. History has shown it’s just as likely to be wrong, to mislead customers, or both. Why call products dead when everyone is still using them? Many people on Twitter had the same thought I did – PKI, IPV4, Kerberos, AV and firewalls, have all been ‘dead’ for years – but they all remain in wide use with no indication of actually going away. Worse, when we say older standards are now made obsolete by new standards – which are yet to be finished, much less adopted – we often fall on our faces when the new standard gets stuck in committee and turns out to die while the ‘dead’ predecessor lives on. We have seen cases where simplicity of concept (UNIX) trumps a grand vision (MULTICS). And we have seen cases where technologists want something to die (IE 6 comes to mind), but the general population sees value and utility in the product. Plenty of technologies which are wished or “supposed to be” dead continue to be essential computing and security. So maybe dead means “dead to me” – an entirely different meaning. Share:

“WTF? There are no security people here! I’m at a security conference without security folk. How weird is that?” I just got back from the Cloud Identity Summit in Vail, Colorado. Great conference, by the way. But as I walked around during the opening night festivities, I quickly realized I did not know anyone until Gunnar Peterson showed up. 400 people in attendance, and I did not know anyone. I’ve been in security for something like 16 years. When I go to a security conference – say RSA or Black Hat – I see dozens of people I know. Hundreds I have met and spoken with. And hundreds more I’ve met over the years, whose names I can’t remember, but I know we have crossed paths. I was at a security conference, where only two other people in attendance attend any mainstream security events. Seriously. And one of those two works with me at Securosis. This is amazing. Amazingly bad, but still shocking. Why are these two crowds separate and distinct? Identity and access managements is security. But the people who attend identity events are not and will not be at Black Hat. They are definitely not the people at DefCon. I am guessing that is because of the different mindset and approach between the two camps. I was talking with Gunnar about how the approach in identity now is about building capabilities and interconnectedness. Security is still mostly about breaking stuff to prove a point, with a little risk analysis thrown in. I say identity is enablement, while security is disablement. Gunnar said “IAM is about integration; security is about stopping threats”. That’s the difference in mindset. And if any two audiences need to cross-pollinate, it’s these two. Be honest: how much do you know about SAML? When was the last time you used the phrase “relying party” in a sentence? PIP? Yeah, that’s what I thought. The other big takeaway from the event was how cloud computing architectures are changing the way we use identity services. We’re not talking about moving Active Directory to the cloud – it’s an entirely different approach. At Securosis we talk a lot about the need for security companies to stop ‘cloudwashing’ their marketing collateral, and instead redesign parts of their products from scratch to accommodate different cloud service models. Identity providers are doing this, in a big way. Another thing the conference highlighted is the failure of perimeter-based security for cloud computing, and how that applies to identity. For most of you reading this, that’s not a new concept – but seeing it in practice is something else entirely. In years past I have called identity “front door security”, because it’s the technology that secures the main entry point for applications and services. It still is, but the “front door” is dead. There is no front door – as the perimeter security model dies, so does the concept of solid walls guarding content and systems. This has been a key theme in many of Chris Hoff’s presentations over the last several years, and was the theme of this identity conference in Colorado as well. But it hits home when you see that major cloud providers are in the second or third phase of maturity when it comes to federated identity and SSO outside corporate IT. Services Oriented Architectures have many public facing portions – with many cooperating services working together to determine identity, access rights, and provisioning. I will have much more to say about the different architectures and supporting technologies in the coming months. All in all the Cloud Identity Summit was one of the better security events I have ever been to. Being in Vail helped, no doubt, but the conference was well run. Good speakers, good orchestration, plenty of coffee, and the most family oriented conference I’ve ever been to in any industry. I’ll be going back next year. And if you are in security you should check it out too. Honestly, people, it’s okay to Cross the streams. I know hacking is far sexier than writing secure code, but it’s okay to learn about positive security models as well. Share:

It probably does not need to be said, but just about the entire Securosis team will be at Black Hat this week. And no, not just for the parties, but there will be some of that as well. I want to see a boatload of sessions this year – and I am betting Moss, Schneier, Shostack, Ranum, and Granick on stage together will be entertaining. On Wednesday David Mortman will present The Defense rests: Automation and APIs for Improving Security. I think this will be a great session – the topic is very timely, given the way firms are moving away from SOAP-based APIs to REST. You should see this one too – rumor is that Kaminsky’s presentation is very boring, and API security is way more interesting than that old network stack/DNS stuff. This Friday at DefCon David Mortman, Rich Mogull, Chris Hoff, Dave Maynor, Larry Pesce, and James Arlen will all present at DEF CON Comedy Jam V, V for Vendetta. I have seen parts of Rich’s presentation, and it’s definitely something you’ll want to see as well. Me, I am going to be… actually I have no idea where I will be. I’m proctoring sessions, but at this moment I have no idea which ones. Or when. Unlike previous years, I am “schedule challenged” – but fear not, for those of you I said I want to meet, I will get in touch when I land in Vegas and figure out my schedule. Looking forward to seeing you there! Share:

The summer conference season has begun, and for those of us living in Phoenix, going to conferences is a great way to get out July’s blast furnace heat. I’m heading out tomorrow to the Cloud Identity Summit in Vail, Colorado. I’m not speaking – just going to hang out and learn. And there is a lot to lean about with new developments in identity management. Many of the basic tools are not actually new – SAML has been around for about a decade – but the rate of product evolution in this field is frankly staggering. How products are being deployed for cloud and mobile – and how authentication, authorization, and provisioning work together in these environments – are new. I expect to see wholesale changes in how we use and consume identity in the coming years – be it cloud, mobile, or whatever. So we have decided we need to increase coverage in this area, to aid IT in understanding how to approach identity management projects, and to dig into some of the technical details of how developers should approach implementation. Rich and I will be doing a lot of blogging on this topic in the coming months, and Gunnar Peterson and I plan to publish research on the ins and outs of cloud identity late this summer, so stay tuned. My goal is to do a little blogging while I’m there, about what’s new and interesting. If you plan to attend let me know so we can meet up! Share: