Research

We are a full disclosure shop here at Securosis. That means you get to see the good, the bad, and yes, the ugly too. We’ve been pretty up front about saying it was just a matter of time before our stuff got hacked. In fact, you can check out the last comment from this 2007 post, where Rich basically says so. Not that we are a high profile target or anything, but it happens to everyone at some point or another. And this week was our time. Sort of. You see, we are a small business like many of you. So we try to leverage this cloud thing and managed services where appropriate. It’s just good business sense, given that many of these service providers can achieve economies of scale we could only dream about. But there are also risks in having somewhat sensitive information somewhere else. A small part of our email list was compromised, as a result of our service provider being hacked. I got an email from a subscriber to the Incite mailing list on Monday night, letting me know he was getting spam messages to an address he only uses for our list. I did some initial checking around and couldn’t really find anything amiss. Then I got another yesterday (Wednesday) saying the same thing, so I sent off a message to our email service provider asking what was up. It seems our email provider got compromised about 6 weeks ago. Yes, disclosure fail. Evidently they only announced this via their blog. It’s surprising to me that it took the bad guys 6 weeks to start banging away at the list, but nonetheless it happened and proves that one of our lists has been harvested. There isn’t anything we can do about it at this point except apologize. For those of you who share your email addresses with us, we are very sorry if you ended up on a spam list. And that’s one of the core issues of this cloud stuff. You are trusting your sensitive corporate data to other folks, and sometimes they get hacked. All you can do is ask the questions (hopefully ahead of time) to ensure your information is protected by the service provider, but at the end of the day this happens. We are on the hook for violating the trust of our community, and we take that seriously. So once again all of us at Securosis apologize. Share:

What a week. Last Monday and Tuesday I was out meeting with clients and prospects and was totally psyched at all the cool opportunities coming up. I was a bit ragged on Wednesday, but figured it was the lack of sleep. Nope. It was the flu. The big FLU, not its little cousin the cold. I was laid up in bed for 4 days, alternating between shivering and sweating. I missed our annual Turkey Trot 10K, Thanksgiving, and a charity dinner at our zoo I’ve been looking forward to all year. Then a bronchial infection set in, resulting in a chest x-ray and my taking (at one point) five different meds. Today (Thursday) is probably my first almost-normal day of work since this started. Those of you in startups know the joy that is missing unexpected time. But all is not lost. We are in the midst of some great projects we’ll be able to provide more detail on in the coming months. We are partnering with the Cloud Security Alliance on a couple things, and finally building out our first product. I’m actually getting to do some application design work again, and I forgot how much I miss it. I really enjoy research, but even though the writing and presenting portion is a creative act, it isn’t the same as building something. Not that I’m doing much of the coding. No one needs a new “Hello World” web app, no matter how cleverly I can use the <BLINK> tag. On a different note, we are starting (yes, already) to put together our 2011 Guide to RSA. We think we have the trends we will cover nailed, but if you have something you’d like in the guide please let us know. And don’t forget to reserve Thursday morning for the Disaster Recovery Breakfast. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian on Database Password Crackers. Rich quoted in SC: WikiLeaks prompts U.S. government to assess security. No easy tech answers for leaks, folks. Mike on consumerization of IT security issues at Threatpost. Rich wasn’t on the Network Security Podcast, but you should listen anyway. Favorite Securosis Posts Adrian Lane: Criminal Key Management Fail. No Sleep Till… David Mortman: Are You off the Grid? Mike Rothman: Are You off the Grid? You’ve got no privacy. Get over it. Again. Rich: Counterpoint: Availability Is Job #1. Actually, read the comments. Awesome thread. Other Securosis Posts I can haz ur email list. Incite 12/1/10: Pay It Forward. Holiday Shopping and Security Theater. Grovel for Budget Time. Ranum’s Right, for the Wrong Reasons. Incident Response Fundamentals: Phasing It in. Incite 11/24/2010: Fan Appreciation. I Am T-Comply. Meatspace Phishing Encounter. Availability and Assumptions. Favorite Outside Posts Adrian Lane: Security Offense vs. Defense. It’s a week old, but I thought this post really hit the mark. David Mortman: Software [In]security: Cyber Warmongering and Influence Peddling. Mike Rothman: And Beyond…. We all owe a debt of gratitude to RSnake as he rides off into the sunset. To pursue of all things – happiness. Imagine that. Rich: More than just numbers. Jack Jones highlights why no matter what your risk approach – quantitative or qualitative – you need to be very careful in how to interpret your results. Mike Rothman: Palo Alto Networks Initiates Search for Top Executive. Rarely do you see a white-hot private start-up take out the CEO publicly over differences in “management philosophy.” Board room conversations must have been ugly. Chris Pepper: Modern Espionage and Sabotage. Project Quant Posts NSO Quant: Index of Posts. Research Reports and Presentations 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 Chrome Gets a Sandbox for the Holidays. WordPress Fixes Vuln. RSnake’s 1000th post. Top Web Hacking Techniques Contest. Some great links! Robert Graham and the TSA. Kinda fun following his rants about the TSA. User Profiles Security Issue on Twitter. Ford employee stole $50M worth of secrets. Armitage UI for metasploit. Blog Comment of the Week Remember, for every comment selected, Securosis makes a $25 donation to Hackers for Charity. This week is a bit different – we had a ton of amazing comments on Firestarter: A Is Not for Availability and Counterpoint: Availability Is Job #1. Far too many to choose just one, so this is a group award that goes to: Somebloke Mark Wallace endo Steve Paul ds Dean Matt Franz Lubinski LonerVamp Franc mokum von Amsterdam TL sark Andrew Yeomans And of course, Adrian, Mike, Gunnar, and Mortman. Share:

I used to be a real TV head. Before the kids showed up, the Boss and I would spend a good deal of every Saturday watching the 5 or 10 shows we recorded on the VCR (old school, baby). Comedies, dramas, the whole ball of wax. Then priorities shifted and I had less and less time for TV. The Boss still watches a few shows, but I’m usually along for the ride, catching up on my reading while some drivel is on the boob tube (Praise iPad!). In fact, the only show I religiously watch is The Biggest Loser. I’ve mentioned before that, as someone for whom weight control is a daily battle, I just love to see the transformations – both mental and physical – those contestants undergo in a very short time. Actually this season has been pretty aggravating, but more because the show seems to have become more about the game than about the transformation. I stopped watching Survivor about 8 years ago when it became all about the money. Now I fear The Biggest Loser is similarly jumping the shark. But I do like the theme of the show this year: Pay It Forward. Each eliminated contestant seems to have found a calling educating the masses about the importance of better nutrition and exercise. It’s great to see. We have a similar problem in security. Our security education disconnect is less obvious than watching a 400 pounder move from place to place, but the masses are similarly uneducated about privacy and security issues. And we don’t have a forum like a TV show to help folks understand. So what to do? We need to attack this at the grassroots level. We need to both grow the number of security professionals out there working to protect our flanks, and educate the masses to stop hurting themselves. And McGruff the Cyber-crime dog isn’t going to do it. On the first topic, we need to provide a good career path for technical folks, and help them become successful as security professionals. I’m a bit skeptical of college kids getting out with a degree and/or security certification, thinking they are ready to protect much of anything. But folks with a strong technical/sysadmin background can and should be given a path to the misery that is being a security professional. That’s why I like the InfoSec Mentors program being driven by Marisa Fagan and many others. If you’ve got some cycles (and even if you don’t), working with someone local and helping them get on and stay on the path to security is a worthwhile thing. We also need to teach our community about security. Yes, things like HacKid are one vehicle, but we need to do more faster. And that means working with your community groups and school systems to build some kind of educational program to provide this training. There isn’t a lot of good material out there to base a program on, so that’s the short-term disconnect (and opportunity). But now that it’s time to start thinking about New Year’s Resolutions, maybe some of us can band together and bootstrap a simple curriculum and get to work. Perhaps a model like Khan Academy would work. I don’t know, but every time I hear from a friend that they are having the Geek Squad rebuild their machine because they got pwned, I know I’m not doing enough. It’s time to Pay it Forward, folks. And that will be one of my priorities for 2011. Photo credits: “Pay It Forward” originally uploaded by Adriana Gomez Incite 4 U You can’t outsource innovation: Bejtlich goes on a bit of a tirade in this post, basically begging us to Stop Killing Innovation. He uses an interview with Vinnie Mirchandani to pinpoint issues with CIO reporting structures and the desire to save money now, often at the expense of innovation. What Richard (and Vinnie) are talking about here is a management issue, pure and simple. In the face of economic uncertainty, many teams curl up into the fetal position and wait for the storm to pass. Those folks expect to ride productivity gains from IT automation, and they should. What they don’t expect is new services and/or innovation and/or out-of-the-box thinking. Innovation has nothing to do with outsourcing – it’s about culture. If folks looking to change the system are shot, guess what? They stop trying. So your culture either embraces innovation or it doesn’t. What you do operationally (in terms of automation and saving money) is besides the point. – MR It’s time: It’s time for a new browser. Some of you are thinking “WTF? We have Chrome, Safari, IE, Firefox, and a half dozen other browsers … why do I need or want another one”? Because all those browsers were built with a specific agenda in the minds of their creators. Most want to provide as much functionality as possible, and support as many fancy services as they can. It’s time for an idiot-proof secure browser. When I see stupid S$!& like this, which is basically an attempt to ignore the fundamental issue, I realize that this nonsense needs to stop. We need an unapologetically secure browser. We need a browser that does not have 100% functionality all the time. Sure, it won’t be widely used, because it would piss off most people by breaking the Internet with limited support for the ubiquitous Flash and JavaScript ‘technologies’. But I just want a secure browser to do specific transactions – like on-line banking. Maybe outfitted to corporate security standards (wink-wink). Could we fork Firefox to make this happen? Yeah, maybe. But I am not sure that it could be effectively retrofitted to thwart CSRF and XSS. The team here at Securosis follows Rich’s Macworld Super-safe Web Browsing guide, but keeping separate VMWare partitions for specific tasks is a little beyond the average user. This kind of security must come from the user side – web sites, security tool vendors, and security service

I got email from friends this week about a web site that creeped them out. It’s called Spokeo, and it provides a Google-like search on personal information. Rather than creeped out, I was fascinated. Not to look for other people, but to see what the search found for me. I hate mentioning it as I am not endorsing the web site or service, but I can’t help my fascination at seeing what personal data has been collected and aggregated on me. I actually have a larger Internet fingerprint than I expected! This tool is kinda like Firesheep for personal information: the data is already out there, this site just shoves in your face how easy it is for anyone to collect basic stuff about you. But the friends who directed me to the site were genuinely worried that criminals would use the site to locate single women in their late 70s in order to create a robbery target list. Seriously … that explicit. I told them they needed counseling as they probably had ‘mommy’ issues. I find this ridiculous because in Arizona we call have ‘Sun City’ – the age-restricted community where everyone seems to be over 70, with some of the lowest crime rates in the county. I make a big deal about personal data because I believe no good deed goes unpunished. Shared personal information will sooner or later be used against you. My personal phobia is that an insurance company will write an automated crawler for personal data, consider something I do ‘risky’, and quadruple my rate for fun. Yeah, I probably need counseling as well. The paranoid part of me wanted to know how much more I had exposed myself. I looked myself up in various states, with and without my middle name. In most cases it’s easy to see where the data came from. Facebook. LinkedIn. Yelp. Some information has to be public because of government regulations. Sometimes it looks like data collected from other people’s contact lists that I never authorized, which is why I found old phone numbers from decades past. In some cases I couldn’t tell – I looked on all of the social media I use and couldn’t find a reference. It’s been a decade or so but I knew I would eventually see a tool like this. What made me laugh is that my years of paranoia have paid off. This shows up in how they get a lot of stuff wrong. Whenever I sign up for anything on line I always use make-believe data: age, race, contact information, etc. Sure, some digital profiles are work-related and so can’t be totally fake, but it’s kinda fun to see that I am a late-40’s hispanic woman to much of the digital world. Still, private as I am, I lost the bet with my wife, who has less public data out there. She is virtually invisible online. “Ha! Take that, Mr. Privacy Expert!” was her comment. Share:

One of the concepts I use in my Pragmatic CSO material is a Day in the Life of a CISO. There are lots of firefighting and other assorted activities. I usually get a big laugh when I get to the part about groveling to the CIO and CFO for budget. Yes, I call it like I see it. But after seeing a post on budgeting by Ed Moyle from before Thanksgiving, I think it’s time to dig a bit deeper. Remember the budget is pretty critical to your success (or failure) in security. This job is hard enough with sufficient resources and funding. Without them, you’ve got no shot. So becoming a budget ninja is one of the key skills to climb the security career ladder. Ed makes a number of good points about spending transparency and measuring effectiveness. Basically trying to show senior management what you spend money on and how well it’s working. I agree with all of those sentiments. And I’m being a bit sarcastic (go figure), when I talk about groveling for budget. You need to ask, but in a way that provides a chance of success. And the most useful tool I’ve seen used for this in practice is the idea of scenarios. Basically when building up your architecture, project plans, and other assorted strategies for the coming year, think about breaking up those ideas into (at least) three scenarios: Low bar: This is the stuff you absolutely need – in order to have any shot at protecting your critical information, or meeting your compliance mandate, or the like. To understand where this bar is, think about a scenario where you would quit because you don’t have enough resources/funding to have any shot, and a significant issue becomes a certainty. That is your low bar. High bar: This is what you need to really do the job. Not to 100% certainty – don’t be silly. But enough to have a good feeling that you’ll be able to get the job done. Real bar: This is somewhere in the middle and what you hope to be the most likely scenario. To be clear, how much funding you get to do security is out of your control. It’s a business issue. You are competing with not just IT projects, but all projects, for that resource allocation. And if you think it’s a slam dunk to build a case for a new perimeter security infrastructure, as opposed to a new machine that can streamline manufacturing, think again. Even if you know your project is the right thing to do, it may not be as clear to someone with lots of folks all groveling for their own pet projects. The scenarios help you explain the risks of not doing something, and provide a more tangible idea of the costs, than a long project list which means nothing to a non-security person. Scenario Risks Group your projects into scenarios, and model a specific type of attack that would be protected. For example, in your low bar scenario, just make the case that you’ve got no shot to meet compliance mandate X without that funding. Then explain the possible ramifications of not being compliant (fines, brand damage, breaches, etc.). This must be done in a dispassionate way. You are presenting just the facts, like Joe Friday. The burden is on the business managers to weigh the risk of not meeting (funding) the low bar. When presenting the high bar, you can discuss some of the emerging attacks that you’d be able to either block or more likely detect faster to mitigate damage. Get as specific as you can, use real examples of your applications and the impact of those going down. But be careful to manage expectations. Even if you reach the high bar of funding (which typically only happens after a breach), you still may have problems, so don’t bet your firstborn or anything. The real bar provides a good mixture of protection and compliance. Or at least it should. Truth be told, this is our hopeful scenario, so make it realistic and plausible. Make it clear what you can’t do (relative to the high bar) and what you can do (compared to the low bar). And more importantly the potential risks/losses of each decision. Not in an annualized loss expectancy way, but in a we’ll lose this kind of data way. The key here is to rely on contrast to help the bean counters understand what you need and why. The low bar is really the bare minimum. Make that clear. The high bar is a wish list, and in reality most wishes don’t come true. The real bar is where you want to get to, so use some creativity to make the cases push your desired outcome. Don’t Take It Personally Above all else, when dealing with budgeting, you can’t take it personally. Every executive team must balance strategic investments and risks and decide what is the best way to allocate the limited resources of the organization. Sometimes you win the battle, sometimes you lose. As long as you get to the low bar, that’s what you get. If you don’t get to the low bar, then maybe you should take it personally. Either you made a crappy case, you have no credibility, or the powers that be have decided (in their infinite wisdom) that they are willing to accept the risks of not hitting the low bar. That doesn’t mean you have to accept those risks. Remember, you are the one who will be thrown out of the car (at high speed), if things go south. So if you don’t reach the low bar, it make be time to look for another gig. And do it aggressively and proactively. You don’t want to be circulating your resume while your organization is cleaning up a high profile breach. Photo credits: “spare change towards weed + starbucks 🙂 long live bank of america” originally uploaded by sandcastlematt Share:

This is usually the time of year I write a how-to article on safe seasonal shopping. And some of it is the usual generic advice – use a credit card, don’t click email links, use merchants you trust, etc. – but I like to include specific advice to deal with new seasonal threats. Wading into the deluge of threat warnings about Black Friday shopping schemes this year, I found mostly noise. There are plenty of real attacks consumers should be worried about, but many which aren’t worth the attention. And every article seems to have a particular agenda. For example, I have a hard time believing SMS banking scams are a real threat to holiday shoppers, in the same way I can’t imagine someone falling for a Nigerian banking scam or turning off their refrigerator because of a crank call. Some are so targeted at a small group, the news is only interesting to the most dedicated security researchers. Others attacks combine good old fashioned fraud with a few Search Engine Optimization shenanigans to game the system, causing a lot of people grief, but persist until law enforcement makes then a priority to investigate. Of the dozens of articles out there, they all seemed to feed the security theater, making it much harder to know what’s a real threat and what’s not. I don’t know if Bruce Schneier coined the term Security Theater, but he’s certainly the first person I head use the expression. Over the years I thought I knew exactly what he meant: pretending to do something about security when not really doing much of anything. But every couple years I find a new wrinkle to the concept, and now the term embraces several variants. To my mind there are at least four additional variations on this theme, all quasi-political: Grandstanding: For the pure selfish desire to be front and center in a discussion, and a relevant force in the industry, talking about security topics in overheated terms such as ‘Cyber-War’, taking the popular side on a one-sided issue like spam, or stating “X technology is dead!” Voyeuristic Groupies: The audience for security theater. If you have ever been to Washington DC and watched the lawyers and lobbyists huddle around politicians and policy makers for the sheer enjoyment of watching partisan politics as if it were Shakespearean theater, you know what I am talking about. The audience for security theater is simply fascinated by the hacks and clever ways in which hardware, software, and people are subverted. They love security rock stars. Hacking news may not contain much actionable information, but this audience feeds on the drama. Red Herring: Cry loudly about one problem, while studiously avoiding equally troubling issues. A little security theater redirects the spotlight away from the real problem. Like how to protect oneself from Firesheep, when the real problem is security irresponsibility and sloppy web site coding practices, which are much harder to tackle. Or focusing attention on ATM skimmer fraud becoming more of a problem while releasing very little information on the rates of compromised point-of-sale computers that serve credit card readers. Both are serious security problems – and I am guessing that they cause equal financial losses – but we have published numbers in one instance and not for the other. I understand why: one makes the bank or merchant look like the victim, but the other makes them look too cheap/lazy/incompetent to provide security. Reverse Scamming: The ATM skimming article referenced above states that there are technologies that solve these problems, such as ‘Chip-and-PIN’ systems. The theoretical argument is that this system is better because it uses two-factor authentication (knowing your PIN and having the card with the chip in it), in practice these systems have been hacked with great success. Look no further that European ATM fraud rates if you have any doubt. If you are a vendor of such technologies, it’s sure great to have people think you can solve the problem, and maybe even get adopted it as a standard. What better way to fill the company coffers? One thing we know for sure is that on-line fraud rates are on the rise, and both companies and individuas are targets. What we don’t have this year is one or two popular attack types to warn users about – rather we are seeing every known type. And this is further clouded byt seeing more ‘spin’ on security news than I have ever seen before. So this year’s advice is simple: use your head, and use your credit card. Hopefully that will keep you out of trouble, or at least reduce your liability if you do find any. Share:

Information Security Magazine’s November issue is available. In it is an interesting rehash of the security monoculture debate between Bruce Schneier and Marcus Ranum some 8 years ago. Basically the hypothesis was that if all your software is provided by one vendor, a single security vulnerability means everyone is vulnerable. The result is a worldwide cascade of failures. The term “domino effect” was thrown around to describe what would happen. I remember reading that debate when it first came out, but the most interesting aspect of this discussion is actually how much the threat landscape has changed in 8 years. Much of the argument was based on a firm with a culture of insecurity. Who knew Microsoft would take security seriously, and dramatically improve their products? Who knew that corporate espionage would be a bigger threat than DDoS? And that whole Apple thing … total surprise. All in all I tend to agree with Ranum’s position, but not because of the shaky points he raised. It’s not because everyone patches at different rates, or that some systems are “loosely coupled” or in “walled gardens”, or even that the organism analogies suck. It’s because of two things: Resiliency – Marcus’s point that the first part of the scenario – hacked systems every week for the last 15 years – is spot on. But the Internet continues to rumble along, warts and all. I don’t think this has so much to do with the difference in the way servers are managed, it’s that companies are a lot better at disaster recovery that they are security. Recover from tape, patch, and move on. We know how to do this. We got hacked, we fixed the immediate problem, and we moved on. Vulnerabilities – Even if we had very small communities of software developers, is there any reason whatsoever to believe security would be better? Just because we don’t have write-once, exploit-everywhere malware, it does not mean that all the smaller vendors would not have been hacked. Just because Microsoft was a large target does not mean Adobe was any more secure. Marcus has published research on how people studiously avoid accepting blame for stupid decisions and are likely to repeat them. Even without a monoculture, classes of vulnerabilities like buffer overflow, SQL injection, and DoS are common to all software. And classes of people persist as well. It would take hackers more time and effort for every system they attack in a diversified model, but they would still be able to hack them. But the goal is usually stealthy theft of data, so the probability of detecting compromise also falls. We did see millions of web sites, applications, and databases compromised over the last 8 tears. And we know many more were never made public. And we have no way to calculate the cost in terms of lost productivity, or the damage due to corporate espionage. But recent APT attacks using unpublished Microsoft 0-day attacks, such as the recent Stuxnet attack, show it does not matter whether it’s mainstream software from a single large vendor, or obscure SCADA software nobody’s ever heard of. Every piece of software I have ever encountered has had security bugs. Monoculture or otherwise, we’ll see lots of vulnerable software. I could offer an organism based analogy, or a parable about genetics and software development, but that would probably just annoy Marcus more than I already have. Share:

You may have noticed we’ve renamed the React Faster and Better series to Incident Response Fundamentals. Securosis shows you how the security research sausage gets made, and sometimes it’s messy. We started RFAB with the idea that it would focus on advanced incident response tactics and the like. As we started writing, it was clear we first had to document the fundamentals. We tried to do both in the series, but it didn’t work out. So Rich and I re-calibrated and decided to break RFAB up into two distinct series. The first, now called Incident Response Fundamentals, goes into the structure and process of responding to incidents. The follow-up series, which will be called React Faster and Better, will delve deeply into some of the advanced topics we intended to cover. But enough of that digression. When we left off, we had talked about what you have to do from a structural standpoint (command principles, roles and organizational structure, response infrastructure and preparatory steps), an infrastructure perspective (data collection/monitoring), before the attack, during the attack (trigger, escalate, and size up and contain, investigate, and mitigate, and finally after the attack (mop up, analyze, and QA) to get a broad view of the entire incident response process. But many of you are likely thinking, “That’s great, where do I start?” And that is a very legitimate question. It’s unlikely that you’ll be able to eat the elephant in one bite, so you will need to look at breaking the process into logical phases and adopt those processes. After integrating small pieces for a while, you will be able to adopt the entire process effectively. After lots of practice, that is. So here are some ideas on how you can break up the process into logical groups: Monitor more: The good news is that monitoring typically falls under the control of the tech folks, so this is something you can (and should) do immediately. Perhaps it’s about adding additional infrastructure components to the monitoring environment, or maybe databases, or applications. We continue to be fans of monitoring everything (yes, Adrian, we know – as practical), so the more data the better. Get this going ASAP. Install the organization: Here is where you need all your persuasive powers, and then some. This takes considerable coercion within the system, and doesn’t happen overnight. Why? Because everyone needs to buy in on both the process and their response responsibilities & accountabilities. It’s not easy to get folks to step up on the record, even if they have been doing so informally. So you should get this process going ASAP as well, and coercion (you can call it ‘persuasion’) can happen concurrently with the additional monitoring. Standardize the analysis: One of the key aspects of a sustainable process is that it’s bigger than just one person; that takes some level of formality and, even more important, documentation. So you and your team should be documenting how things should get done for network investigation, endpoint investigation, and database/application attacks as well. You may want to consult an external resource for some direction here, but ultimately this kind of documentation allows you to scale your response infrastructure, as well as set expectations for what and how things need to get done in the heat of battle. This again can be driven by the technical folks. Stage a simulation: Once the powers that be agree to the process and organizational model, congratulations. Now the work can begin: it’s time to practice. We will point out over and over again that seeing a process on the white board is much different than executing it in a high-stress situation. So we recommend you run simulations periodically (perhaps without letting the team know it’s a simulation) and see how things go. You’ll quickly quickly the gaps in the process/organization (and there are always gaps) and have an opportunity to fix things before the attacks start happening for real. Start using (and improving) it: At this point, the entire process should be ready to go. Good luck. You won’t do everything right, but hopefully the thought you’ve put into the process, the standard analysis techniques, and the practice allow you to contain the damage faster, minimizing downtime and economic impact. That’s the hope anyway. But remember, it’s critical to ensure the QA/post-mortem happens so you can learn and improve the process for the next time. And there is always a next time. With that, we’ll put a ribbon on the Incident Response Fundamentals series and start working on the next set of advanced incident response-related posts. Share:

Though I have tailed off a bit from my ridiculous pace of two years ago, I still go see a lot of live music. Although many of these acts make a mint, it’s not an easy life. I can only imagine how difficult it is to be on the road for months at a time. It’s hard enough for me, and I’m only gone one or two nights at a time. Though it’s not like I’m staying at the Ritz every night (don’t tell Rich I’m staying at the Ritz, okay?). But there are examples of bands that do a job and earn their money every night. Let me highlight two great examples. First off, I saw Green Day during the summer. Those guys are one of the biggest bands in the world right now, but they haven’t forgotten where they came from. They played for almost 3 hours, had folks doing stage dives, and even gave a guitar to a lucky audience member. At one point they all dressed in drag for a few laughs. And repeatedly they made the point about how much they appreciated their fans and that they give everything every night to make sure the fans get their money’s worth. They know that seeing a rock concert is a luxury for many people, and are grateful their fans choose to spend money they may not have to see them play music. Next I’ll highlight Styx. I saw them a few weeks ago on their Grand Illusion/Pieces of Eight tour. They played each album in its entirety and it was like stepping into a time machine. These guys haven’t had a hit record in decades, but they are able to travel around and play their classics year after year. And folks like me show up every time, which I assume provides a decent living for guys who probably carry AARP cards. They get how lucky they are and they play like it. It was a great show. I guess my point is that we all have fans, whatever that definition is. Folks who allow you to do what you do. Do you appreciate them? Really? In the day to day mayhem of deadlines and other demands, I need to remember that without our readers and contributors, I wouldn’t be able to do what I love. With Thanksgiving coming up, I want to let you know how appreciative I am. For all of you who read our stuff, who show up when we pontificate, and who ask for our advice, thank you. I know I speak for Rich and Adrian as well. We know how good we have it, and that’s because of you. So before you take off for the long weekend (if you are in the US, anyway), make sure your fans know you appreciate them. I know they’d appreciate being appreciated. Photo credits: “Starsky & Hutch Appreciation Fan Club originally uploaded by Ged Carroll Incite 4 U Truth in advertising? – Stop reading this and click this link. Read the words in the picture very carefully. Doesn’t it make a pretty acronym? Mike is pretty slow, so I’ll spell it out. The first letters of McAfee’s three attributes (Focused, Unwavering, & Dedicated) spell out FUD. Really. You have to see it to believe it. I have a really hard time believing this was completely accidental, and nobody at McAfee was sniggering when they came up with it. Perhaps some marketing wonk misunderstood the meaning. Perhaps someone knew what they were doing, and wanted to see if they could pull a fast one. Perhaps this was a Titanic example of proofreading FAIL. I actually saw that while driving to my hotel for an appointment today, but only off in the distance when I couldn’t read it. Anyway, I suspect it won’t be up for long, which is too bad because it shows a heck of a sense of humor. Maybe. – RM Why bother? – The SQL Server 2008 option for massively parallel servers is going to be late. Actually, it’s already late, but it’s going to be even late-er-er or something like that. But the question in my mind is why? Why play this game at all? Why try to be the biggest and fastest relational database out there when performance benchmarks have not been a major buying considerations for databases in 15 years. Teradata has a killer database that scales great … but it’s not exactly dominating the market. Look at super-fast databases and database hardware providers historically, and tell me how they have generally done. Ant? Sequent? Yeah, exactly. I can see why Microsoft would like to be a player in that lucrative field, but the number of firms willing to spend $40k per processor on giant mission critical transaction processing systems is dwindling. BI and data warehousing is moving to generic cloud based non-relational data stores that perform 10 to 100 times better, but can be leased at fractions of the price. And the requirements of the data warehousing market are changing. My guess is that cloud services will be “good enough”, and this will be a case where “cheap, fast, and easy” cuts the massively parallel server market down before Microsoft arrives on the scene. – AL Ray Noorda rolls in his grave… – Like Shimmy, I remember when Novell was the king of networking. In fact, I cut my teeth on a Novell LAN (Token Ring, in fact) and am happy to say I have a CNE (that lapsed probably 20 years ago). But Novell is no more. It’s being acquired by Attachmate for a cool $2.2 billion. And that doesn’t seem to include some intellectual property that Microsoft is buying. It seems Attachmate is becoming a friendly CA, in that they buy mature, slow-growth businesses with big customer bases and the associated maintenance streams. Novell does compete in some growth markets like Identity Management, SIEM, and desktop management – but really the private equity guys are using leverage to buy cash flow. It’s a good model for the investors – not sure for customers.

Skipped out of town for a much needed vacation Friday, and spent the weekend in a very remote section of desert. I spent my time hiking to the top of several peaks and overlooking vast areas of uninhabited country. I rode quads, wandered around a perfectly intact 100 year old mine shaft, did some target practice with a new rifle, built giant bonfires, and sat around BSing with friends. A total departure from everyday life. So I was in a semi-euphoric state, and trying to ease my way back into work. I was not planning on delving into complex security philosophy and splitting semantic hairs. But here I am … talking about Quantum Datum. Rich’s Monday FireStarter is a departure from the norm for security. The resultant comments, not so much. Cloud, SaaS, and other distributed resource usage models are eviscerating perimeter based security models. For a lot of you who read this blog that’s a somewhat tired topic, but what to do about it is not. You need to view Rich’s comments from a data perspective. If the goal is to secure data, and the data must be self-defending because it can’t trust the infrastructure, what we do today breaks. As is his habit, Gunnar Peterson succinctly captured the essence of the friction between IT & Security in response to Mike’s “Availability Is Job #1” post: I agree that availability is job 1, its just not security’s job. We have built approx zero systems that have traditional cia, time to move on. And we fall back into the same mindset, as we don’t have a mental picture of what Rich is talking about. The closest implementations we have are DLP and DRM, and they are still still off the mark. I look at traditional C-I-A as a set of goals for security in general, and attribution as a tool – much in the way encryption and access control are tools. Rereading Rich’s post, I think I missed some of the subtleties. Rich is describing traits that self-defending data must possess, and attribution is the most difficult to construct because it defines specific use cases. Being so entrenched in our current way of thinking limits our ability to even discuss this topic in a meaningful way, because we have unlearn certain rules and definitions. Is availability job 1? Maybe. If you’re a public library. If you’re the Central Intelligence Agency, no way. Most data will fall somewhere between these two extremes, and should have restrictions on how it is available. So the question becomes: when is data available? Attribution helps us determine what’s allowed, or when data is available, and under what circumstances. But we build IT systems with the concept that the more people can access and use data, the more value it has. Rich is right: treating all data like it should be available is a broken model. Time to learn a new C-I-A. Share: