Research

This is off topic but I need to vent a bit. I’ve followed the LeBron James free-agency saga with amusement. Thankfully I was in the air last night during the “Decision” TV special, so I didn’t have any temptation to participate in the narcissistic end of a self-centered two weeks. LeBron and his advisors did a masterful job of playing the media, making them believe anything was possible, and then doing the smartest thing and heading to Miami to join the Heat. First off, I applaud all three All-Stars, who made economic sacrifices to give themselves a chance to win. They all understand that a ball-player’s legacy is not about how much money they made, but how many championships they won. Of course, the economic sacrifices are different for them – you know, whether to settle for $2 or $3 million less each year. Over 6 years that is big money, but they want to win and win now. But that’s not what I want to talk about. I want to talk about how the Cavaliers’ owner, Dan Gilbert, responded to the situation. It makes you think about the high road versus the low road. Clearly Gilbert took the low road, basically acting like a spoiled child whose parents said they couldn’t upgrade to the iPhone 4. He had a tantrum – calling LeBron names and accusing him of giving up during the playoffs. The folks at the Bleacher report hit it right on the head. I understand this guy’s feelings are hurt. LeBron (and his advisors) played him like a fiddle. They gave him hope that LeBron would stay, even though at the surface it would be a terrible decision – if the goal is to win championships. Over the past 8 years, LeBron doubled the net worth of the Cavs franchise, and that is the thanks he gets from the owner. Can you see Bob Kraft of the Patriots having a similar tantrum? Or any of the top owners in the sport? Yes, Dan Gilbert really reflected the mood of his town. His frustration at losing the LeBron-stakes aligns with the prospect of losing a lot more in years to come. But as an owner, as the face of your franchise, you have to take the high road. You get a Cleveland sports columnist to write the hit piece making all those speculations. But, you (and the rest of the franchise) need to act with class. Have the PR folks write a short statement thanking your departing star for 8 great years of sell-outs, wishing him the best of luck, and saying you look forward to seeing them in the Eastern Conference finals. Most of all, you take a step back and you don’t say anything. That’s what I try to tell the kids when they are upset. And try to practice myself (failing most of the time, by the way). Don’t say anything because you’ll only make it worse and say something you’ll regret. I’m sure folks in Cleveland are happy with Dan Gilbert’s outburst, but the rest of the country sees a total ass having a tantrum in public. And overnight he made LeBron into a sympathetic figure. Which is probably what LeBron and his advisors wanted the entire time. Damn, that’s one smart power forward, probably enjoying the view from the high road. Share:

Today is the deadline for RSA speaker submissions, so the entire team was scrambling to get our presentation topics submitted before the server crash late rush. One of the things that struck me about the submission suggestions is that general topics are discouraged. RSA notes in the submission guidelines that 60% of the attendees have 10 or more years of security experience. I think the idea is that, if your audience is more advanced, introductory or general audience presentations don’t hold the audience’s attention so intermediate and advanced sessions are encouraged. And I bet they are right about that, given the success of other venues like BlackHat, Defcon, and Security B-Sides. Still, I wonder if that is the right course of action. Has security become a private club? Are we so caught up in the security ‘echo chamber’ we forget about the mid-market folks without the luxury of full-time security experts on staff? Perhaps security just is not very interesting without some novel new hack. Regardless, it seems like it’s the same group of us, year after year, talking about the same set of issues and problems. From my perspective software developers are the weakest link in the security chain. Most coders don’t have 10 years of security experience. Heck, they don’t have two! Only a handful of people I know have been involved in secure code development practices for 10 years or more. But developers coming up to speed with security is one of the biggest wins, and advanced security topics may not be inaccessible to them. The balancing act between cutting-edge security discussions that keep researchers up to date, versus educating the people who can benefit most, is at issue. I was thinking about this during our offsite this week while Rich and Mike talked about having their kids trained in martial arts when they are old enough. They were talking about how they want the kids to be able to protect themselves when necessary. They were discussing likely scenarios and what art forms they felt would be most useful for, well, not getting their asses kicked. And they also want the kids to derive many of the same secondary benefits of respect, commitment, confidence, and attention to detail many of us unwittingly gained when our parents sent us to martial arts classes. As the two were talking about their kids’ basic introduction to personal security, it dawned on me that this is really the same issue for developers. Not to be condescending and equate coders to children, but what was bugging me was the focus on the leaders in the security space at the expense of opening up the profession to a wider audience. Basic education on security skills doesn’t just help build up a specific area of education every developer needs – the entire approach to secure code development makes for better programmers. It reinforces the basic development processes we are taught to go through in a meaningful way. I am not entirely sure what the ‘right’ answer is, but RSA is the biggest security conference, and application developers seem to be a very large potential audience that would greatly benefit from basic exposure to general issues and techniques. Secure code development practices and tools are, and hopefully will remain for the foreseeable future, a major category for growth in security awareness and training. Knowledge of these tools, processes, and techniques makes for better code. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich and Adrian in Essentials Guide to Data Protection. Rich on Top Three Steps to Simplify DLP without Compromise. Rich quoted at Dark Reading on University Data Breaches. Favorite Securosis Posts Adrian Lane: School’s out for Summer. Mike Rothman: Incite 7/7/2010: The Mailbox Vigil. Normally I don’t toot my own horn, but this was a good deal of analysis. Fairly balanced and sufficiently snarky… David Mortman: School’s out for Summer. Rich: Understanding and Selecting SIEM/LM: Selection Process. Other Securosis Posts Uh, not so much. Favorite Outside Posts Adrian Lane: Atlanta Has Dubious Honor of Highest Malware Infection Rate. This was probably not meant to be humorous, but the map of giant bugs just cracked me up. Does this help anyone? Rich: Top Apps Largely Forgo Windows Security Protections. There is more to vulnerability than the operating system. We can only hope these apps get on board with tactics that will make them (and us) harder to pwn. Mike Rothman: RiskIT – Does ISACA Suffer from Dunning-Kruger?. Hutton is at it again, poking at another silly risk management certification. I’m looking forward to my “Apparently OK” Risk Certificate arriving any day now. Pepper: HSBC mailing activated debit cards. And to make it better, they didn’t agree that this is a serious problem. David Mortman: The New Distribution of The 3-Tiered Architecture Changes Everything. Project Quant Posts DB Quant: Protect Metrics, Part 2, Patch Management. DB Quant: Manage Metrics, Part 1, Configuration Management. DB Quant: Protection Metrics, Part 4, Web Application Firewalls. Research Reports and Presentations White Paper: Endpoint Security Fundamentals. Understanding and Selecting a Database Encryption or Tokenization Solution. Low Hanging Fruit: Quick Wins with Data Loss Prevention. Top News and Posts Regional Trojan Threat Targeting Online Banks. Is Breaking a CAPTCHA a crime? A little more on Cyberwar. Blog Comment of the Week This week’s winner is … no one. We had a strong case of ‘blog post fail’ so I guess we cannot expect comments. Share:

Just when I thought I was done talking about DLP, interest starts to increase again. Below is an article I wrote up on how to minimize the complexity of a DLP deployment. This was for the Websense customer newsletter/site, but is my usual independent perspective. One of the most common obstacles to a DLP deployment is psychological, not technical. With massive amounts of content and data streaming throughout the enterprise in support of countless business processes, the idea that we can somehow wrangle this information in any meaningful way, with minimal disruptions to business process, is daunting if not nigh on inconceivable. This idea is especially reinforced among security professionals still smarting from the pain of deploying and managing the constant false positives and tuning requirements of intrusion detection systems. Since I started to cover DLP technologies about 7 years or so ago, I’ve talked with hundreds of people who have evaluated and/or deployed data loss prevention. Over the course of those conversations I’ve learned what tends to work, what doesn’t, and how to reduce the potential complexity of DLP deployments. Once you break the process down it turns out that DLP isn’t nearly as difficult to manage as some other security technologies, and even very large organizations are able to rapidly reap the benefits of DLP without creating time-consuming management nightmares. The trick, as you’ll see, is to treat your DLP deployment as an incremental process. It’s like eating an elephant – you merely have to take it one bite at a time. Here are my top 3 tips, drawn from those hundreds of conversations: 1. Narrow your scope: One of the most common problems with an initial DLP deployment is trying to start on too wide a scale. Your scope of deployment is defined by two primary factors – how many DLP components you deploy, and how many systems/employees you monitor. A full-suite DLP solution is capable of monitoring network traffic, integrating with email, scanning stored data, and monitoring endpoints. When looking at your initial scope, only pick one of the components to start with. I usually recommend starting with anything other than endpoints, since you then have fewer components to manage. Most organizations tend to start on the network (usually with email) since it’s easy to deploy in a passive mode, but I do see some companies now starting with scanning stored data due to regulatory requirements. In either case, stick with one component as you develop your initial policies and then narrow the scope to a subset of your network or storage. If you are in a mid-sized organization you might not need to narrow too much, but in large organizations you should pick a subnet or single egress point rather than thinking you have to watch everything. Why narrow the scope? Because in our next step we’re going to deploy our policies, and starting with a single component and a limited subset of all your traffic/systems provides the information you need to tune policies without being overwhelmed with incidents you feel compelled to manage. 2. Start with one policy: Once you’ve defined your initial scope, it’s time to deploy a policy. And yes, I mean a policy, not many policies. The policy should be narrow and align with your data protection priorities; e.g. credit card number detection or a subset of sensitive engineering plans for partial document matching. You aren’t trying to define a perfect policy out of the box; that’s why we are keeping our scope narrow. Once you have the policy ready, go ahead and launch it in monitoring mode. Over the course of the next few days you should get a good sense of how well the policy works and how you need to tune it. Many of you are likely looking for similar kinds of information, like credit card numbers, in which case the out of the box policies included in your DLP product may be sufficient with little to no tuning. 3. Take the next bite: Once you are comfortable with the results you are seeing it’s time to expand your deployment scope. Most successful organizations start by expanding the scope of coverage (systems scanned or network traffic), and then add DLP components to the policy (storage, endpoint, other network channels). Then it’s time to start the process over with the next policy. This iterative approach doesn’t necessarily take very long, especially if you leverage out of the box policies. Unlike something like IDS you gain immediate benefits even without having to cover all traffic throughout your entire organization. You get to tune your policies without being overwhelmed, while managing real incidents or exposure risks. Share: