Blog Host: Mike Rothman - president and principal analyst, Security Incite READ ENTIRE BIO

The moat is great. You put up a nice picture of a castle with a large moat protecting it and people get it. The bad guys are on the outside, so you build a deep, wide gulf between you and them and life is good, no?

Unfortunately, the moat is passé. Thinking about security as a moat no longer works, because you are intentionally dropping the drawbridge to let some of your "trusted" trading partners in to streamline operations. Or, at least, that was the story you were told. What about all of those insiders that have access because they work for you (or are consultants?

Nowadays, we don't know who the bad guys are. So a deeper and wider moat is not really going to help. This phenomenon is called "de-perimeterization" in the trade. I'm not sure who came up with that term, and it kind of sucks, but it's what we've got. Suffice it to say, you need to spend some time focusing on how you are going to protect your environment when the bad guys can be anywhere. Literally.

So now you need to look at security from two perspectives. The first is "outside-in," which is still important. Bad guys are still out there, and, if you let your guard down, they'll compromise your defenses, turn your machines into zombies and steal your private data. Although the moat is no longer sufficient, it's still necessary.

The new wrinkle here is something that my pal Ted Julian (over at Application Security) calls "inside-out." Basically, you need to figure out how the data is used, who has rights to it, and a way to protect it. This is more art than science right now, and sometimes there aren't good answers. You should be thinking about how products in the database, content, and web application security spaces are potential solutions.

I've come up with a security architecture, called "Pragmatic Security," that aims to simplify how we talk about security, and make the point regarding the need to treat your infrastructure (outside-in) differently than your data/information/content (inside-out). Check out that post here. Of course, the lines blur at times, but this model has been well-received by folks trying to restore order to the chaos.

As disappointed as I am to not be able to explain security with the moat analogy anymore, I think it's good for the business. Maybe now we have to talk about two moats: one protecting the perimeter and one for the data center. Not sure it gets there, but it's a start.
Posted by Mike Rothman Thinking positively about security
13 JUL 2006 17:43 EDT (21:43, GMT)
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.
Posted by Mike Rothman Your vendor is bought, now what?
13 JUL 2006 15:33 EDT (19:33, GMT)
There has been a lot of M&A activity in the security space of late. With EMC buying RSA and Secure Computing acquiring CipherTrust, I'm sure there is a lot of angst in the end user community about the impact of these mergers on the only thing that's important -- you and the security of your environment.

M&A in the security space (actually all of technology for that matter) is a fact of life. So grinding your teeth about it will only make your dentist happy. But there are a set of activities that end users can undertake, once a key vendor is acquired, that will help.

The reason I even bring this up is an article I found in Information Security Mag from May of 2006 that seems like it must have been lost for four or five years (or possibly misdated). It's been a long time since I've seen Axent and Platinum Technology used as an example in anything. This article talks about the potential impact of mergers on customers and the conclusions are pretty close to reality.

From my perspective, very few deals actually are in the customer's best interest. Deals are driven by economics, and, inevitably, the integration causes the acquired company to lose momentum both on the distribution/sales side as well as in improving the product. When I was on the vendor side, we would joke that your second happiest day is when your biggest competitor gets acquired. That gives you at least six months of runway to do damage and take share as they look internally and focus on integration.

Of course, the happiest day is when you get acquired. But at that point, you are more likely thinking about your new big house or fancy sports car than about your customers.

So, a key vendor of yours gets acquired, what do you do? I mapped out my thoughts in this post from April, but let me summarize quickly.

1. Do nothing at first -- Just because a deal is announced doesn't mean it's going to close (remember Check Point/Sourcefire?). So until the deal actually closes, it's business as usual.
2. Call a meeting -- Within a week or two of the deal closing, call a meeting with the surviving entity. Hopefully you'll know who your account rep is at that point. You'll want to ask three questions.
   • How does my product (the one that was bought) fit into your strategy?
   • Is my account team changing?
   • What is the 18 month product roadmap?

Listen very carefully to the answers, because you should have a gut feel at the end of the meeting whether the integration is going to be a train wreck. Based on what you learn, then you'll have two more decisions to make.

1. Look at how to do more business -- so if you are happy with the products, account team and roadmap -- you should be seeing if there are other opportunities to do business with the vendor. This would be a good thing.
2. Look for Plan B -- if the answers are no good, then start talking to competitors immediately. Most will be very willing to defer costs until your existing contract/maintenance expire, in order to displace a competitor.

In either case, DO NOT be the victim here. You are driving your security strategy, and if you don't like what you hear from the vendor, throw them under the bus. It's not like you've got any vested interest or political capital tied up with the new guy. Blame the merger and move on. There is another 750 other security companies ready, willing and able to sell you stuff.
Posted by Mike Rothman The joke of analysts' vendor rankings
12 JUL 2006 14:35 EDT (18:35, GMT)
As I discussed yesterday, I've spend a lot of time helping end users buy security products more effectively. Inevitably the customers want a recommendation on what product they should buy. Most are chagrined when I tell them that I won't do that. I can certainly provide some perspective on who are the market leaders, based on lots of criteria. But I won't recommend a product for them. That's their job, because it's their ass that's on the line if the decision is wrong. You can't outsource the decision, not if you like your job anyway.

But not all of the analysts out there think this way. The business of ranking vendors is a big one. Whether you want to call it a Magic Quadrant, a Wave, market sizing, or anything else -- these are all fundamentally the same. They strive to generate a generic answer to what is the best product, based upon some arbitrary criteria.

Here's the problem. Your environment isn't generic, is it? If you look exactly like companies of similar size in similar businesses, then what is your differentiation? Why are you different? There are definitely similarities between businesses based on size and industry, but each organization has their own strategic imperatives, culture, threshold for pain and budgets. You cannot generically decide what products will potentially be best.

And even worse, as pointed out by looking at James Governor's post on MQ sample sizes and this Forrester post, you see that these opinions are based on a very small sample sizes. Help me understand how Forrester decides market leadership based upon talking to seven vendors and 10 users? Gartner at least "talks" to a hundred or so users. But this is not statistically significant stuff, let's be clear about that.

Sure Gartner and the others field lots of inbound calls, but rankings are based on specific quantitative criteria based upon qualitative conversations. So it all gets back to opinion. They are making it up. Which is OK, but only if you trust the analyst.

As for me, I don't trust anyone. Sure, it's a personality quirk, but if my career was on the line, I'd be real careful about using these tools as key arbiters of the decision.

I recommend you use an MQ or a Wave or any other chart as a guidepost. Do your own research and potentially validate your findings relative to the analyst chart. But don't allow the chart to dictate your short list. There are a lot of vendors that don't even get on the chart or are poorly ranked because they don't (or can't) play the game. That doesn't mean those vendors wouldn't be the best fit for what you need to do.

But what annoys me the most is that these analysts agree with me on how and when to use a chart. They don't want the responsibility. I ranted about that on my personal blog. The problem is that customers don't get it and until they do, these vendor rankings will be much more important then they should be.
Posted by Mike Rothman Why request for proposals are still relevant
11 JUL 2006 20:58 EDT (00:58, GMT)
One of the things I find most entertaining about my job is helping end users buy security products. It is amazing that so many sophisticated technicians have such a hard time buying the products. I guess I shouldn't be surprised because many of the folks that drive the purchase process end up as managers after starting their career on the technical side.

It was a post I saw on Arbor Network's blog that got me thinking about this topic again. Carlos Morales makes the point that pretty much everyone hates request for proposals (RFP). They waste time and resources, request a feature list that no vendor can meet, and usually involve a ridiculously aggressive deadline. I agree that, ultimately, RFPs very rarely help the purchase process.

BUT, what he's forgetting is that RFPs have nothing to do with streamlining the purchase process and very little to do with trying to save money. It's all about covering someone's ass. There, I said it. Pure and simple, RFPs are used to cover the respective asses of the folks that buy things for larger companies and government entities.

I suppose that's a pretty cynical position to take, but it's true. As Carlos points out, there are ways to buy products that wouldn't require doing a formal RFP. In fact, I published an eBook on that very topic. It's available for those that sign up for my daily newsletter or email me. I lay out a multi-step process to buy a product, which may or may not involve an RFP, that can be tailored to what you need to buy and what process your organization requires.

Thanks to Carlos for making a number of very relevant points here, but ultimately it doesn't matter. We'll still see RFPs and probably more of them. As long as folks have an ass to cover, they'll continue to use the RFP process (and magic quadrants and other analyst hocus pocus -- but that's a discussion for another day) to be able to point the finger at someone else. And when the stuff hits the fan, you can only hope you still have a finger to point.
Posted by Mike Rothman The dichotomy of Microsoft's advance notification
09 JUL 2006 22:02 EDT (02:02, GMT)
On my Security Incite blog, I've made no bones about how sick I am of Patch Tuesday (here and here). Thankfully the preamble to July's festivities happens during a holiday week, so many of the beat reporters that need this stuff for content are MIA. That's a good thing in my book. But it got me thinking, why does Microsoft pre-announce what they are going to fix anyway?

I checked out Microsoft's web site and saw the following explanation:

As part of the monthly security bulletin release cycle, Microsoft provides advance notification to our customers on the number of new security updates being released, the products affected, the aggregate maximum severity and information about detection tools relevant to the update. This is intended to help our customers plan for the deployment of these security updates more effectively.

The cynical and devious bastard in me thinks Microsoft is opening holes by pointing out exposures that folks may not have known about. So now the bad guys have roughly six days to get an exploit out there and do some damage.

It's kind of like a bank saying, "We're fortifying the sub-basement under our vault next Tuesday." If you are a bank robber, you know your timetable and where the exposure is. Of course, there is still a lot of work to get in, but you've got a lot more information than you did before. You probably assumed the sub-basement was already fortified, no?

Alas, I also see the other point of view, which is that enterprises (both small and large) need to plan. If Microsoft drops a bomb on Tuesday with a very high profile patch that requires immediate attention, administrators get really pissed. They like to know exactly what is happening and why, even though many of them use automated patching products to "set it and forget it" once it's QA'd by the patch vendor.

The conclusion I come to is that Microsoft is dealing in numbers that mere mortals could only dream about. When they patch something it goes out in volumes of HUNDREDS of millions, not like 10 or 15 or even 1000. They've honed in on a patching process that is far from perfect, but works pretty good over a long period of time. To my knowledge, no one has taken a pre-announced patch and exploited it in the window of opportunity. So they have their bases covered.

There is also a halo effect with most customers about coming clean with issues. Everyone knows that every piece of software has vulnerabilities. Sure Microsoft's software has a lot (relatively more than others), but they acknowledge it and are moving to fix the systemic root causes of the problems.

One man's opinion is that Oracle and Apple should communicate a bit more about things they find. Apple just fixes things, but their software makes the updates relatively transparent and their lack of presence in the data center makes this a non-issue for most enterprises. Oracle, on the other hand, patches once a quarter and doesn't even get to everything. So it's hard to point to Microsoft as a security innovator, but they are eons ahead of the other folks relative to patching problems they created.
Posted by Mike Rothman The hogwash of security ROI
07 JUL 2006 12:42 EDT (16:42, GMT)
As the Internet bubble burst, the bean counters reemerged as true power brokers over all things IT. For the most part that was a good thing, since IT pretty much spent like drunken sailors towards the end of the millennium and the hangover was pretty severe. It was up to the accountants to bring the Gatorade and Advil (my favorite hangover remedy) to restore some sanity.

In tight budget cycles, you need to rely pretty heavily on ROI (return on investment) calculations to justify spending anything. Over the years a number of folks got pretty good at showing how things like CRM and business intelligence provide a distinct return to the business. Those were easy cases to build because the technology really did favorably impact the business. But security professionals have always struggled with this, pretty much since the beginning of time.

Why? Because quantifying risk is an inexact science at best. You have no idea what the downtime of specific assets really costs. Figuring out "productivity improvements" due to not making someone jump through as many authentication hoops is suspect. And ultimately none of these calculations matter. The day an attack is successful and a network or application is compromised, all bets are off. The next day about 50 POs are cut to pretty much buy every product a technologist can get their hands on. Fool me once, shame on you. Fool me twice... or so the saying goes.

I bring this up because folks like Pete Lindstrom have been trying to do research and come up with a defendable model for what he calls ROSI (return on security investment) for years. And he's failed. There are so many caveats to make the number believable, it's just not. This has nothing to do with Pete's creativity or talent, he did his best. It's more about the impracticality of doing it in the first place.

But what really set me off was an article posted on SearchCIO from some folks at Alinean, who specialize in developing ROI models. I think that approach is hogwash. There is no way to gather most of those numbers. Not in a way where you could sleep well at night. If you are okay presenting those numbers to a CIO or CFO with your credibility and career on the line, more power to you.

I know that my general disdain for ROI models puts many of my clients and readers of my personal blog in a bind because their bean counters want to see ROI information. But I say now is the time to RISE UP and fight the power. No I haven't been listening to my classic Public Enemy CDs again, I really mean it.

In the time you'd spend making up some cockamamie ROI model, you could be doing real work. An alternative approach is to take some of that hard fought budget and get a penetration test. I bet that within a day, your network would be proven to be Swiss cheese. Take the pen test report to your CFO and don't forget your stack of POs for all the new stuff you need to buy.

There's your ROI model. A sophisticated hacker will make mincemeat out of our network unless you buy some stuff. How about them apples, Big Mr. Bean Counter? And while we're at it, let's discuss that BMW I've been looking at.
Posted by Mike Rothman Big is the new small
06 JUL 2006 00:10 EDT (04:10, GMT)
One of the topics I cover on my personal blog is vendor dynamics, paying particularly close attention to how these dynamics impact the tactical decisions that security administrators make on a daily basis.

The concept that has gained the most legs over the past few months is "Big is the New Small," which is basically just an acknowledgement that end users are tired of the status quo. End users no longer have the time, money or patience to continue buying all sorts of widgets from innovative start-ups to address very narrow security exposures. Ten years later, this approach has resulted in most organizations having a hodge-podge of crap deployed to solve security problems. Even worse, these products all use different management consoles, different techniques, and offer varying results in stopping the exponentially increasing number of security challenges faced by us all. The only constant has been the need for the CUSTOMER to integrate all the pieces.

Additionally, start-ups cannot provide the breadth that end users need to truly address the security issue. So, consolidation has resulted with "Big Security" vendors promising to do the integration, not you. By assembling enough pieces to provide "good enough" protection, customers feel good about their infrastructure services and don't have to spend all day with duct tape and bailing wire to make all of that stuff work together.

Now to be clear, the "architectures" that the big vendors (Cisco, Symantec, McAfee, Microsoft, etc.) have put forth are still more theory than reality. Integration remains largely a myth. But when you see some of these folks give a pitch, end users start to foam at the mouth. Most of my conversations with end users also reinforce the frustration of this customer-driven integration and I believe that many will start voting with their dollars for tighter integration from bigger security players.

Does that mean we'll get to a Big Security reality overnight? Of course not. But shame on me if I don't alert you to this new architectural construct.

You make tactical decisions every day and you really need to start thinking a bit more strategically about how all of those decisions play into the bigger entirety of a security architecture.

For more context, you can revisit my original posts on the topic here and here.
Posted by Mike Rothman The age of research accountability
03 JUL 2006 21:21 EDT (01:21, GMT)
Welcome to my two-week stint in the Expert Answer Center. Over the next two weeks, I'll provide commentary on what is going on in the realm of information security and try to provide some "incite" to get you thinking about ways you can make your environment more secure. One of the things I find most offensive about IT research is the lack of accountability.

You know what I'm talking about. Inexperienced analysts make ill-advised market projections and the end users that actually take their advice are left holding the bag. Does anyone ever go back and really track whether these folks are full of crap? Does anyone ever call these folks out for just being wrong? Sadly, the answer has been no.

When I started Security Incite back in January, I wanted it to be different. I wanted to add value and help end users make better decisions about how to secure their environments. I want to make the tough calls, even if they are unpopular. I expect to be held accountable for when I made stupid projections. Yet, there is no independent body to keep tabs on folks like me, so I decided to do it myself.

The first thing I did was publish a set of "Incites," or trends of what I expected to happen in 2006. Those Incites are attached to this blog posting. I got some great feedback on those initial perspectives and I knew some would be close and others... not so much.

Most folks revisit their projections annually, but I didn't think that was often enough. So I committed to evaluating my Incites twice a year. You can find the Incites Redux series that I posted to my personal blog here, here, here and here.

As you can see, some of my thinking was right on the money, especially relative to UTM, compliance, and security management. My ideas on application security and security education still have a chance, but clearly haven't happened to the extent I expected.

But if there is one thing I'd like you to develop over the next two weeks, it's an appreciation for the value of good industry analysis. Maybe I'm being a bit presumptuous relative to what is "good," but at a minimum you deserve someone to tell you when they hit the target, and when they don't. That much I promise -- so fasten your seat belts -- we're going to have a fun ride.

2006 Security Incites and Predictions

Mike Rothman is President and Principal Analyst of Security Incite, an Atlanta-based information security research firm. You can catch Mike's Daily Incite newsletter with his unique take on the news by sending email to dailyincite@securityincite.net or visiting the newsletter's page.
Posted by Mike Rothman