Research

Yesterday I got involved in an interesting Twitter discussion with Jeremiah Grossman, Chris Eng, Chris Wysopal, and Shrdlu that was inspired by Shrdlu’s post on application security over at Layer8. I sort of suck at 140 character responses, so I figured a blog post was in order. The essence of our discussion was that in organizations with a mature SDLC (security development lifecycle), you shouldn’t need to prove that a vulnerability is exploitable. Once detected, it should be slotted for repair and prioritized based on available information. While I think very few organizations are this mature, I can’t argue with that position (taken by Wysopal). In a mature program you will know what parts of your application the code affects, what potential data is exposed, and even the possible exploitability. You know the data flow, ingress/egress paths, code dependencies, and all the other little things that add up to exploitability. These flaws are more likely to be discovered during code assessment than a vulnerability scan. And biggest of all, you don’t need to prove every vulnerability to management and developers. But I don’t think this, in any way, obviates the value of penetration testing to determine exploitability. First we need to recognize that – especially with web applications – the line between a vulnerability assessment and penetration test is an artificial construct created to assuage the fears of the market in the early days of VA. Assessment and penetration testing are on continuum, and the boundary is a squishy matter of depth, rather than a hard line with clear demarcation. Effectively, every vulnerability scan is the early stage of a (potential) penetration test. And while this difference may be more distinct for a platform, where you check something like patch level, it’s even more vague for a web application, where the mere act of scanning custom code often involves some level of exploitation techniques. I’m no pen tester, but this is one area where I’ve spent reasonable time getting my hands dirty – using various free and commercial tools against both test and (my own) production systems. I’ve even screwed up the Securosis site by misconfiguring my tool and accidentally changing site functionality during what should have been a “safe” scan. I see what we call a vulnerability scan as merely the first, incomplete step of a longer and more involved process. In some cases the scan provides enough information to make an appropriate risk decision, while in others we need to go deeper to determine the full impact of the issue. But here’s the clincher – the more information you have on your environment, the less depth you need to make this decision. The greater your ability to analyze the available variables to determine risk exposure, the less you need to actually test exploitability. This all presumes some sort of ideal state, which is why I don’t ever see the value of penetration testing declining significantly. I think even in a mature organization we will only ever have sufficient information to make exploitation testing unnecessary for a small number of our applications. It isn’t merely a matter of cost or tools, but an effect of normal human behavior and attention spans. Additionally, we cannot analyze all the third party code in our environment to the same degree as our own code. As we described a bit in our Building a Web Application Security Program paper, these are all interlocking pieces of the puzzle. I don’t see any of these as in competition in the long term – once we have the maturity and resources to acquire and use these techniques and tools together. Code analysis and penetration testing are complementary techniques that provide different data to secure our applications. Sometimes we need one or the other, and often we need both. Share:

Ah yes, 2011 is here. A new year, which means it’s time to put into action all of those wonderful plans you’ve been percolating over the holidays. Oh, you don’t have plans, besides getting through the day, that is? I get that. The truth is things aren’t likely to be better in 2011 – probably not even tolerable. But we persevere because that’s what we do, although a lot of folks (including AndyITGuy, among others) continue talking burnout risk. And that means we have to refocus. A while back I did a presentation called The Pursuit of Security Happyness. It was my thoughts on how to maintain your sanity while the world continues to burn down around you. But that was about you. If you drew the short straw, you may be in some kind of management position. That means you are not only responsible for your own happiness, but have a bunch of other folks looking to you for inspiration and guidance. I know, you probably don’t feel like much of a role model, but you drew the short straw, remember? Own it, and work at it. The fact remains that most security folks aren’t very good at managing. Neither their security program (what the Pragmatic CSO is about), nor their people. With it being a new year and all, maybe it’s a good idea to start thinking about your management skills as well. Where do you start? I’m glad you asked… I stumbled across a post from Richard Bejtlich over the break, which starts with a discussion about how Steve Jobs builds teams and why they are successful. Yes, you need good people. Yes, the bulk of your time must be spent finding these people. But that’s not interesting. What’s interesting is making the mission exciting. Smart talented folks can work anywhere. As a manager, you need to get them excited about working with you and solving the problems you need to solve. LonerVamp highlighted a great quote at the bottom of Bejtlich’s post: Real IT/security talent will work where they make a difference, not where they reduce costs, “align w/business,” or serve other lame ends. So that’s what you need to focus on. To be clear, someone has to align with business. Someone also has to reduce costs and serve all those lame ends, which was LonerVamp’s point. Unfortunately as a manager, that is likely you. Your job as a manager is to give your people the opportunity to be successful. It means dealing with the stuff they shouldn’t have to. That means making sure they understand the goal and getting them excited about it. Right, you need to be a Security Tony Robbins, and motivate your folks to continue jumping into the meat grinder every day. And all of this is easier said than done. But remember, it’s a new year. If you can’t get excited about what you do now, maybe you need to check out these tips on making your resume kick ass. Share:

Well, it didn’t take long to see the bankers and lawyers stayed busy over the holidays. Dell announced they are acquiring SecureWorks, the MSSP, for an undisclosed sum. Yeah, you are probably thinking the same thing I did initially. Dell? WTF? Now I can certainly rationalize the need for Big IT to expand their services capabilities. IBM started the trend (and got into security directly) with the ISS deal, and HP bought EDS to keep pace. Dell bought Perot as well because that was the me-too thing to do. Dell also tried to buy their way into the storage market, but was foiled by HP’s 3Par deal. Kind of makes you wonder if Dell spent stupid money on this deal (thus the undisclosed sum) because HP was bidding also. But I’ll leave the speculation on bidding wars to others, and focus on the merits of the deal. For SecureWorks, it’s pretty straightforward. Let me list the ways this deal makes sense for them: Cash Simoleons Tons of sales people Euros Global distribution Shekels Balance sheet (for expansion and more deals) Krugerands And I figure it was a lot of cash, because there was nothing forcing SecureWorks to sell now. Besides a big pile of money. Though there was always trepidation inside SecureWorks about doing a deal because of the likelihood of screwing up the corporate culture built by Mike Cote and his team. I guess the bags of money Michael Dell hauled down to Atlanta must have been pretty compelling. Channel Leverage SecureWorks started by focusing on smaller companies. Dell sells computer equipment to a lot of small companies. So there is a clear upside here. Just to give you an idea of scale, I have a buddy who sells for Dell in GA. He has half the state, and his patch is about 5,000 companies. And about 2,500 have done business with Dell over the past two years. That’s half of a relatively small state. But we’ve seen countless deals flounder, and this one will too unless SecureWorks can 1) educate Dell’s field on why security services are a good thing (even if they don’t get bolted into racks), and 2) package and provision the services efficiently and at scale to hit a broader market target. Dell is also global, and that is a key focus for SecureWorks in 2011. They bought a small player in the UK last year, and this gives them a business operations platform to scale globally a lot more quickly than they could do themselves. So there is a lot of upside, assuming reasonable deal integration. No, that’s not a good assumption. I know that. Customer Impact If you are currently a SecureWorks customer, it’s unlikely you’ll notice any difference. The early indications are that Dell won’t be messing with the operations of how security services are delivered. In fact, Dell plans to bring every single SecureWorks employee on board when the deal closes. That is good news for customers (and rather unique, considering today’s cut costs above all else mentality). Optimistically, as the business scales, Dell has plenty of compute horsepower (and global operations centers) to facilitate building out new data centers. If you are a Dell customer, call your Dell rep right now and ask them about the new SecureWorks services. Odds are you’ll hear crickets on the line. It’s not like you are buying a lot of security from Dell now anyway, so does having SecureWorks on board change that? Will you take Dell seriously as a security player now? Yeah, me neither. Though I should be open-minded here, so if this does change your perception, drop a comment below. It would be interesting to hear if that’s true. But I guess every company has to start somewhere as they enter new markets. Little Competitive Impact It’s hard to see how this deal either helps or hinders SecureWorks’ ability to compete. Some competitors were on Twitter today, hoping this puts a crimp in SWRX’s momentum and provides them with an opportunity to gain share. There will inevitably be some integration hiccups, which may slow the move to a new services platform (integrating the heritage SecureWorks and the acquired VeriSign technologies), but Dell would be stupid to mess with it much at all. They’ve got nothing to speak of in security now, and the obvious strategy is to use SecureWorks as the linchpin of a security practice. SecureWorks will see more deals if they can leverage Dell’s global channels, and having Dell behind them can’t hurt in enterprise deals, but candidly it didn’t seem like SWRX was losing deals because they weren’t IBM or Verizon – so it’s not clear how important a change this is. Although Dell may get some benefit from being able to package security into some of their bigger IT operations product and services deals. Dell? Really? Yet I’m still perplexed that Dell was the buyer. They do very little with security. They do even less with security services. Although I guess you could see Dell’s partnership with SecureWorks, announced back in July, as a harbinger of things to come. The joint offering hasn’t even hit the market yet. You still have to wonder why they’d buy the cow, when they don’t even know what the milk tastes like. It’s not like the $120 million in revenue SecureWorks brings is going to move Dell’s needle. Even if they triple it over the next 2 years, that would still be about 1% of Dell’s business. Unless SWRX was in play and Dell needed to pull the trigger. Buying SecureWorks certainly won’t hurt Dell, but it’s not clear how it helps much, either. I guess every big IT shop needs some real estate in security, as they try to become a solutions provider, but the fit seems off. You can clearly see how SWRX would fit better with an HP or a Cisco or even a MFE/Intel. But Dell? It seems like the obvious motivation is envy of its bigger