Research

“Hi. I’m Mike. And I’m an addict.” I start every chapter of the Pragmatic CSO with those very words. There there are many things you can be addicted to. Thrills. Sex. Sugar. Booze. Drugs. Twitter. Pr0n. Caffeine. Food. Some are worse than others, though none of them really good for you. But now I have to face up to another addiction. The need for gadgets. I’m jonesing for a new MacBook Air. Big time. Like waking up in the middle of the night wanting some SSD goodness in a petite 2lb package. Jonesing, I say, and it’s not pretty. Now there are folks with much worse gadget addiction than me. They are the ones standing in line at Best Buy for the latest Zune. Those folks have a problem. To be clear, so do I. I have a perfectly workable 15” MacBook Pro. It’s been a workhorse for two and a half years. For what I need, it’s fine. Why can’t I be happy with it? Why do I long for something new? The problem is my gear isn’t shiny anymore. I need a new trophy. Need. It. Now. I feel inadequate with a late 2008 MBP. In the bagel shop where I was writing this morning, there was a guy with an MB Air. I felt envy. Not enough to poach his machine when he tok a leak (by the way, it’s two frickin’ pounds – you can take it to the loo), but definitely envy. But then I looked over my other shoulder and saw a guy with an old school Apple laptop. And I mean old school. Like before they had a MagSafe connector, meaning a PowerBook G4. Oh, the horrors. I don’t know how that guy gets out of bed in the morning. And it’s worse when we have a Securosis meeting. Rich gets all the new toys. He’s got an MB Air 11”. I know he scoffs at my MBP. My laptop is older than his kids. Really. But Adrian is a different animal. He’s into high end audio equipment and dogs. My addiction is cheaper. At least I have that going for me. Over two years with the same laptop is a lifetime for me. Some guys trade in their wives every couple years. I trade in my laptop. The Boss likes that approach much better. Normally it’s not an issue, since I tend to hold down a job for 15 months, so I get a new toy every time I get a new job. I get my fix and have no issue, right? Not so much anymore – I’m not changing jobs any time soon. At least that’s what Rich and Adrian keep telling me. But I am getting smarter. Knowing this little issue I have, I made proper provisions this year by doing a side project over the winter and expressly earmarking those fees to breathe the (MB) Air. I’ve got motive. I’ve got opportunity. I’ve even got the funds. I know, you are wondering why I don’t just hop on the Apple web site and order it? This is why. They expect a new Air in the summer. That’s only what, 2 months away? It’ll be worth the wait. That’s what I keep telling myself. It will be smokin’ fast. And shinier. The next 2 months will be a struggle. I want it now. But I’m repressing my urges because I know how bad I’d feel when someone else got the shiny fast one, 4 days after I took delivery of my slow, dull one. I need to do some NLP to associate those bad feelings with the late 2010 MB Air. I will awaken the giant within, just you watch. That will keep me off the gadget juice. I’ll hold out because I have a plan. Every day, I’ll do my affirmations to convince myself that I’m still a good person, even though I use a late 2008 MBP. It will work. I know it will. The power of positive thinking in action. I’ll send a DM to my sponsor every day because I’m not addicted to Twitter. Not yet anyway. That will keep me on the straight and narrow. And doggone it, people like me, right? But we all know what happens when you repress an urge for too long. Gosh, that iPad 2 looks awfully shiny… -Mike Photo credits: “Apple addiction” originally uploaded by new-york-city Since I don’t do enough writing here on the Securosis blog, I figured I’d inflict some pithy verbiage on the victims, I mean readers, of Dark Reading. I’ll be posting on their Hacked Off blog monthly, and started with a doozy on why the RSA breach disclosure was pretty good. Surprisingly enough, I took a contrarian view to all those folks who think they should know everything, even if they aren’t RSA customers. It’s not about you, folks – sorry to bruise your egos. Incite 4 U Mea culpa roll with a side of SQLi: Do you ever wonder what a Barracuda roll tastes like? You can ask the folks in Hong Kong who used an automated SQLi attack to feast on Barracuda’s customer list over the weekend. The good news is that not much data was lost. Some customer and partner names and emails. The bad news is the breach happened because of an operational FAIL to put WAF back into blocking mode. As usual, people are the weakest link. But this disclosure is a great example of how to own it, explain it, and help everyone learn from it. A side of SQLi is not quite as tasty as miso soup, but news of the attack goes down a lot easier with a large serving of mea culpa. – MR Trust No One: I keep stealing a slide Gunnar did a while back (from Chris Hoff, who showed it to me first). It’s a table showing all the big advances in the web and web applications, and then the security tools we use to secure them. In every case, it’s firewalls and SSL. But between the Comodo breach and the

So your key security metrics are collected and shared safely. What comes next? Now we need to start deriving value from the data. Remember, metrics and numbers aren’t worth the storage to keep them, unless you use them as management tools. You need to start comparing the data, drawing conclusions, and adjusting your security program based on the data. OMG, actually making changes based on data rather than shiny objects, breaches, airline magazine articles, and compliance mandate changes. How novel. Remember the goal of this entire endeavor: to show relative progress. Now we get to figure out relative means, which involves defining peer group(s) for comparison. The first group you’ll compare your data to is actually yourself. Yes, this is trend analysis on your own metrics. It will provide some perspectives on whether you are improving – but improving against yourself does not provide perspective on whether you are ‘good’, spending too much money, or focusing on the right stuff. This is where you need to think about benchmarking, or going beyond security metrics. Peer Groups There are ways to define your peer group: Industry: This is your vertical market. Initially (until you have access to loads of data), you will focus on big industry buckets – like defense, healthcare, financial, hospitality, etc. Obviously there are differences between investment banks and insurance companies within the financial vertical, but businesses in the same category will have many consistent business processes which involve collecting very similar types of data. These organizations also tend to have similar geographic profiles – as for example a typical retailer will have a headquarters, regional distribution centers, and tons of stores. Additionally these companies exist under similar compliance/regulatory regimes. They also tend to be relatively consistent in terms of to technology adoption/maturity, which is critical for making relevant comparisons. Company size: Similar to the consistencies we find among companies in the same vertical/industry, we also find many similarities between companies of roughly the same size. For instance large enterprises (10,000+ employees) are generally global by definition – it is very difficult to get that big while focusing on a single geographic region. So organizational models and scale tend to be fairly consistent within a company-size segment. These companies also tend to spend similarly on security. Of course there are always outliers and some industries show less consistency, but we aren’t looking for perfection here. Region: Regional comparisons support many interesting comparisons. Culture and attitudes toward security can be enhanced or hindered by government funding and compliance regimes. We also see relatively consistent technology maturity/adoption within regions – largely based on local drivers such as compliance with laws and other rules, infrastructure, and available talent. Of course, not all metrics apply to any peer group. So when you define your benchmark peer groups, factor this in. The best way is to figure out how the specific metrics correlate for each peer group. We know, it’s math, but you’ll figure out pretty quickly whether there are any useful patterns or consistency within any particular metric. Focus on the metrics with the best correlation across a peer group. Sample Size Now that we’re talking about math, we have to address sample size. That’s basically how much data you need before the benchmark is useful. And as usual it depends, but push for statistical significance over the long term. Why? Because by definition statistical significance means a result is unlikely to occur by chance. You don’t want to be making decisions based on chance and randomness, so that’s our benchmark. More to the point, you want to stop making decisions based on chance. But it’s likely to take some time to get to a statistically significant dataset, so what can you do in the meantime? Look at the distribution, remove the outliers (which screw up your trend lines), and start comparing yourself against the trends you can spot. You can get a decent trend with only a handful of data points for metrics that correlate strongly. Always remember to keep the goal clearly in focus, and that is to identify gaps and highlight success, neither of which requires a huge amount of data. But to be clear, you are looking over time for statistical significance. Reverting to the Mean Another issue is whether you want to “revert to the mean,” meaning you look like everyone else in the peer group. Once again, it depends. Let’s take a look at a couple of likely metrics categories: For spending, it’s unlikely that you are getting a reasonable return from security spending 3 standard deviations above the mean. Not unless you can differentiate your product/offering on security, which is rare. For incidents, you want to be better than the mean. Most likely significantly so. Why? Because all your years of hard work can be unwound with one high profile breach. So the more effectively and quickly you respond and contain the damage, the better. Here you definitely don’t want to be in the bottom quartile, which indicates a failure of incident response and should be unacceptable to senior management. For efficiency, effectiveness, and coverage metrics (most of the easily quantifiable and operational metrics), you want to be better than the mean. That shows operational competence. In terms of importance, your spending is usually the most visible (to the folks who pay the bills, at least), so be in the ballpark there. Incidents come next, as they have a direct impact on issues like availability and brand damage. Then comes the operational stuff – it’s certainly important to how you run the security program, but rarely interesting to the muckety-mucks. Now it’s time to tell those muckety-mucks what you found, which means focusing on the commmunication strategy underlying your benchmarking program, so that’s where we’ll focus in the next post. Share:

Some projects take us a few days. Others? More like 18 months. Back before Mike even joined us, Adrian and I started a ‘quick’ project to develop a basic set of metrics for database security programs. As with most of our Project Quant efforts, we quickly realized there wasn’t even a starting framework out there, never mind any metrics. We needed to create a process for every database security task before we could define where people spent their time and money. Over the next year and a half we posted, reposted, designed, redesigned, and finally produced a framework we are pretty darn proud of. To our knowledge this is the most comprehensive database security program framework out there. From developing policies, to patch management, to security assessments, to activity monitoring, we cover all the major database security activities. We have structured this with a modular set of processes and subprocesses, with metrics to measure key costs at each step. The combination of process framework and metrics should give you some good ideas for structuring, improving, and optimizing your own program. Here’s the permanent home for the report, where you can post feedback and which will include update notices: Measuring and Optimizing Database Security Operations (DBQuant). We broke this into an Executive Summary that focuses on the process, and the full report with everything: Executive Summary. (PDF) The Full Report. (PDF) Special thanks to Application Security Inc. for sponsoring the report, and sticking with us as we pretended to be PhD candidates and dragged this puppy out. Share:

This is a non-security post, in case that matters to you. A few days ago I was reading about a failed Telcomm firm ‘refocusing’ its business and technology to become a cloud database provider. I’m thinking that’s the last frackin’ thing we need. Some opportunistic serial start-up-tard can’t wait to fail the first time, and wants skip over onto not one but two, hot trends. Smells like 1999. Of course they landed an additional $4M; couple Cloud with a modular database and it’s a no-lose situation – at least for landing venture funding. So why do we need vendor #22 jumping onto the database in the cloud bandwagon? I visited the xeround site, and after looking at their cloud database architecture … damn, it appears solid. Think of a more modular MySQL. Or better yet, Amazon Dynamo with less myopic focus on search and content delivery. Modular back-end storage options, multiple access nodes disassociated from the query engines, and multiple API handlers. The ability to mix and match components to form a database engine depending upon the task at hand makes more sense than the “everything all the time” model we have with relational vendors. I don’t see anything novel here, just a solid assemblage of features. To fully take advantage of the elastic, multi-zone, multi-tenant pay-as-you go cloud service, a modular, dynamic database is more appropriate. Notice that I did not say ‘requirement’ – you can run Oracle as an AMI on Amazon too, but that’s neither modular nor nimble in my view. The main point I want to make is that the next generation of databases is going to look more like this and less like Oracle and IBM DB2. The core architecture described embodies a “use just what you need” approach, and allows you tailor the database to fit the application service model. And don’t mistake me for yet another analyst claiming that relational database platforms are dead. I have taken criticism in the past because people felt I was indicating relational platforms had run their course, but that’s not the case. It’s more like the way RISC concepts appeared in CISC processors to make them better, but did not supersede the original as promised. NoSQL concepts are pushing the definition of what ‘database’ means. And we see all these variants because the relational platforms are not a good fit for either the application model or cloud service delivery models. Expect many of the good NoSQL ideas to show up in relational platforms as the next evolutionary step. For now, the upstarts are pointing the way. Note that this is not an endorsement of the xeround technology. Frankly I am too busy to load up an AMI and try their database to see if it works as advertised. And their feature comparison is kinda BS. But conceptually I think this model is on track. That’s why will see many new database solutions on the market, as many firms struggle to find the right mix of features and platform options to meet requirements of application developers and cloud computing customers. Share:

One thing I don’t miss from my vendor days in the Database Activity Monitoring market is the competitive infighting. Sure, I loved to do the competitive analyses to see how each vendor viewed itself, and how they were all trying to differentiate their products. I did not enjoy going into a customer shop after a competitor “poisoned the well” with misleading statements, evangelical pitches touting the right way to tackle a problem, or flat-out lies. Being second into a customer account meant having to deal with the dozen land mines left in their minds, and explaining those issues just to get even. The common land mines were about performance, lack of impact on IT systems, and platform support. The next vendor in line countered with architectures that did not scale, difficulties in deployment, inability to collect important events, and management complexity of every other product on the market. The customer often cannot determine who’s lying until after they purchase something and see if it does what the vendor claimed, so this game continues until the market reaches a certain level of maturity. With Database Activity Monitoring, the appliance vs. software debate is still raging. It’s not front and center in most product marketing materials. It’s not core to solving most security challenges. It is positioned as an advantage behind the scenes, especially during bake-offs between vendors, to undermine competitors. Criticism not based on the way events are processed, UI, or event storage – but simply on the deployment model. Hardware is better than software. Software is better than hardware. This virtual hardware appliance is just as good as software. And so on. This is an area where I can help customers understand the tradeoffs of the different models. Today I am kicking off a short series to discuss tradeoffs between appliance, software, and virtual appliance implementations of Database Activity Monitoring systems. I’ll research the current state of the DAM market and highlight the areas you need to focus on to determine which is right for you. I’ll also share some personal experiences that illustrate the difference between the theoretical and the practical. The series will be broken into four parts: Hardware: Discussion of hardware appliances dedicated to Database Activity Monitoring. I’ll cover the system architecture, common deployment models, and setup. Then we’ll delve into the major benefits and constraints of appliances including performance, scalability, architecture, and disaster recovery. Software: Contrasting DAM appliances with software architecture and deployment models; then cover pros and cons including installation and configuration, flexibility, scalability and performance, and installation/setup Virtual Appliances: Virtualization and cloud models demand adaptation for many security technologies, and DAM is no different. Here I will discuss why virtual appliances are necessary – contrasting against with hardware-based appliances – and consider practical considerations that crop up. Data Collection and Management: A brief discussion of how data collection and management affect DAM. I will focus on areas that come up in competitive situations and tend to confuse buying decisions. I have been an active participant in these discussions over the last decade, and I worked for a DAM software provider. As a result I need to acknowledge, up front, my historical bias in favor of software. I have publicly stated my preference for software in the past based upon my experiences as a CIO and author of DAM technology. As an analyst, however, I have come to recognize that there is no single ‘best’ technology. My own experiences sometimes differ from customer reality, and I undersetand that every customer has its own preferred way of doing things. But make no mistake – the deployment model matters! With that said, there is no single ‘best’ model. Hardware, software, and virtual appliance – each has advantages and disadvantages. What works for each customer depends on its specific needs. And just like vendors, customer will have their own biases. What’s important is what is ‘better’ for the consumer. I will provide a list of pros and cons, to help you decide what will work best. I will point out my own preferences (bias), and as always you are welcome to call ‘BS’ on anything in this series you don’t accept. Perhaps more than any other series I have ever written at Securosis, I want to encourage feedback from the security and IT practitioner community. Why? Because I have witnessed too many software solutions that don’t scale as advertised. I am aware of several hardware deployments that cost the customer almost 4X the original bid. I am aware of software – my own firm was guilty – so inflexible we were booted from the customer site. I know these issues still occur, so my goal is to help wade through the competitive puffery. I encourage you to share what have you seen, what you prefer, and why, as it helps the community. Share:

You really should read Lee Kushner and Mike Murray’s Information Security Leaders blog. Besides being good guys, they usually post good perspectives on career management each week. Like this post on Rats and Ships, where they basically address how to know your company is in trouble and when to start looking for what’s next. Obviously if the company is in turmoil and you don’t have your head in the sand, the writing will be on the wall. I learned in the school of hard knocks that you always have to be looking for what’s next. I know that sounds very cynical. I know it represents a lack of loyalty to whoever you are working for now. You see, things can change in an instant. Your company can lose a big deal. You could be the fall guy (or gal) for a significant breach (remember blame != responsibility). Or you could have a difference of opinion with your boss. There are an infinite number of scenarios that result in the same thing: You, out on your ass, with no job. Usually you expect it, but not always. The absolute worst day of my career was having to lay off a good friend, who had absolutely no idea it was coming. Because I couldn’t give him a head’s up that we were trying to sell the company, he was blindsided. When we closed the deal, almost everyone had to go. Some situations you can see coming, some you can’t. But either way you need to be prepared. If you are in security, you are trained to think defensively. You look at a situation and need to figure out how you can get pwned, screwed, or killed. It’s no different managing your career. Always be aware of how you can get screwed. Hopefully you won’t and you’ll have a long, prosperous career wherever you are, if that’s what you choose. But that doesn’t get you off the hook for being prepared. You should always be out there networking, meeting people, and getting involved in your community and paying it forward. Read Harvey Mackay’s book “Dig Your Well Before You’re Thirsty.” It’s the best book I’ve read about why you need to do something you likely despise – networking. And let’s not forget that opportunity cuts both ways. You need to be ready to pull the rip cord when things come unglued, but sticking around can be worthwhile too. For one, less people around means more opportunity for you, especially if you are pretty junior. You may end up with far more responsibility than your title, salary, and/or experience would otherwise warrant. And if you can see it through to the recovery (to the degree there is a recovery), you are positioned to be an up and comer in your organization. I guess the bigger message is to be aware of what’s going on, and to actively manage your career progression. Don’t let your career manage you. To the degree you want to do that. If you are really a glutton for punishment, start your own company. Then you can stop looking. Because you’ll know where to find all the problems. Photo credit: “Virtual Defensive Driving” originally uploaded by Kristin Brenemen Share:

I was almost Phished this week. Not by some Nigerian scammer, or Russian botnet, but by my own bank. Bundled with both my checking and mortgage statements – with the bank’s name, logos, and phone number was the warning: “Notice: Credit Report Review Re: Suspicious activity detection”. The letter made it appear that there were ongoing suspicious activity reported by the credit agency, and I needed to take immediate action. I thought “Crud, now I have to deal with this.” Enclosed was a signature sheet that looked like they wanted permission to investigate and take action. But wait a minute – when does my bank ask for permission? My suspicion awoke. I looked at the second page of the letter, under an electron microscope to read the 10^-6 point fine print, and it turned out suspicious activity was only implied. They were using fear of not acting to scare me into signing the sheet. The letter was a ruse to get me to buy credit monitoring ‘Services’ from some dubious partner firm that has been repeatedly fined millions by various state agencies for deceptive business practices. Now my bank – First Usury Depository – is known for new ‘products’ that are actually financial IED’s. Of the 30 fantastic new FUD offerings mailed in the last three years, not one could have saved me money. All would have resulted in higher fees, and all contained traps to hike interest rates or incur hidden charges. But the traps are hidden in the financial terms – they had not stooped to fear before, instead using the lure of financial independence and assurances that I was being very smart. Alan Shimmel’s right that we need to be doubly vigilant for phishing scams, just for the wrong reasons. Both phishers and bank executives are looking to make a quick buck by fooling people. They both use social engineering tactics: official-looking scary communications, to trigger fear, to prompt rushed and careless action. And they both face very low probabilities of jail time. I can’t remember who tweeted “Legitimate breach notification is indistinguishable from phishing”, but it’s true on a number of levels. Phished or FUDded, you’re !@#$ed either way. I have to give First Usury some credit – their attack is harder to detect. I am trained to look at email headers and HTML content, but not so adept at deciphering credit reports and calculating loan-to-value ratios. If I am phished out of my credit card number, I am only liable for the first $50 If I am FUDded into a new service by my bank, it’s $20 every month. Hey, it has worked for AOL for decades… On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Mike quoted on metrics in Dark Reading. Adrian’s DAM and Intrusion Defense lesson Rich on Threatpost talking about RSA and Epsilon breaches. Adrian’s Securing Databases In The Cloud: Part 4 at Dark Reading. Favorite Securosis Posts Rich: Less Innovation Please. We don’t need more crap. We need more crap that works. That we use properly. Mike Rothman: Less Innovation Please. Adrian kills it with this post. Exactly right. “We need to use what we have.” Bravo. Adrian Lane: FireStarter: Now What? Other Securosis Posts Always Be Looking. Incite 4/6/2011: Do Work. Fool us once… EMC/RSA Buys NetWitness. Security Benchmarking, Going Beyond Metrics: Collecting Data Systematically. Security Benchmarking, Going Beyond Metrics: Sharing Data Safely. Quick Wins with DLP Light: Technologies and Architectures. Quick Wins with DLP Light: The Process. Favorite Outside Posts Rich: IEEE’s cloud portability project: A fool’s errand? Seriously, do you really think interoperability is in a cloud provider’s best interest? They’ll all push this off as long as possible. What will really happen is smaller cloud vendors will adopt API and functional compatibility with the big boys, hoping you will move to them. Mike Rothman: Jeremiah Grossman Reveals His Process for Security Research. Good interview with the big White Hat. Also other links to interviews with Joanna Rutkowska, HD Moore, Charlie Miller, and some loudmouth named Rothman. Pepper: Creepy really is. You can build a remarkable activity picture / geotrack / slime trail from public photo geolocation tags. Adrian Lane: Incomplete Thought: Cloudbursting Your Bubble – I call Bullshit…. Project Quant Posts DB Quant: Index. NSO Quant: Index of Posts. NSO Quant: Health Metrics–Device Health. NSO Quant: Manage Metrics–Monitor Issues/Tune IDS/IPS. NSO Quant: Manage Metrics–Deploy and Audit/Validate. NSO Quant: Manage Metrics–Process Change Request and Test/Approve. NSO Quant: Manage Metrics–Signature Management. Research Reports and Presentations Network Security in the Age of Any Computing. The Securosis 2010 Data Security Survey. Monitoring up the Stack: Adding Value to SIEM. Network Security Operations Quant Metrics Model. Network Security Operations Quant Report. Understanding and Selecting a DLP Solution. White Paper: Understanding and Selecting an Enterprise Firewall. Understanding and Selecting a Tokenization Solution. Top News and Posts Conde Nast $8M Spear Phishing Scam was mostly buried in the news, but a big deal! Something about email addresses being hacked. You make have heard about it from 50 or so of your closest vendors. Albert Gonzales surprise appeal. IBM to battle Amazon in the public cloud. Cyberwars Should Not Be Defined in Military Terms, Experts Warn. Net giants challenge French data law. EMC Acquires NetWitness Corporation Blog Comment of the Week Remember, for every comment selected, Securosis makes a $25 donation to Hackers for Charity. This week’s best comment goes to Lubinski, in response to Incite: Do Work. “They seem to forget we are all supposed to be on the same team” I work with a few people like this. It makes me wonder if they don’t really think about it and just go on doing what they have been doing for X number of years and consider that good enough. The RSA can get pwnd as easily as the rest of the world, its not like they have users that carry around magical anti-hacker unicorn’s. I see a new buzzword coming on, StuxAPT. 🙂 No? Share:

We spent last weekend up north visiting friends and family while the kids are on Spring Break. We decided to surprise them on Sunday by going to a baseball game. It was opening weekend and our home team was in town. We got cheap seats in the upper deck, but throughout the game we kept moving downwards, and by the 9th inning we were literally in the front row on the dugout. The Boss turned to me and asked if the kids had any idea how lucky they are. Yeah, right. And that’s a huge problem for me. Given a lot of luck and a little talent, I make a pretty good living, which means my kids can do things that weren’t possible for me growing up. But where do you draw the line? You want the kids to have great experiences, but you also want them to understand the work involved to provide those experiences. The best answer I have right now is to do work. I think I saw Chris Nickerson say that on Twitter one day and it resonated with me. It’s basically leading by example. I get up every morning and do work. Even though most of the time what I do all day doesn’t feel like work. The kids know that I work hard and I’m good about reminding them when they get a little uppity. One of the best parts of the weekend was seeing our twin nephews. They are 3 months old and a lot of fun. But each time I got my hands on one of them, I’d start working them out. You know, getting them to start supporting their weight – both sitting and standing. I also had them doing some tummy time, which brought back plenty of memories from when my kids were babies. Just like I remembered, newborns don’t like to do work. They like to eat and sleep and crap their pants. And when they would bark at me I’d just look them in the eye and say “stop bitching and do work!” Though maybe it is a bit early to push them out of their comfort zone. Although they do have to get into that fancy pre-school, after all… Yes, I know kids need to be kids too. They need to play and have fun because lord knows once they get out of school it’s not as much fun. But they can work at having fun. They can work on their ball skills, being a good friend, or even Angry Birds. If you want to be good, you need to work at it. That’s right. Do work! Working at home creates some challenges because every so often one of the kids will want to play during the work day. I politely (or sometimes not so politely) decline and remind them that Dad is doing work. Then I make sure they did work before letting them go do their own thing. You see, working hard is a habit and I know that sometimes I can be a bit relentless with them, but if they don’t learn a good work ethic now life will be pretty tough. So I’ll assume that reading my drivel is work for you, so you can feel good about spending 10 minutes with us each day. And no, I won’t reimburse you for those 10 minutes you’ll never get back. Now get back to work! That’s what I’m going to do. -Mike Photo credits: “Do work, son!” originally uploaded by Lee Huynh Incite 4 U Bully? I’m good with that: We haven’t spoken about Stuxnet recently, so let me point to an interesting post from VC David Cowan (the first money into VeriSign among others), who talks about how the guy that decomposed and published all the gory details of Stuxnet is misguided in calling the US a cyber-bully. You see, whether Ralph Langner wants to admit it or not, a nuclear-capable Iran isn’t in anyone’s best interests. Regardless of your politics, it’s hard to make a case otherwise. So presumably the US (and other partners) came up with a way to avoid bombing the crap out of somewhere while meeting their requirements. That’s innovation, folks. And innovation can’t be stopped. Remember the Manhattan Project? How long was it before the USSR had their own nuclear weapons? Once Pandora’s box is open, it’s open. And I’m glad the US got to open this one. – MR Advanced Persistent Service Providers: Ever hear of Epsilon? Not the Greek letter – the email marketing company. Me neither, until the breach notifications started rolling in. I bet the Secret Service never heard of them either. Evidently they are a pretty successful company, and that made them a target. As our emails and names start circulating the botnets, one interesting point is emerging. If you read one email sent to the DataBreaches.net folks you realize that the lost data included not only folks who opted out, but leftover data from prior corporate customers. That’s right, they kept everything. Forever. This provides a new perspective on the idea of persistence, eh? Perhaps it’s time to check your contracts with your service providers, so you aren’t exposed by their mistakes, after you switch to their competitor. – RM Consumerization FTW: ZDNet discussed an interesting use case for Pano Logic virtual client terminals at public libraries. I am a big fan of desktop virtualization, both for security because it’s easier to patch and implement policy centrally, and also because this makes your virtual session available regardless of your location or device. This is not an endorsement of any product – just of this type of technology in general. The use case makes sense, and particularly for schools which need controlled environments. At the same time I realize this will probably never catch on – for the same reason phone booths are gone – cell phones made them obsolete. The organizations with the most to gain from this service model are least likely to be able to afford it. In the long run schools and public libraries will likely require people to

The best definition of a security benchmarking effort I am aware of is in Chapter 11 of my book, The Pragmatic CSO, which provides a good perspective on why benchmarking is important. Since it is very hard to have objective, defendable measures of security effectiveness, impact, etc., a technique that can yield very interesting insight into the performance of your security program is to compare it to others. If you can get a sample set of standard questions, then you can get a feel for whether you are off the reservation on some activities and out ahead of others. Benchmarking has been in use in other IT disciplines for decades. Whether it was data center performance or network utilization, companies have always felt compelled to compare themselves to others. It’s part of the competitive, win at all costs mentality that pervades business. So one of the best ways to figure out how good your security is, and get a feel for various other operational aspects of your security program, is to figure out how you compare to someone else. The objective is not to come up with a “security number” or “risk score”, but to present information in the context of other companies that face the same kinds of attacks. This provides management with what they always want: a perspective on the level of risk they are willing to take. If you are behind a reasonable peer group, they can decide to invest more or to accept the risks of a less effective security program. If they are ahead, maybe they will opt to maintain or even accelerate investment in the unlikely event they can differentiate on security). Or, yes, they might decide to scale back on security ‘overhead’. Either way, it’s a win for you as the practitioner, because you know where you stand and the decision makers are actually making informed decisions with data. How novel! But before we can start thinking about comparing all the metrics we’ve decided are important and are now collecting systematically, we need some kind of infrastructure and mechanism to share this data, safely and securely. A few years ago I did a lot of research into building a security benchmark, and customers clearly agreed that any sharing mechanism would need to ensure: Anonymity: First and foremost, these customers wanted to make sure the data wasn’t attributed back to them. No way, no how. Of all the things I discussed with these customers, this was non-negotiable. There could be no way for another customer could identify source data or derive which company provided any of the data. Integrity: The next issue was making sure the data was meaningful. That means it must be objectively and consistently gathered. Obviously there would need to be some level of agreement on what to count and how to count it, and that would likely be the purview of a third party. Security: This goes hand in hand with anonymity, but it’s different in that potential customers need to understand how the data would be protected (at a granular level) before they’d be comfortable sharing. Given all that, is it any wonder that security benchmarking remains in its infancy? When talking to any potential community aggregator or commercial benchmark offering, be sure to dig very deeply into how the data is both secured and aggregated to calculate the benchmarks. You need to ensure proper data encryption and segregation to make sure your data doesn’t get mixed with others, and that even if it somehow does, it wouldn’t be accessible. Additionally, you’ll want to make sure any device uploading data (this must be systematic and automated, remember) is mutually authenticated and authorized so no one can game the benchmark. From an infrastructure protection standpoint, make sure all the proper controls are in place. Things like strong identity management, egress filtering, HIPS (if not whitelisting on the devices with access to the data), as well as significant monitoring on the network and database. Given some recent high-profile breaches, it’s not unreasonable to expect network full packet capture as well. Ultimately you need to be comfortable with how your data is protected, so ask as many questions as you need to. From an application standpoint it’s also reasonable to expect the code to be built using some kind of secure development methodology. So learn about the threat models the vendor (or community) used to design the protection, as well as to what degree automated and non-automated testing mechanisms were used to scrutinize the application at all points during the development process. Learn about audits and pen tests, and basically crawl into very dark places in the provider’s infrastructure to get comfortable. This is a tall order and adds substantially to the due diligence required to get comfortable participating in a security benchmark. We understand this will be too high a hurdle for some. But keep your eyes on the prize: making security decisions based only actual data, within the context of your peer group. As opposed to doing what your gut tells you, or politics, or prayer. Once you clear this intellectual hurdle it’s time to define your peer groups for comparison and how to analyze the data. That’s next. Share:

It happens every time we have a series of breaches. The ‘innovators’ get press coverage with some brand-new idea for how to stop hackers and catch malicious employees trying to steal data. We are seeing yet another cycle right now, which Rich discussed yesterday in FireStarter: Now What? The sheer idiocy of Wired Magazine’s Paranoia Meter made me laugh out loud. Not that monitoring should not be done, but the concept of monitoring users’ physical traits to identify bad behavior is a lot more effort and is also error-prone. Looking at posture, mouse movements, and keystrokes to judge state of mind, then using that to predict data theft? Who could believe in that? It baffles me. User behavior in the IT realm does not need to be measured in terms of eye movement, typing speed, or shifting in one’s seat – if it did, we would need to round up all the 3rd graders in the world because we’d have a serious problem. Worse, the demand is clearly a marketing attempt to capitalize on WikiLeaks and HBGary – the whole thing reminds me more than a little of South Park’s ‘It’. Behavior analysis of resource usage is quite feasible without spy cameras and shoving probes where they don’t belong. We can collect just about every action a user takes on the network, and if we choose from endpoint and applications as well – all of which is simpler, more reliable, and cheaper than adding physical sensors or interpreting their output. It’s completely feasible to analyze actual (electronic) user actions – rather than vague traits with unclear meaning – in order to identify behavioral patterns indicating known attacks and misuse. Today we mostly see attribute-based analysis (time, location, document type, etc.), but behavioral profiles can be derived to use as a template for identifying good or bad acts, and used to validate current activity. How well this all works depends more on your requirements and available time than the capabilities of particular tools. What angers me here the complete lack of discussion of SIEM, File Activity Monitoring, Data Loss Prevention, or Database Activity Monitoring – all four technologies exist today and don’t rely upon bizarre techniques to collect data or pseudoscience to predict crime. Four techniques with flexible analysis capabilities on tangible metrics. Four techniques that have been proven to detect misuse in different ways. We don’t really need more ‘innovative’ security technologies as Wired suggests. We need to use what we have. Often we need it to be easier to use, but we can already have good capabilities for solving these problems. Many of these tools have been demonstrated to work. The impediments are cost and effort – not lack of capabilities. Share: