Research

Obviously bad news sells. If you have any doubt about that, watch your local news. Wherever you are. The first three stories are inevitably bad news. Fires, murders, stupid political fiascos. Then maybe you’ll see a human interest story. Maybe. Then some sports and the weather and that’s it. Let’s just say I haven’t watched any newscast in a long time. But this focus on negativity has permeated every aspect of the media, and it’s nauseating. Let’s take the Olympics, for example. What a great opportunity to tell great stories about athletes overcoming incredible odds to perform on a world stage. The broadcasts (at least NBC in the US) do go into the backstories of the athletes a bit, and those stories are inspiring. But what the hell is going on with the interviews of the athletes, especially right after competition? Could these reporters be more offensive? Asking question after question about why an athlete didn’t do this or failed to do that. Let’s take an interview with Michael Phelps Monday night, for example. This guy will end these Olympics as the most decorated athlete in history. He lost a race on Sunday that he didn’t specifically train for, coming in fourth. After qualifying for the finals in the 200m Butterfly, the obtuse reporter asked him, “which Michael Phelps will we see at the finals?” Really? Phelps didn’t take the bait, but she kept pressing him. Finally he said, “I let my swimming do the talking.” Zing! But every interview was like that. I know reporters want to get the raw emotion, but earning a silver medal is not a bad thing. Sure, every athlete with the drive to make the Olympics wants to win Gold. But the media should be celebrating these athletes, not poking the open wound when they don’t win or medal. Does anyone think gymnast Jordyn Weiber doesn’t feels terrible that she, the reigning world champion, didn’t qualify for the all-around? As if these athletes’ accomplishments weren’t already impressive enough, their ability to deal with these media idiots is even more impressive. But I guess that’s the world we live in. Bad news sells, and good news ends up on the back page of those papers no one buys anymore. Folks are more interested in who Kobe Bryant is partying with than the 10,000 hours these folks spend training for a 1-minute race. On days like this, I’m truly thankful our DVR allows us to forward through the interviews. And that the mute button enables me to muzzle the commentators. –Mike Photo credits: STFU originally uploaded by Glenn Heavy Research We’re back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, where you can get all our content in its unabridged glory. And you can get all our research papers too. Endpoint Security Management Buyer’s Guide The Business Impact of Managing Endpoints Pragmatic WAF Management New Series: Pragmatic WAF Management Incite 4 U Awareness of security awareness (training): You have to hand it to Dave Aitel – he knows how to stir the pot, poking at the entire security awareness training business. He basically calls it an ineffective waste of money, which would be better invested in technical controls. Every security admin tasked with wiping the machines of the same folks over and over again (really, it wasn’t pr0n) nodded in agreement. And every trainer took offense and pointed both barrels at Dave. Let me highlight one of the better responses from Rob Cheyne, who makes some good points. As usual, the truth is somewhere in the middle. I believe high-quality security training can help, but it cannot prevent everybody from clicking stuff they shouldn’t. The goal needs to be reducing the number of those folks who click unwisely. We need to balance the cost of training against the reduction in time and money spent cleaning up after the screwups. In some organizations this is a good investment. In others, not so much. But there are no absolutes here – there rarely are. – MR RESTful poop flinger: A college prof told me that, when he used to test his applications, he would take a stack of punch cards out of the trash can and feed them in as inputs. When I used to test database scalability features, I would randomly disconnect one of the databases to ensure proper failover to the other servers. But I never wrote a Chaos Monkey to randomly kick my apps over so I could continually verify application ‘survivability’. Netflix announced this concept some time back, but now the source code is available to the public. Which is awesome. Just as no battle plan survives contact with the enemy, failover systems die on contact with reality. This is a great idea for validating code – sort of like an ongoing proof of concept. When universities have coding competitions, this is how they should test. – AL Budget jitsu: Great post here by Rob Graham about the nonsensical approach most security folks take to fighting for more budget using the “coffee fund” analogy. Doing the sales/funding dance is something I tackled in the Pragmatic CSO, and Rob takes a different approach: presenting everything in terms of tradeoffs. Don’t ask for more money – ask to redistribute money to deal with different and emerging threats – which is very good advice. But Rob’s money quote, “Therefore, it must be a dishonest belief in one’s own worth. Cybersecurity have this in spades. They’ve raised their profession into some sort of quasi-religion,” shows a lot of folks need an attitude adjustment in order to sell their priorities. There is (painful) truth in that. – MR Watch me pull a rabbit from my hat: The press folks at Black Hat were frenetic. At one session I proctored, a member of the press literally walked onto stage as I was set to announce the presentation, and several more repeatedly

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

Keeping track of 10,000+ of anything is a management nightmare. With ongoing compliance oversight, and evolving security attacks taking advantage of vulnerable devices, getting a handle on what’s involved in managing endpoints becomes more important every day. Complicating matters is the fact that endpoints now include all sorts of devices – including a variety of PCs, mobiles, and even kiosks and other fixed function devices. We detailed our thoughts on endpoint security fundamentals a few years back, and much of that is still very relevant. But we didn’t continue to the next logical step: a deeper look at how to buy these technologies. So we are introducing a new type of blog series, an “Endpoint Security Management Buyer’s Guide”, focused on helping you understand what features and functions are important – in the four critical areas of patch management, configuration management, device control, and file integrity monitoring. We are partnering with our friends at Lumension through the rest of this year to do a much more detailed job of helping you understand endpoint security management technologies. We will dig even deeper into each of those technology areas later this year, with dedicated papers on implementation/deployment and management of those technologies – you will get a full view of what’s important; as well as how to buy, deploy, and manage these technologies over time. What you won’t see in this series is any mention of anti-malware. We have done a ton of research on that, including Malware Analysis Quant and Evolving Endpoint Malware Detection, so we will defer an anti-malware Buyer’s Guide until 2013. Now let’s talk a bit about the business drivers for endpoint security management. Business Drivers Regardless of what business you’re in, the CIA (confidentiality, integrity, availability) triad is important. For example, if you deal with sophisticated intellectual property, confidentiality is likely your primary driver. Or perhaps your organization sells a lot online, so downtime is your enemy. Regardless of the business imperative, failing to protect the devices with access to your corporate data won’t turn out well. Of course there are an infinite number of attacks that can be launched against your company. But we have seen that most attackers go after the low-hanging fruit because it’s the easiest way to get what they are looking for. As we described in our recent Vulnerability Management Evolution research, a huge part of prioritizing operational activities is understanding what’s vulnerable and/or configured poorly. But that only tells you what needs to get done – someone still has to do it. That’s where endpoint security management comes into play. Before we get ahead of ourselves, let’s dig a little deeper into the threats and complexities your organization faces. Emerging Attack Vectors You can’t pick up a technology trade publication without seeing terms like “Advanced Persistent Threat” and “Targeted Attacks”. We generally just laugh at all the attacker hyperbole thrown around by the media. You need to know one simple thing: these so-called “advanced attackers” are only as advanced as they need to be. If you leave the front door open, they don’t need to sneak in through the ventilation pipes. In fact many successful attacks today are caused by simple operational failures. Whether it’s an inability to patch in a timely fashion or to maintain secure configurations, far too many people leave the proverbial doors open on their devices. Or they target users via sleight-of-hand and social engineering. Employees unknowingly open the door for the attacker – with their desired result: data compromise. But we do not sugarcoat things. Attackers are getting better – and our technologies, processes, and personnel have not kept pace. It’s increasingly hard to keep devices protected, which means you need to take a different and more creative view of defensive tactics, while ensuring you execute flawlessly because even the slightest opening provides an opportunity for an attacker. Device Sprawl Remember the good old days, when your devices consisted of PCs and a few dumb terminals? Those days are gone. Now you have a variety of PC variants running numerous operating systems. Those PCs may be virtualized and they may be connecting in from anywhere in the world – whether you control the network or not. Even better, many employees carry smartphones in their pockets, but ‘smartphones’ are really computers. Don’t forget tablet computers either – which have as much computing power as mainframes a couple decades ago. So any set of controls and processes you implement must be consistently enforced across the sprawl of all your devices. Every attack starts with one compromised device. More devices means more complexity, which means a higher likelihood something will go wrong. Again, this means you need to execute your endpoint security management flawlessly. But you already knew that. BYOD As uplifting as dealing with these emerging attack vectors and this device sprawl is, we are not done complicating things. Now the latest hot buzzword is BYOD (bring your own device), which basically means you need to protect not just corporate computer assets but your employees’ personal devices as well. Most folks assume this just means dealing with those pesky Android phones and iPads, but that’s a bad assumption. We know a bunch of finance folks who would just love to get all those PCs off the corporate books, and that means you need to support any variety of PC or Mac any employee wants to use. Of course the controls you put in place need to be consistent, whether your organization or the employee owns a device. The big difference is granularity in management. If a corporate device is compromised you just wipe the device and move on – you know how hard it is to truly clean a modern malware infection, and how much harder it is to have confidence that it really is clean. But what about the pictures of Grandma on an employee’s device? What about their personal email and address book? Blow those away and the reaction is likely to be much worse. So

What is normal? It changes most every day, especially when you are 8. We picked up the Boy from a month away at camp last weekend and we weren’t sure how he’d respond to, uh, real life. After seeing him on Visiting Day the week before, we knew he was having a great time. Maybe too great a time, as the downside is the inevitable adjustment period when times aren’t as fun or active or exciting or anything besides 16 hours of non-stop playtime. To give you some context, we had him explain a typical day at camp. They’d rise at 7, line up to raise the flag, clean up their bunk for inspection, have breakfast, do an elective, then move on to a bunk activity before instructional swim. Then they’d eat lunch. Right, that was just the morning. After lunch they’d have another bunk activity, free swim, rest time, then dinner. After dinner, they’d chill out at the canteen and have an evening activity. Then it was bed time, finally. I get tired just typing up this list. Think about it — non-stop activity every day for a month. Of course it would take some time to get back into the swing of being home. Let’s just say his activity level at home is not. like. that. He was fine the first day, as he got fawned over by his parents, grandma and cousins. On the second day we drove back to GA. It didn’t go well. Not well at all. He got a bit car sick and thus the iPad was out of play. That was a problem. So he proceeded to make us miserable for the first four hours of the drive. As much activity as he had at camp, he had none on this day. The 180 degree turn gave him some whiplash. And he let us know it wasn’t fun. As if driving 10 hours was just a load of laughs for me. Then it hit me — he had the DTs. Thankfully without the vomiting or convulsions, as that would have made a mess in my new car. So we just had to ride it out and let him detox from his activity addiction. He slept, a lot, I listened to a lot of Pandora, and the Boss watched some movies. When we finally got home, he was genuinely happy to be home. He liked the changes we made in the house when he was away. He couldn’t wait to see his buddies. We still have to manage his expectations a bit by providing a minute by minute description of what he’ll be doing each day. And he’ll have fun, but not as much fun as when he was at camp. Then he’ll be back in school, and fun will be a distant memory. I wonder if they have methadone treatments for that? -Mike Photo credits: Novus Medical Detox Center 01 originally uploaded by thetawarrior Securosis at Black Hat As Adrian posted on Monday, the extended team is descending on Vegas this week for the madness that is Black Hat and DEFCON. That means not just Rich, Adrian and I, but Mort, Jamie and Dave will be there also. Seems that only Gunnar has the sense to stay off the surface of the sun in August. I can only speak for myself and my schedule’s been locked down for weeks. But I’ll look forward to seeing some of you on the party circuit through Thursday night. Follow us on the Tweeter and you’ll sure to get some idea of where we’re milling around. Incite 4 U Beware the PDoS: I’m not sure if Krebs should be flattered or horrified that he’s the unknowing beta tester of all sorts of bad stuff in development. He details his experience as the target of a PDoS (personal denial of service), getting flooded by emails, texts and calls one day. It was a crippling attack, even for someone knowing what they are doing. Amazingly enough shortly thereafter, Brian saw a commercial offering hit to provide the same kind of attack. As you can imagine, if a bad guy was trying to prevent some kind of notification of bad stuff happening (like a huge bank transfer, etc.), shutting down someone’s methods of communication could be pretty effective. So the question for all of us (assuming you require notification and authorization of some types of transactions) is whether your institution fails open (allows the transaction) or fails closed (doesn’t). I’m not going to assume anything, and will be checking all of my accounts ASAP. — MR Mah SIEM sux: Mark Runals’ discusses some of the limitations with misuse detection, examining both statistical analysis and rule based policies, as they relate to SIEM and Log Management platforms. I agree with his conclusion about the value of starting with statistical analysis (you know, baselines) as an easier first step, but keep in mind that threat-model based rules is a great way to isolate specific actions and alert/report on unwanted behavior. Most firms have a handful of very specific actions/attacks they want to detect. But some of the reasons people say ‘Mah SIEM sux’ is that the logs lack enough context and/or some of the necessary attributes, to provide truly effective rules. And the log data is often normalized into uselessness along the way, with correlation focused on network-based attributes that don’t really help you understand the impact of application or system events. Enrichment is supposed to help fill this deficiency, but then rules need to evolve to take advantage of the enriched logs, increasing the amount of work it takes to write rules. This, and the fact that we can’t predict – and subsequently write policies – for all possible conditions we need to watch for. Policies are limited only by the imagination of the policy manager, the time it takes to write/tune the policies, and the processing power available to analyze the ruleset. Not to mention the more granular the policies

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:

21 days. It doesn’t seem like a long time. In the day to day grind of my routine, 3 weeks is nothing. I basically blink and that much time passes. But when your kids are away at camp it is a long time. For us day 21 is a lifesaver because it’s the first visiting day. So last weekend we packed up the car and made the trek to Pennsylvania to see the kids. For 21 days, we were in parental purgatory. We wait and we worry and we look at pictures and we make up all sorts of stories about what the kids are doing, based on thos pictures and a couple 2-sentence letters. That’s what parents do. So after 21 days, we finally get to compare reality to our made-up vision of what they are doing. Just to give you a little flavor for the kinds of letters we receive, XX2 wrote this missive to her Grandma (slightly edited for readability, but not much): Grandma, Please send make-up. I need lipstick and eyeshadow and hairspray. I’ve had to borrow from the other girls. I’m helpless without makeup. Love, XX2 Helpless?!? What a character. Though we had a decision to make – to send the make-up or not. Of course we sent her make-up. Actually, the Boss was very surprised because at home I’m very anti-makeup. My kids are beautiful without needing to look like street walkers. But they are at camp to find themselves. To do the things they want to do, without their parents micromanaging every move. Even if it involves wearing make-up – so be it. The good news is the kids are doing great. Really great. Even the Boy, who is away for the first time. His counselors said he was quiet for the first two weeks, while he figured out which end was up. But now that he’s comfortable with everyone, he’s pretty talkative. The girls are camp pros by now, and they are having the time of their lives. XX2 got a big part in the play, and XX1 has made the Boss very happy by being in the middle of every picture she’s in and flashing a huge smile. In another 21 days, we’ll return to camp for the second visiting day and to pick up the girls. Then we’ll do the long drive back to GA and get back into the routine of school and activities. For us, the next 21 days will be agonizingly slow. For them, they will pass in the blink of an eye. And they’ll enjoy every second of it. –Mike Photo credits: Welcome to Camp originally uploaded by Altus Wilder Incite 4 U Security vs. Convenience: This post on scaling by one of the Dropbox ops guys was very interesting. Counter-intuitively adding “fake” load prematurely only to remove the extra load when you run out of capacity is an interesting tactic to buy some time. Also the ideas of actually testing the edge cases and logging all sorts of stuff (even if you don’t know how you’ll use the data) will help to put our scaling efforts in perspective when we have Nexus scaling problems, that is. But it’s the last paragraph that is pretty problematic (and explains how privacy issues and obfuscation happen). He says that “security is really important for Dropbox,” but then goes into a riff on making trade-offs based on how important security is to the service. Let’s be clear, security isn’t important to any emerging service until they screw something up. Then security is very important. Which is why trying to build a security program in an organization that’s never had a security problem can be the Impossible Dream (h/t to Don Quixote). – MR Cry havoc and let slip the honeypots of war:: Playing defense all the time is a real pain in the behind. No one enjoys just sitting there until some dumb ass wielding Metasploit comes by and owns you. At the same time, never underestimate the marketing power of the latest security meme. One of these hot topics is the concept of active defense, which can technically mean a whole host of things as described by Chris Hoff in his latest post (that also references one of my posts). As this conversation picks up I think it’s important to remember that these principles, and even sometimes technologies, have been around for a while. The problem has often been they lack the automation to make them truly useful. Too complex, too manual. That’s starting to change, and I think most organizations will adopt active defenses fairly soon. As for Chris’ OODA loop reference… well let’s just say I have more to write on that. – RM Browser Security is more than sandboxing: Reading the Which Browser is Safest on nakedsecurity I was non-plussed as there are several important ways to judge browser security not even discussed in the post. Sandboxing is certainly one element, but there is no discussion of XSS or CSRF. And there are the reputation based protections, to detect things like malware and bad certificates. Perhaps more importantly, there is still no real equivalent to NoScript on Chrome or IE, which is the last reason I continue to cling to Firefox while most people I know have long since moved to Chrome. Then there is the rest of the privacy side of the equation. Ironic that someone on nakedsecurity is discussing browser security when their site source cross-links to eight or so other sites and feeds your browser with another 8 ghost cookies. As bad as Firefox is, at least my add-ons allow me to block most of the data I don’t want sites having on me and my browser. – AL The challenge of asymmetry: Greg Ferro summarize the issues of doing security pretty effectively in Basics:Threat Asymmetry and Security Posture. Yes, it’s a pretty simple concept, but when you spend all day in your reversing tool or knee deep in PCAP files, sometimes

Our friend Richard Stiennon put his promotional engine in gear this week to push his new book, UP and to the RIGHT. So my Twitter stream has been blown up by all sorts of folks praising Richard’s work. Which is great for Richard. I know what kind of commitment is required to write a book and what’s involved in self-publishing one. Including the Herculean task of getting your buddies to write glowing reviews and generating buzz in the echo chamber. Richard is a good analyst. He has seen the process of vendor ranking from both sides, as both the analyst and the vendor. If someone is going to write a book about optimizing a vendor’s position on the Magic Quadrant, it should be Richard. If you just fell off the turnip truck and have no idea how analyst relations works, then maybe you need a book to teach you what to do. But it has been a long time since I’ve talked to someone at a high level within a enterprise class security vendor who doesn’t understand how the process works. In terms of disclosure, I haven’t read Richard’s book and I’m not going to. I’ve lived Richard’s book. So has Rich (from the analyst side) and Adrian (from the vendor side). So maybe Richard has new nuggets of wisdom for all of us. But let me save you all a little time and tell you vendor folks the two steps to a better ranking on any of the analyst charts. Step 1: SELL. MORE. STUFF. TO. ENTERPRISE. CUSTOMERS. Step 2: Go back to Step 1. It’s not really any more complicated than that. Of course you can spend a zillion dollars on subscription services and analyst days and conference sponsorships. That may move your dot a little bit. But it won’t move your dot a lot. The only thing that will truly shift your ranking is customer success. That’s what most folks don’t understand. Or don’t want to understand. Lots of vendors (strangely correlated with those in the ‘loser’ quadrant) continue to hide behind the pay for play bogeyman, figuring they aren’t ranked better because the big competitor spends a bunch more money on analyst services. That’s rubbish. In my experience, it doesn’t work that way. And by the way, marketing professionals can’t fix a busted product or a company and finagle a better ranking. Analysts (even the bad ones) involved in an MQ or Wave project talk to a lot of people. They hear the good and the bad. Calling in favors to get your good customers to call the analyst (‘unprompted’) and tell them good things may help. But not if the ratio of calls talking about replacing your gear to those good calls is 4:1. Believe me, I’ve tried. I’m not going to minimize the importance of spending time building rapport with the analyst who covers your company. Oh, by the way, you may actually learn something if you spend half a second listening to what the analyst says about what’s happening in your market. As opposed to spinning like a nuclear centrifuge for the entire meeting. Talk to them quarterly. Keep them updated on what’s going on with your company. On your success and your failures. They are going to hear about your failures anyway, so you may as well be honest. If you have a compelling vision that aligns with how they see the world, then these briefings may move your dot a little to the right. But not a lot. I’m sure there is a lot of great stuff in Richard’s book. But nothing in a book is going to help you sell more stuff to the end users who Gartner and Forrester are talking to every day. If those folks aren’t looking at your product or service, and if they aren’t deploying it, you have no shot. You deserve to be in the loser quadrant. And no number of strategy days is going to change that. Photo credit: “Magic Quadrant Fruits White” originally uploaded by Jinho Jung Share: