As you are reading this, my flight back to ATL should be climbing up through 10,000 feet on my way back home. Another year, another Black Hat, another set of things that are sure to kill us somewhere down the line, another few parties, and another frantic ride back to the airport.

Day 2 was a bit more sedate than Day 1, though that may have more to do with my hangover (that I finally chased away about 3 PM). I also skipped the keynote, though I heard it was pretty good. Here's a brief rundown of the sessions I did today.

• Satan is on my friends list: This session went deep into some of the tricks you can use on Facebook, MySpace, and LinkedIn to make the application do unexpected things. The most interesting thing is that the attacks were shockingly simple. No wonder these social network sites are such havens for malware, leveraging XSS, CSRF and all sorts of other attack vectors. Shawn Moyer and Nathan Hamiel also ran a little experiment in adding Marcus Ranum (with his permission) to LinkedIn and added about 60 connections within a day. One of the last recommendations was to make sure you had a profile on each of the sites. Not because you plan to use it, but because you should get one out there before the bad guys do. At least the inimitable Ranum now has a profile.
• No More Signatures: Defending Web Apps with ModProfiler: I was pretty disappointed with this session from Breach's Ivan Ristic and Ofar Shezaf. They spent the first 45 minutes explaining what a web application firewall is and some specifics about ModSecurity (the open source version). I was there to hear about ModProfiler, which is a new project focused on more effectively leveraging a positive (if it's not explicitly allowed, then it's not allowed) web application security model. They only spent maybe 30 minutes on that and didn't show the code or a demo or anything. Maybe they did in the last 15 minutes, but I left before then. You shouldn't make people wait for an hour to get to the technology mentioned in the title of the pitch.
• Get Rich or Die Trying: Jeremiah did a great job going over quite a few scams that really leverage web technologies, kind of. Most took advantage of weaknesses in the web application, as opposed to actually security flaws. And to see some of the real simple stuff (like having press releases accessible before they hit the wire by figuring out the naming sequence), and how one woman made about $400,000 by selling merchandise that QVC shipped her even after she canceled the transaction. So, the moral of the story is that company's should probably pay their Q/A people a lot more money (or get new ones) to find this stuff before an application goes live.

And that's all she wrote. Back to a regular publishing schedule next week. Enjoy your weekend.

 

Good Morning:
When was the last time you used a pay phone? For me it was a LONG time ago. I'm not sure why I thought about that, but sometimes entire industries just go away and we hardly notice. Pay phones were a very big business for the phone companies many years ago. I remember having my trusty phone card always by my side and finding those germ-ridden phone boxes wherever I could to check in.

Yes, this was before cell phones became ubiquitous and Blackberry's made 24 hour connectivity not only possible, but connected. This is why I always tell everyone to question everything. I'm sure the phone executives didn't figure their cash cow pay phone business would just go away. Even early in the cell phone revolution. I still used my calling card in hotels because the cell phone was too expensive to use all the time. Now, not so much.

So what can kill your business? What will you do if your main cash cow just goes away? If you work for a big business, these questions may not be that relevant (since I doubt a company like GE is going away, even if a portion of their businesses), but if you work for a small business - it certainly is relevant. I see this every day. Companies that were great businesses are rendered obsolete. And the businesspeople either adapt or they die.

Darwin would be proud. He was right. Have a great day.

Incite #7: The SDLC is your friend

As innovation in web application scanners is crushed by consolidation and web application firewalls still can’t find its sea legs, security professionals finally get religion about building secure applications, largely to avoid the PCI stick in the eye and embracing the reality that applications remain the path of least resistance. A long, hard cultural struggle ensues between security and software development personnel, but by focusing on building the most critical applications securely, the tide turns regarding the secure systems development lifecycle (SDLC).

Read the original Days of Incite post on this topic.

6-month grade: C

I curse the PCI 6.6 clarification. Ugh. It was that one little clause of either WAF or code reviews/SDLC to be compliant with 6.6 that torpedoed this Incite. Fact is, I've written a lot about the fact that most organizations will opt for the path of least resistance, and that usually means a box - as opposed to a process change. And a WAF is a box, and an SDLC is a process change. Guess which one wins, when deemed reasonably equal in the eyes of the assessor?

Now has their been a lot of innovation in the WAF space? Not really. But who cares. It's the path of least resistance for many trying to outrun the specter of PCI - so it's not only have WAFs found their sea legs, but you are seeing integration with web app scanning and other parts of the eco-system. By the way, if being wrong about an Incite means things are moving forward - then I'm cool with it.

But what about secure development practices? What about SDLC and code reviews and the like? Yep, they are still important and I think that implementing these concepts now will pay dividends for years down the road. And I also know it's hard and that many dev teams will be resistant to changing the way they do things. All I can say is to keep fighting the good fight and focus. 

One approach is to build up a grass roots effort by focusing on those apps that directly handle critical data. You aren't going to totally and fundamentally change things overnight. Nor should you. Some apps don't need to be overhauled, since they are either not exposed or they don't handle sensitive data. But for those that do, keep banging away. Yes you get a headache, and probably a callas on your forehead. 

If it was easy, everyone would be doing it.

Photo credit: "Path of Least Resistance" by kisses are a better fate than wisdom

You've got to love Google. Besides how quickly and effectively they've disrupted the advertising world and built a company of scale, they have changed the way most folks think about web applications. Google (to my knowledge) was the first that harnessed the power of "BETA" to release buggy software with a smile on their face.

You see, BETA is all about managing expectations. By putting the BETA moniker on an application, you are telling the customer (and amazingly enough people even pay for BETA software) that there are problems. There will be issues, it won't work as you want, you'll probably lose data, and it's your problem. The software developer doesn't want to hear from you when they crater your email or application or anything else.

That's right. By plastering BETA in your application, you get off the hook. And it works. When I can't get to my Gmail, I just shrug and say - well it's BETA after all. And the price is right.

Yet, this is killer for someone who is responsible for web application security. Why? Because BETA (and Web 2.0) is all about getting something out there, not something that is good. Once it's out there, you can iterate and make it better.

From a functionality standpoint, that's exactly right. Quick interations are critical to gather market feedback and improve the experience. From a security standpoint, by the time you get to iterate - you'll already be dead. Or looking for your next job, at a minimum.

Let's go back to Web App Security theory. In a perfect world, a threat model is built ahead of architecture and development, and systematic process of testing the application for vulnerabilities and exposures happens at every step of the dev process. Right?

Wrong. There are maybe a handful of companies that actually develop applications like that. The rest just build crap, plaster BETA on it, and let it loose on the world. XSS, CSRF, SQL injection and any number of other application vulnerabilities and all.

Which creates quite a quandary for a security professional. What to do? Basically you need to hack your BETA applications. That's right, go Hack Yourself. Even if you have to do it in your free time, you have to do it.

The only way to make it clear to the developers the dangers of the BETA mentality is to show them with incontrovertible evidence. You need to break your own stuff and then they'll at least have to listen to what you say. Or then you can go find another job in better conscience that you tried your best to do the right thing.

No this isn't a big departure from a lot of my thinking on security assurance, but it's a bit further under the radar.

Once you've broken the BETA, you can start building your credibility and showing the developers that a bit of balance between getting it out there (the BETA mindset) and shipping commercial-grade software (you know, stuff actually works and is sort of secure) can be reached.

And then thank Google for setting the web application bar so low that no one seems to care anymore.

Photo credit: "Public Enemy" originally uploaded by Matheus Kawasaki

Amazingly enough, every time it starts to look dour for the security business, a new regulation comes down from the heavens to give security marketers another wave of fear, uncertainty, and doubt to throw at unsuspecting customers.

Yes, the recent "clarification" of PCI requirement 6.6 (pdf) is the latest in the ongoing wave of regulations that are meant to keep security professionals on the edge of their seats in Depend undergarments. Given the number of ways you can get killed today (just ask the security marketers for a few examples), there is no shame in a blowout or two every so often.

Though this rant is not about PCI 6.6, which I think is the kind of clarification we need to provide good direction to security professionals about what good practice is. My problem is in how some security companies are using the regulation to try to get some level of urgency, so they can sell their stuff.

I'm a businessman, and I've been in the game long enough to understand how it's played. I know fear-based marketing is part of the process. Security is like insurance and unless you think you are going to die or wreck your car or have a tree fall on your house, you wouldn't buy much insurance. So the job of the insurance salesperson is to convince you that not only will those scenarios happen, but they are even likely.

From a disclosure standpoint, I carry insurance on my life, my cars, and my house -even though I understand statistics and know that it's probably a bad deal. I still buy it anyway because you never know... But security is a bit different. Most folks understand what happens when a tree falls on your house (it isn't good). Most executives can't really envision what it means when a hacker sells your customer database to the Russian Business Network.

Yet again I digress. I got a head's up about a release from Ounce Labs last week when I was about to board a plane. Thankfully they had barf bags on the plane, so I didn't make a mess. The release pretty much made me sick because it represented pretty much everything I hate about security marketing. OK, not everything - but a lot.

Let's start at the title: "Leading Security Expert Asserts that PCI Compliance is Not Achievable Without Source Code Analysis." I hope you haven't eaten yet today because you are about to be served a FUD sandwich. Yummy. The release goes on to talk about how PCI compliance is about more than a firewall and that an organization cannot be truly secure (or PCI compliant) without reviewing their source code.

Let's be very clear. An organization CANNOT be truly secure - even if they review their source code. There is no such thing as "truly secure." But it does provide a good sound bite and some good FUD for security professionals to chew on.

In this case, Ounce is both right and wrong. Since I'm trying my best to be a half-full type of guy - they are right in that source code analysis needs to be part of any security program. You won't get much disagreement about that.

What I object to is saying that you cannot be compliant without source code review. Huh? How do they know? I'm sure there are lots of QSA's out there that will provide the rubber stamp via other methods to secure applications. Like a web app firewall or other compensating controls (like database monitoring and leak prevention).

PCI Assessments (and every audit for that matter) are a totally SUBJECTIVE process. It's based on the judgement of the auditor/assessor that shows up. Sure they have guidelines and even some new quality standards, but at the end of the day, it's based upon whether the auditor buys into your security strategy and believes you can meet the spirit of the regulation.

Anyone who tells you any different is:

1. Full of crap
2. Trying to sell you something
3. Just fell off the turnip truck
4. A combination of all 3

Relative to PCI 6.6, I personally believe that the best approach is to deploy a web application firewall (or some other application layer blocking technology) to eliminate the low hanging fruit of application attacks. At the same time, high profile applications should be reviewed for security problems, first with a scanner and then a pen test to isolate logic flaws.

Finally, to complete the secure application triad, the development process should evolve to include things like source code analysis and other secure coding techniques. But in the real world, it's unlikely you get to complete the triad, so you do your best to eliminate the most obvious issues and pray that the less obvious ones don't bite you in the ass.

Ultimately this gets back to money. Since the beginning of time, it's been easier for security folks to throw boxes at the problem, then to change behavior or evolve process. And the 6.6 clarification provides a clear excuse to look for a silver bullet wrapped in a 1U enclosure with flashing lights.

Ounce is just trying to say that a WAF is not a panacea. And that they have a quarter to make and investors to keep happy and customers really should look at source code analysis. Please, pretty please, with sugar on top. I get that, and I empathize with the folks that are trying to sell "solutions," when the market wants to apply a band-aid and make the problem go away.

But leveraging FUD, conjecture, and other marketing tactics like this still annoys the crap out of me. It's disappointing, but I'm a big boy and I know it will always be part of the process. That doesn't mean I won't continue to call it out for what it is.

OK, off soapbox now.

Photo credit: "FUD Truck makes a delivery.... (NEW! Savoring our FUD)" by crmudgeon23

 

2007 Incite: The Information Strikes Back
2007 finally brings acknowledgement that data/information security is different than protecting the network and servers. Yet, there is a major skills shortage in folks that understand how to protect applications and databases, resulting in accelerating interest in application and database security product offerings. But history will repeat itself, as a “fool with a tool” is still a fool, which doesn’t help customers solve any problems.

2008 Incite: The SDLC is your friend
As innovation in web application scanners is crushed by consolidation and web application firewalls still can’t find its sea legs, security professionals finally get religion about building secure applications, largely to avoid the PCI stick in the eye and embracing the reality that applications remain the path of least resistance. A long, hard cultural struggle ensues between security and software development personnel, but by focusing on building the most critical applications securely, the tide turns regarding the secure systems development lifecycle (SDLC).

Like yesterday’s piece on laptop encryption, I decided to split the 2007 information security Incite in 2008. Why? Because starting to implement a secure software development lifecycle (SDLC) is a key imperative this year. No you can’t wait until next year or the year after that. Software projects take years to go from idea through deployment to maintenance. Sure there are many iterations along the way, but if a project starts in 2008 and isn’t built thinking about security from the get-go, it’s not going to happen later.

I’m not going to go through the numbers of why it’s important to fix software defects early in the process. That is obvious or at least it should be. You want to eliminate issues prior to software being deployed. Bokay?

Here’s the rub. Organizationally, it’s hard to embrace secure coding standards. You need a seriously high level mandate to get everyone on board, and those take some time. Yesterday on Microsoft’s SDL blog, Michael Howard, details how Microsoft embraced their SDL. Basically they did it because Bill Gates told them to. They had no other choice. Unfortunately sometimes that’s what it takes to get the behavior changes that are required.

There are other reasons why the SDL needs to be a short-term imperative. It may be the first situation where security leadership influences other parts of IT and the business to think about security – before they have to. Remember, being a senior security professional requires sales and persuasion skills. Yes, these are more valuable than technical chops moving forward.

As I mentioned, it’s a long tough slog to get the developers to do a threat model when they are architecting the application. It’s hard to get Q/A to add more security tests to their harness because they are already behind since they got the code late. It’s hard to get them to hold up a release, which is already late, because there are serious security holes. Yes, it’s hard.

So how do you increment to get there, knowing that true adoption of the SDLC will take years? Basically you need to attack the issues on multiple fronts. You’ve got to make the investment in the process (SDLC), but you are also well suited to start thinking about how tools can supplement your efforts to amend the process.

Neither web application scanners nor web app firewalls ever really hit the big time. They remain interesting niche markets, but that’s far from what is required to solve the problem. Let’s hit the scanners first. Basically these tools tell you (at a high level) where the holes are in your applications. Actually, to be more correct, they will find SOME of the holes.

Web app scanners cannot find logic flaws in your applications. They have trouble detecting cross-site request forgery. You still need humans to do that. So running the systematic application penetration test is critical to uncovering those issues the technology doesn’t catch. The fact is the tools only go so far and we still need skilled humans to do a comprehensive analysis of an application.

Yet, running a current generation scanner is better than not running one at all. Two of the biggest players in that space were Watchfire and SPI Dynamics. Both were acquired last year by the development tools divisions of IBM and HP, respectively. There is a real risk that innovation slows for both of these companies, since the scanner business is hardly adjacent to development tools.

On the web app firewall front, these devices just never got going. And now you have new entrants (like Palo Alto Networks) and the existing firewall folks claiming to do more sophisticated application-level firewall functions. There are some protocols and attack vectors that web app firewalls handle, that the other devices can’t. Does that mean you need it? As usual, it depends on what you are trying to protect. If it’s that important, then the answer may be yes. But the market has spoken thus far, and web app firewalls are being voted off the island.

I want to wrap up with a little career advice. I get asked frequently where practitioners should focus their efforts and how they can maximize their opportunities and status within their organization. I tell them to learn how to break and protect applications. There is a major skills shortage in dealing with application security, so if you are looking to become more relevant – that’s where to supplement your skills.

Photo credit: freshelectrons

As application security functions are further integrated into UTM platforms in 2006, focus shifts to actually building software securely. The high tech vertical will lead the way in embracing behavioral changes for developers, source code analysis tools, and techniques to protect data at rest. New Web 2.0, SOA and on-demand application architectures with better security models increase in importance.

Grade: C-

Original Days of Incite post: here
Incite Redux post: here

Ouch! What’s the lesson learned from this Incite in 2006? Never minimize the willingness of developers to keep doing what they were doing, even if it’s the wrong thing to do. The secure source code analysis players did announce some high profile reference accounts, but not enough to say this market happened in any way, shape or form in 2006.

Given my strong belief that Mr. Market is right over time, I don’t think counting on developers to get it right is a good plan. So where does that leave customers? Same place we were at the beginning of 2006, focused on doing what we can. You know, taking responsibility for things that are within our control.

We did see an increasing interest in web application scanners, which is happening in the nick of time. Given the path of least resistance to compromise a network is now through the web applications, doing a scan before setting an application loose on the world is a good thing.

But as Jeremiah Grossman points out in this tremendous post (here), we have a bit of a scaling issue relative to the expertise required to assess all of these applications. There is no way there will be enough qualified folks to test all the applications that need to be tested. So that means YOU (yes, I’m pointing at you) need to get a lot smarter on Web application security in 2007.

One part of the Incite that was dead on is the focus on protecting data at rest. If you read between the lines of the big EMC/RSA deal, you get to the conclusion pretty fast that securing all that data stored on EMC spindles was a key driver for the $2.1 BIG (as in Billion) they spent. Look for continued interest in this space (including database monitoring) for quite a while.

Finally, Web 2.0 and SOA hit their strides in 2006, but the security implications are largely unknown. Everyone acknowledges that these new application architectures are fundamentally different and will require fundamentally different approaches to secure these applications. Beyond that, there is precious little consensus on what the answer is.

In 2006 we asked the right questions about application security. Our task in 2007 is to start moving towards the answers because the state of application security is not where it needs to be. Not by a long shot.

The folks at TechTarget were kind enough to let me republish my posts at the Expert Answer Center here. This post first appeared on July 13. Link here.

Over the past week or so, I hope you've gotten a feel that I'm not really a touchy-feely type of guy. And I need to work hard to be optimistic about things because I'm wired to find problems and try to figure out solutions. It makes my wife crazy ("Can't you ever just be happy?!?!"), but that trait also makes me well suited to being an analyst.

But this isn't about optimism or even pessimism; it's about securing your networks and critical information assets. If something goes down the only touchy-feely you are going to get is a boot on your backside. Wishing your network is secure doesn't help either. As my father-in-law says, "If you hope, you are a dope." I tend to use the "hope is not a strategy" cliché more than I would prefer. The fact remains; you are either a hero or goat depending on whether the myriad of attacks you see every day are successful.

To be clear, I'm not talking about thinking positively here (though I heard it does help, maybe I should try it someday), I'm talking about acting positively. And in a security context, that means only allowing the stuff you specifically want to run on your network, and blocking everything else.

You can first start this on your perimeter. Basically, your access router shouldn't allow anything unless you specifically decide it should. This technique is called "default-deny." Depending on what you have running, that probably means SMTP and HTTP at a minimum. Maybe a few other protocols as well, but nothing else. Shut it down. If you block stuff before it even gets to your network, you are much better off.

Same deal goes for your firewall. Take a look at what is probably a panoply of firewall rules that may not even be relevant anymore. Have you compared what you are allowing and blocking to the router? Make sure every rule in there is for a VERY good reason and that the firewall and router configurations are in sync. Don't take chances by leaving your perimeter sloppy.

Unfortunately, with more and more applications looking like HTTP and coming in over port 80, this technique is not as effective as it used to be. That's why we need stuff like intrusion prevention, deep packet inspection, and anomaly detection to ensure that port 80 traffic isn't malicious. But doing this little stuff on your existing firewall and router is still effective and will make a difference.

Next, let's look at the desktops (or laptops, as it may be) that access your network. Lots of folks get compromised because their employees surf to a bad site (either through phishing or pharming). They can also contract something in a coffee shop, which they so kindly proliferate through your network upon their return.

What you are looking for here is a strong, positive endpoint security posture. Basically, malware infects a machine by running executables that compromise the machine, turn off its defenses and then spread to other devices. If you use the trusty old "default-deny" approach, specifying which applications you allow to run on your devices, the malware has a hard time spreading.

Of course, this technique can be controversial, especially if you decide that iTunes is not an authorized application. And it's not foolproof -- nothing is. But I've seen this approach be very successful in stopping the contraction and spread of malware.

So the next time someone tells you to think positive, you can say with a straight face that you always do. Maybe smile for good nature and say "Kumbaya!" It'll make everyone feel better.

This morning I stumbled upon Roger Grimes' column in InfoWorld and his recent post "Effective Security isn't easy, but it's possible." Link here. In this piece, he makes a number of contentions that make a lot of sense and highlights the point that security your environment is achievable, but there is a cost - and I'm not talking about money.

The thing I didn't see in Roger's column that I think is pretty important is every company's threshold for security is going to be different. Some are willing to accept a bit more risk in order to either improve the user experience or perform an important business function. But the key here is for the end user to MAKE that decision, as opposed to having it thrust upon them.

Some of Roger's ideas will work for your environment, some not so much. But this is the kind of simple stuff (in concept anyway) that can really make a big difference in your security posture.

So let's go through Roger's list of "effective security solutions" (in his order of effectiveness):

1. Do not allow end-users to run or install unauthorized software - Bingo. This is why application control software is so effective at stopping malware. If users can't do stupid things, everyone is better off.
   
   
2. Don't put unnecessary software on the authorized list - This is where the rubber of #1 meets the road of the customers. He specifically mentions Flash, Real Player and iTunes. I'd posit that for many employees, RealPlayer is the only one that is "optional." With iTunes being a prevalent distribution mechanisms for podcasts (where folks can get info directly related to their jobs), I'm not sure iTunes is the villain it once seemed. And anyone that surfs the web needs Flash. Do these add risk, yes! But I'm not sure a strategy preventing these applications is defendable.
   
   
3. Implement default deny - Amen to this. Otherwise called the positive security model, unless you say it's good, it's not - so you block it. This can be implemented on routers and firewalls and will dramatically increase your perimeter security posture.
   
   
4. Don't allow end-users to be logged in as Administrator - This is easier said than done, and Roger admits that. But getting new applications isn't a very good answer for most folks. Vista will do a lot to help this problem for Windows users.
   
   
5. Automate comprehensive patching - This is great advice. A lot of companies have rigorous change control that takes weeks to authorize a patch. That is weeks of exposure. I say patch first, clean up the small percentage of messes later.
   
   
6. Convert all inbound email to plain text - Hmm. I'm torn about this one. If you have application control implemented, I'm not sure this does anything but piss people off that their email looks like crap.
   
   
7. Enforce long passwords - I don't buy this one. So it takes a password cracker 3 hours instead of 3 minutes. And the reality is that hackers get passwords via social engineering anyway. If you are worried about it, two factor (like BioPassword) could be a good alternative.
   
   
8. Encrypt all confidential data by default - I'm not sure what this means and how you do it. This only solves half the problem. What happens when that data is loaded to a laptop or sent in an email?
   
   
9. Spend less money on new security software and more money on reviewing the basics - This is the best one of the bunch. A misconfigured firewall is about as good as not having one, so yes - in all of our desire to get that shiny new thing, we tend to forget about the simple stuff that can kill us.
   
   
10. Hack and audit your own network regularly - Again, this is great advice. Public companies need to do this and private companies should as well. You never know how effective your defense are until you try to break them.

So in general, Roger's list is real good. I agree that all of these are possible, given a CIO/CISO with an iron fist that can ram a no iTunes policy down the throats of the users. I know they exist, but I don't know too many.

There were clearly pockets of strength in the security space demonstrated at RSA. Here's a quick list of the hotties at the show (and I'm not even focusing on the return of eye candy to RSA):

• Identity Management - There was lots of activity at the show, validating the choice of IdM as the subject of the first battle plan (available at the end of the month). All of the big guys (Microsoft, IBM, Sun, HP, et al) where there in force and lots of other network-security oriented vendors were talking about the linkages between IdM and network access control (NAC) in an effort to differentiate. My checks with resellers and users indicated the IdM strength is not vendor push. It's happening. Another data point was the overflowing sessions on IdM during the conference - I'm talking standing room only. IdM is hot.
  
  
• Network Access Control - A bit further off is NAC, but there was tons of activity in this space as well. The big (Cisco, Microsoft, Symantec, McAfee) and the little (ConSentry, ForeScout, Lockdown, Mirage, StillSecure, Vernier) were well represented and NAC will be the next big thing. The clear challenge for the start-ups will be to focus on clear differentiation to remain relevant. I can't recall a hot market space where the big players are delivering products, mostly home-grown, in the same timeframe as the start-up. Big is clearly the new small.
  
  
• Encryption - Scarily enough, this may actually be the year that encryption happens. Sure, there is still confusion as to what you really can do, and it's not nearly transparent enough. But the rising tide is lifting all the boats (PGP, PostX and Voltage notably) and it seems that a decent portion of that compliance budget is being allocated to rolling out crypto.
  
  
• OATH - The stand set up to demonstrate the Open Standard for Authentication seemed to be packed the entire show. There were something like 10 vendors in there demonstrating their OATH compatible solutions, and this standard is taking root. Given the momentum for IdM and NAC, the need for continued focus on the authentication part of the equation is clear.
  
  
• "Leak Prevention" - It's not clear what this category is called quite yet, but it's basically about making sure that private data and intellectual property stays where it belongs. There was a lot of activity in this space.
  
  
• Web/Application/Database Security - There is a lot of interest in boxes (and software too, I guess) that protects applications and databases from targeted attacks. This market is poised to be big in 2007, so figure next year's RSA show will have this as a prominent theme.
  
  

Clearly this is an unscientific analysis of what was going on, but by roaming around the show floor a bit and talking to lots of people you get a pretty good feel for what is going on.

Bill Gates of Microsoft kicked off the festivities at RSA yesterday with his seemingly annual keynote. At times Microsoft announces new stuff and puts other vendors on notice that the "Redmondsters" are coming for them.

The hope was that Bill Gates would say something of substance. Basically give customers hope that their lives would get better. That the "new" standards friendly Microsoft would not continue to focus on locking customers into a homogenous Windows environment. That Microsoft could evangelize a convincing and achievable security framework for how all the pieces fit together, including legacy (and non-Microsoft) platforms.

I'm sure customers were disappointed by what they saw. I know I was. I thought the keynote sucked.

OK, I said it. Bill was not on his game. The demos were simplistic and not compelling. Their strategy depends on WIDESPREAD, actually UBIQUITOUS adoption of Microsoft's technology on both client and server. Everything was based on Vista, and customers won't be able to get Vista until the end of this year. Deployment won't start in earnest until mid-07 and be sufficiently pervasive (for security to work anyway) for years after that. The really interesting stuff (like Network Access Protection - NAP) won't be available until Longhorn Server, which is mid-2007 best case.

There was also no mention of how Microsoft's stuff is supposed to work with the network. If I totally adopt Microsoft's stuff, do I get to throw out my firewalls? 

Microsoft basically said customers are on their own unless they can fully adopt Vista and Longhorn Server. That's disappointing. So customers, hunker down and make sure your patch process is strong, because you'll be using it for the next 4-5 years. Don't throw out your firewalls yet.

On the positive side, NAP looked pretty cool, but it was also not clear what kind of overhead is involved in setting up access policies for the network. Microsoft's focus on Identity is also good and sorely needed. Their work to harden the Windows platform is positive, as well as upgrading development tools to be more secure.

That's good stuff, but will take years to take root. I remember a quote from Bill himself about how we overestimate the amount of progress in 2-3 years, but underestimate the progress made in a decade. That's absolutely true. But Bill must have forgotten based on another "projection" he made.

"Passwords should be gone in 3-4 years."

You figure he would have learned something from the RSA spam debacle two years ago... But I guess not. Seems that Bill's new pet project is smart cards (since the SecurID didn't work for that purpose), so he envisions a world without passwords. It's not going to happen. Not anytime soon anyway. Here are a couple of reasons why:

1. Adoption timeframe - It takes customers 3-4 years to decide to upgrade to a new Microsoft operation system. Some of the technology requires new products, or at least the latest current version of Windows Server.
   
   
2. Federation must happen - Sure, large companies are already working on it, but in order to move away from passwords, every company must jump on board. And there are still competing standards (WS-* and SAML 2.0), though most products will support both, the presence of both complicates things.
   
   
3. Passwords are good enough - If I'm transferring a million dollars, I probably want stronger authentication. To log into my network, a password is fine. And will remain fine. Reduced sign-on can make passwords easier to deal with, but to think everything will move to a new smart card based reality is plain delusional.
   

Ultimately, I get that Microsoft needs to have a good reason for customers to upgrade to the new platforms (to keep growth going) and maybe trying to vilify passwords is a way to stimulate action. But I don't think so. There are places for stronger authentication and places where it's not worth the effort.

I hope John Chambers of Cisco does better tomorrow.