Research

Nothing makes my day like getting to argue with my colleagues here at Securosis. Sadly today isn’t that day. The only thing that I love almost as much is when Mike and Rich think they are arguing with each other, but I get to point out that they are actually saying the same things, but from different angles, and therefore with different words. The fact is that both of them highlight a very important point: for security groups to be effective, they need to be much more engaged with the business. Security is in fact always reactive in the sense that they cannot do anything more than influence, until the business makes decisions about how things will be done. But there is ‘reactive’ in the sense that the business makes a choice and security deals with, it and then there’s ‘reactive’ in the sense of security teams which are completely disengaged from the business – they only know about stuff when the new app doesn’t work because the firewall rules are wrong or they get a request for a Qualys scan a couple hours before a new server must be live. But back to being engaged with the business. That doesn’t mean sitting in the C suite (though that can be nice) – it means finding out who the people & projects are in your organization which will impact your duties as a security practitioner, getting to know them, and convincing those folks to keep you in the loop. Demonstrate that you are adding value by being involved earlier – perhaps by identifying potential roadblocks and workarounds early so they can be funded, designed around, etc. Or perhaps by staying abreast of forthcoming changes to legislation/regulations and working with legal/audit to make sure your organization is ready before the changes go into effect. These are just a couple examples of ways to show that security can absolutely be proactive rather than merely reactive, and it also proves that I lied above. Today is totally that day: O frabjous day! Callooh! Callay! I get to argue with both Rich and Mike. WIN! Share:

Few things make me happier than getting to publicly disagree with one of my coworkers. Earlier today Mike suggested that security is too reactive and tactical to succeed. Then we hear the usual platitudes about treating security as a risk management function, better metrics, blah blah blah. Not that there is anything wrong with all that, but it needs to be discussed in context of the fundamental nature of security. Which is an ongoing state of disruptive innovation. Security is reactive by nature – the moment it isn’t is the moment you really lose. The question is how to best provide yourself with the most time to plan your reactions, and what kind of infrastructure you can put in place to reduce the cost and complexity of any course corrections. Business innovation tends to result from three primary drivers: Competitive response. A competitor does something; you need to respond to stay in the game. Competitive advantage. You do something to gain an edge, and force others to respond. Efficiency/effectiveness. You streamline and improve your processes to reduce overhead. But security only shares one of those drivers. Security innovation is dominated by externalities: Business innovation. The business does something new, so you need to respond. Attacker innovation. Internal efficiency/effectiveness. “Doing security better”. Two of the three forces on a business are internal, with only competitive response driven by an outside actor. Security flips that. We can’t ever fully predict what the business or attackers will do down the road, so we need to scramble to react. That’s why we can never seem to skate ahead of the puck. You can’t skate ahead of a quantum field state that will eventually collapse into a single wave function – there are too many options to choose one. The trick, as Chris Hoff and I have been talking about at RSA for about 6 years now, is to take a strategic approach to prediction. This is why even a risk-based security approach is, in reality, just another tactical piece. The strategic piece is building a methodology to inform your working assumptions for what the future holds, and building your program to respond quickly once a direction is set. It isn’t magic, and some of you do this intuitively. You stay up to date on the latest research, both in and out of security. You track both new attack and general technology trends. You engage heavily with the business to understand their strategic direction before they make the tactical technology choices you later have to secure. A lot of this looks almost identical to Mike’s recommendations, but the reason organization after another fails in their risk-based, metrics-driven, incident response programs is they to and run them in a bubble, and assume situations are static on at least an annual basis. If you build your program assuming everything will change underneath you, you will be in much better shape. And I absolutely believe this is a realistic and pragmatic goal that others have achieved. Share:

FierceCIO’s Derek Slater offers an interesting perspective on why W. Edwards Deming hates your approach to IT security. I was educated as an industrial engineer, so we had to study Deming left, right, and center in school. Of course when I graduated and went into programming, nobody realized that Deming’s concepts also apply to software development. But that’s another story for another Six Sigma. Derek’s point is that as long as security is treated as a tactical, reactive, part of the organization… it’s doomed to fail. The most common approach is that IT security is regarded as a tactical discipline. The IT security director is part of the IT department, reports to the CIO (or lower), and manages his or her work based on a set of tactical metrics–many of which are merely forms of counting: We blocked this number of web-based attacks and this other number of malware attachments. This approach is purely reactive and therefore doomed to fail. The late business management guru W. Edwards Deming said this about reactive management–that it’s not rational: “Rational behavior requires theory. Reactive behavior requires only reflex action.” He also said this about counting: “It is easy to count. Counts relieve management of the necessity to contrive a measure with meaning.” Yup. The answer is to become more strategic in the eyes of the folks who matter. You could certainly become Pragmatic as a means to do that. But Derek offers a few pointers on that front as well. First is to treat security as a risk management function. As long as you can gain consensus on how to quantify security risk, that’s a good start. Second, you had better React Faster, because you are only as good as your last response. We agree. Finally, security needs better measurement. No kidding. There, friends, is the biggest gap in security: becoming strategic to the business. It’s measuring what we do relative to the business metrics that make an impact on the value of your company. Unfortunately there is no simple answer to the question of what matters to your business. Photo credit: “W. Edwards Deming–statistician…saint” originally uploaded by Peter Kazanjy Share:

It’s nice that my kids are still at a stage where they don’t want to disappoint me or the Boss. They need our approval and can be crushed if we show even the slightest measure of dissatisfaction in what they do. My ego-centric self likes that, but the rest of me wants them to learn to stop worrying about what everyone thinks and do what they think is right. Of course, that involves having enough life experience to understand the difference between right and wrong. I know that a 12 (soon to be 13) year old is not there yet. She still has much to learn. I’m happy to share my experiences so she can learn from them. I told the stories about when I was bullied. About how I learned that hard work creates results (with a bunch of luck). I have tried to impress upon her how important it is to surround yourself with people who appreciate the uniqueness we all possess in different ways. And for all I do, the Boss does 10x. All to give the kids a chance to be productive citizens and good people. If I could teach her even a portion of my experiences over the past (almost) 45 years, she wouldn’t need to go through my angst, suffer my disappointment, or learn the lessons I’ve learned… the hard way. But I can’t. Because kids don’t listen. Maybe they listen or pretend to, but they certainly don’t understand. How could they understand? Some things you just have to learn for yourself. But hopefully there aren’t tens of millions of people watching as those hard lessons are learned. And hopefully the lesson isn’t documented in video and photos, and doesn’t go viral via more Tweets per second than the Super Bowl. Yes, I am talking about the fiasco that Miley Cyrus has become. To be honest, I haven’t watched the performance on the MTV VMAs. I can’t bring myself to do it. I’ve seen that movie before. Child star gets too famous too fast, makes too much money, surrounds themselves with too many vultures and predators, gets very very lost, and becomes tabloid fodder. I’ve got November 10 in the Miley rehab pool. And where are her parents to tell her she’s being an idiot? I mean, what do you think Billy Ray was thinking as he watched her performance? Actually, I don’t care what he was thinking. What would you be thinking if that was your child? It brings front and center Chris Rock’s famous line: “If you can keep your son off the pipe and your daughter off the pole, you’re ahead of the game.” But you still can’t teach kids everything. Sometimes they have to learn hard lessons themselves. And it’s gonna hurt. Your job is to pick them up. Dust them off. Then help them get back on the horse. But most of all, they need to know that you love them. During the good times and bad. Especially during the bad times… –Mike Photo credit: “Bad Teacher” originally uploaded by Sonya Cheney Heavy Research We are 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. Ecosystem Threat Intelligence Use Cases and Selection Criteria Assessing Ecosystem Risk The Risk of the Extended Enterprise Continuous Security Monitoring Migrating to CSM The Compliance Use Case The Change Control Use Case The Attack Use Case Classification Defining CSM Why. Continuous. Security. Monitoring? Database Denial of Service Countermeasures Attacks Introduction API Gateways Implementation Key Management Developer Tools Newly Published Papers The 2014 Endpoint Security Buyer’s Guide The CISO’s Guide to Advanced Attackers Defending Cloud Data with Infrastructure Encryption Network-based Malware Detection 2.0: Assessing Scale, Accuracy, and Deployment Quick Wins with Website Protection Services Incite 4 U I get AV’s cufflinks: Great thought-provoking post by Wendy Nather about the marketing-driven evolution of anti-malware technology. Succinctly stated: “what comes after advanced?” Her points are well-stated: no AV vendor merely uses signatures, and it’s all about detection – not necessarily prevention – now. I guess this React Faster stuff might have some legs. Though the best line in the post is “Nobody wants to say antivirus is dead, but let’s just say they’re planning ahead for the wake and eyeing the stereo.” That kind of prevention is obsolete, but as evidenced by the IBM/Trusteer deal, clearly there is a great future (at least from a valuation standpoint) for companies with new-age prevention technology. But what happens when that advanced stuff isn’t differentiated anymore? I guess the marketeers will need to come up with a new term to describe the next shiny object. – MR Tick tock: Dealing with a breach is never a lot of fun. First you need to detect it in the first place, then you need to figure out whether it’s real, what exactly is going on, what was affected, and how. All while containing the incident, keeping as many important things running as possible, and figuring out a recovery strategy. For anything resulting in lost data, it is an unenviable process to work through. Then, if regulated data is lost, there is the eventual breach notification, which senior executives love. Okay, now imagine that you have 24 hours to notify authorities of any breach and get all the details to them within 72 hours. Because if you operate in the EU, that is your new time limit. I’m all for breach notification laws, but that one might be a tad unrealistic. Keep in mind that we still need to see how it is going to be enforced, but you had better get your lawyers cracking on it now. You know, just in case. – RM Growth business: The latest Nilson Report on global card fraud rates is out, and fraud now accounts for 5.22% of all card transactions. In fact, even with card usage up 11.4% YoY, fraud is up 14.6% over the same period. And when you’re

I do not think Mike’s and Rich’s points are at odds at all. Mike’s post lays out what in my view is infosec’s Achilles heel: lack of strategic alignment with the business. There are very few things that basically everyone in infosec agrees on; but a near universal one is that you can, should, and will never show a Return on Security Investment. “The business” is just supposed to accept this, apparently, and keep increasing the budget year after year; the People’s Republic of Information Security shall remain unsullied by such things as profit and loss, and breeze merrily along. Of course in the very next breath, after waving away the petty request for return on investment, infosec teams routinely complain that “the business” doesn’t get security. I humbly suggest that while that may be true, security doesn’t actually get “the business” either. Rich’s approach to this issue is quite pragmatic: close collaboration. Business is already driven by externalities – infosec is not unique in this regard, although security does have different drivers (although they get more closely aligned every day). I like Rich’s approach, but I would take it one step farther. Andy Jaquith tweeted the other day on OWASP that ‘ITsec guys need to “embed” into existing OSS projects not make new ones’ – this applies to security teams in spades. Embed security in the business. We are so used to trotting out things like breach statistics, but what is “the business” supposed to get from these meaningless out-of-context numbers? They look at the world in terms of transaction volume, throughput, customer retention, cash flows, ARPU, and other business relevant metrics. Every industry has its own key metrics – does your security team know yours? When General David Petraeus took over US forces in Iraq, one of the first things he changed was how to measure success. The previous command used classic military metrics – how many American soldiers got killed and how many enemy combatants did we kill. Petraeus changed the measurement and thus the mindset. He used metrics like how many little old ladies can get safely to the market in Baghdad to buy oranges. This is a totally different way of looking at measuring success and failure. There are precedents for this kind of mind shift in certain industry segments. Banks have sophisticated fraud detection teams and schemes. They are able to map events and compare fraud rates against total transactions and customer interactions. It is a simple way to communicate fraud control program effectiveness with “the business”, once you stop looking at security as something separate and see it as part of the whole. The practical point here is to very clearly understand your business’ competitive advantage. There is no generic answer for this – business imperatives and competitive differentiators vary from one business to the next. That is a major reason there is no magic set of security metrics that broadly addresses the whole industry. You need to know what your moat is, and to organize metrics and processes around moats. If you are Walmart you care about anything that drives up cost because a big part of your moat is being the low-cost provider. If you are an ecommerce company then availability is a big moat. You can bet that Amazon can tell you very precisely what 5 minutes of downtime or an extra second to load a page costs in real dollars. All communication with “the business” should be within this context – then we can map our own internal infosec issues such as attacker innovation and operational efficiency onto a framework that is much more trackable for productive collaboration with “the business.” One more thing: there is no security. There is just “the business” – with everyone sharing the same mission and working together as best we can. Share: