Research

They say the grass is always greener on the other side, and I guess for some folks it is. Most private companies (those which believe they have sustainable businesses, anyway) long for the day when they will be able to trade on the public markets. They know where the Ferrari deal is, and seem to dismiss the angst of Sarbanes-Oxley. On the other hand, most public companies would love the freedom of not having to deal with the quarterly spin cycle and those pesky shareholders who want growth now. Two examples in the security space show the pendulum in action this week. First is Tripwire’s IPO filing. I love S-1 filings because companies must bare their innards to sell shares to public investors. You get to see all sorts of good stuff, like the fact that Tripwire has grown their business 20-30% annually over the past few years. They’ve been cash flow positive for 6 years, and profitable for the last two (2008 & 2009), although they did show a small loss for Q1 2010. Given the very small number of security IPOs over the past few years, it’s nice to see a company with the right financial momentum to get an IPO done. But as everyone who’s worked for a public company knows, it’s really about growth – profitable growth. Does 20-30% growth on a fairly small revenue base ($74 million in 2009) make for a compelling growth story? And more importantly for company analysis, what is the catalyst to increase that growth rate? In the S-1, Tripwire talks about expanding product offerings, growing their customer base, selling more stuff to existing customers, international growth, government growth, and selective M&A as drivers to increase the top line. Ho-hum. From my standpoint, I don’t see anything that gets the company from 20% growth to 50% growth. But that’s just me, and I’m not a stock analyst. Being publicly listed will enable Tripwire to do deals. They did a small deal last year to acquire SIEM/Log Management technology, but in order to grow faster they need to make some bolder acquisitions. That’s been an issue with the other public security companies that are not Symantec and McAfee – they don’t do enough deals to goose growth enough to make the stock interesting. With Tripwire’s 5,400 customers, you’d figure they’ll make M&A and pumping more stuff into their existing base a key priority once they get the IPO done. On the other side of the fence, you have SonicWall, which is being taken private by Thoma Bravo Group and a Canadian pension fund. The price is $717 million, about a 28% premium. SonicWall has been public for a long time and has struggled of late. Momentum seems to be returning, but it’s not going to be a high flyer any time soon. So the idea of becoming private, where they only have to answer to their equity holders, is probably attractive. This is more important in light of SonicWall’s new push into the enterprise. They are putting a good deal of wood behind this Project SuperMassive technology architecture, but breaking into the enterprise isn’t a one-quarter project. It requires continual investment, and public company shareholders are notoriously impatient. SonicWall was subject to all sorts of acquisition rumors before this deal, so it wouldn’t be surprising to see Thoma Bravo start folding other security assets in with SonicWall to make a subsequent public offering, a few years down the line, more exciting. So the pendulum swings back and forth again. You don’t have to be Carnac the Magnificent to figure there will be more deals, with the big getting bigger via consolidation and technology acquisitions. You’ll also likely see some of the smaller public companies take the path of SafeNet, WatchGuard, Entrust, Aladdin, and now SonicWall, in being taken private. The only thing you won’t see is nothing. The investment bankers have to keep busy, don’t they? Share:

There’s nothing like a crisis to bring out the absolute stupidity in a person… especially if said individual works for a big company or government agency. This week alone we’ve had everything from the ongoing BP disaster (the one that really scares me) to the Israeli meltdown. And I’m sure Sarah Palin is in the mix there someplace. Crisis communications is an actual field of study, with many examples of how to manage your public image even in the midst of a major meltdown. Heck, I’ve been trained on it as part of my disaster response work. But it seems that everyone from BP to Gizmodo to Facebook is reading the same (wrong) book: Deny that there’s a problem. When the first pictures and videos show up, state that there was a minor incident and you value your customers/the environment/the law/supporters/babies. Quietly go to full lockdown and try to get government/law enforcement to keep people from finding out more. When your lockdown attempts fail, go public and deny there was ever a coverup. When pictures/video/news reports show everyone that this is a big fracking disaster, state that although the incident is larger than originally believed, everything is under control. Launch an advertising campaign with a lot of flowers, babies, old people, and kittens. And maybe some old black and white pictures with farms, garages, or ancestors who would be the first to string you up for those immoral acts. Get caught on tape or in an email/text blaming the kittens. Try to cover up all the documentation of failed audits and/or lies about security and/or safety controls. State that you are in full compliance with the law and take safety/security/fidelity/privacy/kittens very seriously. As the incident blows completely out of control, reassure people that you are fully in control. Get caught saying in private that you don’t understand what the big deal is. It isn’t as if people really need kittens. Blame the opposing party/environmentalists/puppies/you business partners. Lie about a bunch of crap that is really easy to catch. Deny lying, and ignore those pesky videos showing you are (still) lying. State that your statements were taken out of context. When asked about the context, lie. Apologize. Say it will never happen again, and that you would take full responsibility, except your lawyers told you not to. Repeat. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Mike Rothman on Tabnapping at SC Magazine. The Network Security Podcast, Episode 199. Rich presented on Data Breaches for whitehatworld.com; it should show up on their archive page soon. Favorite Securosis Posts Rich: NSO Quant: Monitor Process Map. These Quant projects keep getting bigger each time we do one, but it’s nice to do some real primary research. Adrian Lane: The Hidden Costs of Security. Mike Rothman: Understanding and Selecting SIEM/LM: Correlation and Alerting. We are working through the SIEM/Log Management research. Check it out and provide comments, whether you agree or disagree with our perspectives. Other Securosis Posts The Public/Private Pendulum Keeps Swinging. White Paper Released: Endpoint Security Fundamentals. Thoughts on Privacy and Security. Incite 6/2/2010: Smuggler’s Blues. On “Security engineering: broken promises”. FireStarter: In Search of… Solutions. Favorite Outside Posts Rich: Inside the heart of a QSA. As much as we complain about bad PCI assessors are, the good ones often find themselves struggling with organizations that only want a rubber stamp. The bad news is there are very few jobs that don’t end up being driven by rote over time. That’s why I like security – it is one of the few careers with options to refresh yourself every few years.. Pepper: Android rootkit is just a phone call away. It’s actually triggered by a call, not installed by one, but still very cool – in a bad way. Adrian Lane: Detecting malicious content in shell code. Mike Rothman: Windows, Mac, or Linux: It’s Not the OS, It’s the User The weakest link in the chain remains the user. But we can’t kill them, so we need to deal with them. Project Quant Posts DB Quant: Secure Metrics, Part 1, Patch. NSO Quant: Monitor Process Map. DB Quant: Discovery Metrics, Part 4, Access and Authorization. DB Quant: Discovery and Assessment Metrics, Part 3, Assess Vulnerabilities and Configuration. 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 MS plans 10 new patches. Sharepoint and IE are the big ones. Cyber Thieves Rob Treasury Credit Union. Ukrainian arrested in India on TJX data-theft charges These incidents go on for years, rather than days or even months. iPhone PIN code worthless Rich published on this a long time ago, and while it was a known flaw, the automounting on Ubuntu is new and disturbing. Previously it looked like you had to jailbreak the iPhone first. Viral clickjacking ‘Like’ worm hits Facebook users. ATM Skimmers. Another installment from Brian Krebs on ATM Skimmers. 30 vs. 150,000 Adam teaches Applied Risk Assessment 101. Trojan targets Anti-Phish software. 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 Michael O’Keefe, in response to Code Re-engineering. Re-engineering can work, Spolsky inadvertently provides a great example of that, and proves himself wrong. I guess that’s the downside to blogs, and trying to paint things in a black or white manner. He had some good points, one was that when Netscape open sourced the code, it wasn’t working, so the project got off to a slow start. But the success of Mozilla (complete rewrite of Netscape) has since proved him wrong. Once Bill Gates realized the importance of the internet, and licensed the code from Spyglass (I think) for IE, MS started including it on every new release of Windows. In this typical fashion, they slowly whittled away at Netscape’s market share, so Netscape had to innovate. The existing code base was

Given the craziness of my schedule, I don’t see a lot of movies in the theater anymore. Hard to justify the cost of a babysitter for a movie, when we can sit in the house and watch movies (thanks, Uncle Netflix!). But the Boss does take the kids to the movies because it’s a good activity, burns up a couple hours (especially in the purgatory period between the end of school and beginning of camp), and most of the entertainment is pretty good. Though it does give me some angst to see two credit card receipts from every outing. The first is the tickets, and that’s OK. The movie studios pay lots to produce these fantasies, so I’m willing to pay for the content. It’s the second transaction, from the snack bar, that makes me nuts. My snack bar tab is usually as much as the tickets. Each kid needs a drink, and some kind of candy and possibly popcorn. All super-sized, of course. And it’s not even the fact that we want to get super sizes of anything. That’s the only option. You can pay $4 for a monstrous soda, which they call small. Or $4.25 for something even bigger. If you can part with $4.50, then you get enough pop to keep a village thirst-free for a month. And don’t get me started on the popcorn. First of all, I know it’s nutritionally terrible. They may use different oil now, but in the portions they sell, you could again feed a village. But don’t think the movie theaters aren’t looking out for you. If you get the super-duper size, you get free refills of both popcorn and soda. Of course, you’d need to be the size of an elephant to knock down more than two gallons of soda and a feedbag of popcorn, but at least they are giving something back. So we’re been trying something a bit different, born of necessity. The Boss can’t eat the movie popcorn due to some food allergies, so she smuggles in her own popcorn. And usually a bottle of water. You know what? It works. It’s not like the 14 year old ticket attendant is going to give me a hard time. I know, it’s smuggling, but I don’t feel guilty at all. I’d be surprised if the monstrous soda cost the theater more than a quarter, but they charge $4. So I’m not going to feel bad about sneaking in a small bag Raisinettes or Goobers with a Diet Coke. I’ll chalk it up to a healthy lifestyle. Reasonable portions and lighter on my wallet. Sounds like a win-win to me. – Mike. Photo credits: “Movie Night Party” originally uploaded by Kid’s Birthday Parties Incite 4 U Follow the dollar, not the SLA – Great post by Justin James discussing the reality of service level agreements (SLAs). I know I’ve advised many clients to dig in and get preferential SLAs to ensure they get what they contract for, but ultimately it may be cheaper for the service provider to violate the SLA (and pay the fine) than it is to meet the agreement. I remember telling the stories of HIPAA compliance, and the reality that some health care organizations faced millions of dollars of investment to get compliant. But the fines were five figures. Guess what they chose to do. Yes, Bob, the answer was roll the dice. Same goes for SLAs, so there are a couple lessons here. 1) Try to get teeth in your SLA. The service provider will follow the money, so if the fine costs them more, they’ll do the right thing. 2) Have a Plan B. Contingencies and containment plans are critical, and this is just another reason why. When considering services, you cannot make the assumption that the service provider will be acting in your best interest. Unless your best interest is aligned with their best interest. Which is the reality of ‘cloud’. – MR It just doesn’t matter – I’m always pretty skeptical of poorly sourced articles on the Internet, which is why the Financial Times report of Google ditching Microsoft Windows should be taken with a grain of salt. While I am sometimes critical of Google, I can’t imagine they would really be this stupid. First of all, at least some of the attacks they suffered from China were against old versions of Windows – as in Internet Explorer 6, which even isolated troops of Antarctic chimpanzees know not to touch. Then, unless you are running some of the more-obscure ultra-secure Unix variants, no version of OS X or Linux can stand up to a targeted attacker with the resources of a nation state. Now, if they want some diversity, that’s a different story, but the latest versions of Windows are far more hardened than most of the alternatives – even my little Cupertino-based favorite.– RM Hack yourself, even if it’s unpopular… – I’ve been talking about security assurance for years. Basically this is trying to break your own defenses and seeing where the exposures are, by any means necessary. That means using live exploits (with care) and/or leveraging social engineering tactics. But when I read stories like this one from Steve Stasiukonis where there are leaks, and the tests are compromised, or the employees actually initiate legal action against the company and pen tester, I can only shake my head. Just to reiterate” the bad guys don’t send message to the chairman saying “I IZ IN YER FILEZ, READIN YER STUFFS!” They don’t worry about whether their tactics are “illegal human experiments,” they just rob you blind and pwn your systems. Yes, it may take some political fandango to get the right folks on board with the tests, but the alternative is to clean up the mess later. – MR Walk the walk – A while back we were talking about getting started in security over at The Network Security Podcast, and one bit of consensus was that you should try

I was catching up on my reading today, and this post by Richard Bejtlich reminded me of the tension we sometimes see between security and privacy. Richard represents the perspective of a Fortune 5 security operator who is tasked with securing customer information and intellectual property, while facing a myriad of international privacy laws – some of which force us to reduce security for the sake of privacy (read the comments). I’ve always thought of privacy from a slightly different perspective. Privacy traditionally falls into two categories: The right to be left alone (just ask any teenage boy in the bathroom). The right to control what people know about you. According to the dictionary on my Mac, privacy is: the state or condition of being free from being observed or disturbed by other people : she returned to the privacy of her own home. My understanding is that it is only fairly recently that we’ve added personal information into the mix. We are also in the midst of a massive upheaval of social norms enabled by technology and the distribution and collection of information that changes the scope of “free from being observed.” Thus, in the information age, privacy is now becoming as much about controlling information about us as it is about physical privacy. Now let’s mix in security, which I consider a mechanism to enforce privacy – at least in this context. If we think about our interactions with everyone from businesses and governments to other individuals, privacy consists of three components: Intent: What I intend to do with the information you give me, whether it is the contents of a personal conversation or a business transaction. Communication: What I tell you I intend to do with said information. Capability: My ability to maintain and enforce the social (or written) contract defined by my intent and communications. Thus I see security as a mechanism of capability. The role of “security” is to maintain whatever degree of protection around personal information the organization intends and communicates through their privacy policy – which might be the best or worst in the world, but the role of security is to best enforce that policy, whatever it is. Companies tend to get into trouble either when they fail to meet their stated policies (due to business or technical/security reasons), or when their intent is incompatible with their legal requirements. This is how I define privacy on the collection side – but it has nothing to do with protecting or managing your own information, nor does it address the larger societal issues such as changing ownership of information, changing social mores, changes in personal comfort over time, or collection of information in non-contracted situations (e.g., public movement). The real question then emerges: is privacy even possible? As Adam Shostack noted, our perceptions of privacy change over time. What I deem acceptable to share today will change tomorrow. But once information is shared, it is nearly impossible to retract. Privacy decisions are permanent, no matter how we may feel about them later. There is no perfect security, but once private information becomes public, it is public forever. Isolated data will be aggregated and correlated. It used to require herculean efforts to research and collect public records on an individual. Now they are for sale. Cheap. Online. To anyone. We share information with everyone, from online retailers, to social networking sites, to the blogs we read. There is no way all of these disparate organizations can effectively protect all our information, even if we wanted them to. Privacy decisions and failures are sticky. I believe we are in the midst of a vast change in our how society values and defines privacy – one that will evolve over years. This doesn’t mean there’s no such thing as privacy, but does mean that today we do lack consistent mechanisms to control what others know about us. Without perfect security there cannot be complete privacy, and there is no such thing as perfect security. Privacy isn’t dead, but it is most definitely changing in ways we cannot fully predict. My personal strategy is to compartmentalize and use a diverse set of tools and services, limiting how much any single one collects on me. It’s probably little more than privacy theater, but it helps me get through the day as I stroll toward an uncertain future. Share:

Continuing our discussion of core SIEM and Log Management technology, we now move into event correlation. This capability was the holy grail that drove most investment in early SIEM products, and probably the security technology creating the most consistent disappointment amongst its users. But ultimately the ability to make sense of the wide variety of data streams, and use them to figure out what is under attack or compromised, is essential to any security practice. This means that despite the disappointments, there will continue to be plenty of interest in correlation moving forward. Correlation Defining correlation is akin to kicking a hornet’s nest. It immediately triggers agitated debates because there are several published definitions and every expert has their favorite. As usual, we need to revisit the definitions and level-set, not to create controversy (though that tends to happen), but to make things easy to understand. As we search for a pragmatic definition, we need to simplify concepts to make subjects understandable to a wider audience at the expense of precision. We understand our community is not a bunch of shrinking violets, so we welcome your comments and suggestions to make our research more relevant. Let’s get back to the end-user problem driving SIEM and log management. Ultimately the goal of this technology is to interpret security-related data to improve security, increase efficiency, and/or document security controls. If a single file contained all the information required for security analysis, we would not bother with the collection and association of events from multiple sources. The truth is that each log or event contains a piece of information, which forms part of the puzzle, but lacks context necessary to analyze the big picture. In order to make meaningful decisions about what is going on with our applications and within our network, we need to combine events from different sources. Which events we want, and what pieces of data from those events we need, vary based on the problem we are trying to solve. So what is correlation? Correlation is the act of linking multiple events together to detect strange behavior. It is the association of different but related events to provide broader context than a single event can provide. Keep in mind that we are using a broad definition of ‘event’ because as the breadth of analysis increases, data may expand beyond traditional events. Seems pretty simple, eh? Let’s look at an example of how correlation can help achieve one of our key use cases: increasing the efficiency of the security team. In this case an analyst gets events from multiple locations and device types (and/or applications), and is expected to figure out whether there is an issue. The attacker might first scan the perimeter and then target an externally facing web server with a series of known exploits. Upon successfully compromising the web server, the attacker sets up a new user account and start scanning internally to find more exploitable hosts. The data is available to catch this attack, but not in a single place. The firewalls see the initial scans. The IDS/IPS sees the series of exploits. And the user directory sees the new account on the compromised server. The objective of correlation is to see all these events come through and recognize that the server has been compromised and needs immediate attention. Easy in concept, very hard in practice. Historically, the ability to do near real time analysis and event correlation was one of the ways SIEM differed from log management, although the lines continue to blur. Most of the steps we have discussed so far (collecting data, then aggregating and normalizing it) help isolate the attributes that link events together to make correlation possible. Once data is in manageable form we apply rules to detect attacks and misuse. These rules are comprised of the granular criteria (e.g., specific router, user account, time, etc.), and determine if a series of events reaches a threshold requiring corrective action. But the devil is in the details. The technology implements correlation as a linear series of events. Each comparison may be a simple case of “if X=Y, then” do something else, but we may need to string several of these comparisons together. Second, note that correlation is built on rules for known attack patterns. This means we need some idea of what we are looking for to create the correlation rules. We have to understand attack patterns or elements of a compliance requirement in order to determine which device and event types should be linked. Third, we have to factor in the time factor, because events do not happen simultaneously, so there is a window of time within which events are likely to be related. Finally the effectiveness of correlation also depends on the quality of data collection, normalization, and tagging or indexing of information to feed the correlation rules. Development of rules takes time and understanding, as well as ongoing maintenance and tuning. Sure, your vendor will provide out-of-the-box policies to help get you started, but expect to invest significant time into tweaking existing rules for your environment, and writing new policies for security and compliance to keep pace with the very dynamic security environment. Further complicating matters: more rules and more potentially-linked events to consider increase computational load exponentially. There is a careful balancing act to be performed between the number of policies to implement, the accuracy of the results, and the throughput of the system. These topics may not immediately seem orthogonal, but generic rules detect more threats at a cost of more false positives. The more specific the rule, and the more precisely tailored to find specific threats, the less it will find new problems. This is the difficulty in getting correlation working effectively in most environments. As described in the Network Security Fundamentals series, it’s important to define clear goals for any correlation effort and stay focused on them. Trying to boil the ocean always yields disappointing results. Alerting Once events are correlated, analysis performed, and weirdness

A holy grail of technology marketing is to define a product category. Back in the olden days of 1998, it was all about establishing a new category with interesting technology and going public, usually on nothing more than a crapload of VC money and a few million eyeballs. Then everything changed. The bubble popped, money dried up, and all those companies selling new products in new categories went bust. IT shops became very risk averse – only spending money on established technologies. But that created a problem, in that analysts had to sell more tetragon reports, which requires new product categories. My annoyance with these product categories hit a fever pitch last week when LogLogic announced a price decrease on their SEM (security event management) technology. Huh? Seems they dusted off the SEM acronym after years on the shelf. I thought Gartner had decreed that it was SIEM (security information and event management) when it got too confusing between the folks who did SEM and SIM (security information management) – all really selling the same stuff. Furthermore, log management is now part of that deal. Do they dare argue with the great all-knowing oracles in Stamford? Not that this expanded category definition is controversial. We’ve even posted that log management or SIEM isn’t a stand-alone market – rather it’s the underlying storage platform for a number of applications for security and ops professionals. The lesson most of us forget is that end users don’t care what you call the technology, as long as you solve their problems. Maybe the project is compliance automation or incident investigation. SIEM/Log Management can be used for both. IT-GRC solutions can fit into the first bucket, while forensic toolkits fit into the latter. Which of course confuses the hell out of most end users. What do they buy? And don’t all the vendors say they do everything anyway? The security industry – along with the rest of technology – focuses on products, not solutions. It’s about the latest flashing light in the new version of the magic box. Sure, most of the enterprise companies send their folks to solution selling school. Most tech company websites have a “solution” area, but in reality it’s always an afterthought. Let’s consider the NAC (network access control) market as another example. Lots of folks think Cisco killed the NAC market by making big promises and not delivering. But ultimately, end users didn’t care about NAC – they cared about endpoint assessment and controlling guest access, and they solved those problems through other means. Again, end users need to solve problems. They want answers and solutions, but they get a steady diet of features and spiels on why one box is better than the competitors. They get answers to questions they don’t ask. No wonder most end users turn off their phones and don’t respond to email. Vendors spin their wheels talking about product category leadership. Who cares? Actually, Rich reminded me that the procurement people seem to care. We all know how hard it is to get a vendor in the wrong quadrant (or heaven forbid no quadrant at all) through the procurement gauntlet. Although the users are also to blame for accepting this behavior, and the dumb and lazy ones even like it. They wait for a vendor to come in and tell them what’s important, as opposed to figuring out what problem needs to be solved. From where I sit, the buying dynamic is borked, although it’s probably just as screwy in other sectors. So what to do? That’s a good question, and I’d love your opinion. Should vendors run the risk of not knowing where they fit by not identifying with a set of product categories – and instead focus on solutions and customer problems? Should users stop sending out RFPs for SIEM/Log Management, when what they are really buying is compliance automation? Can vendors stop reacting to competitive speeds and feeds? Can users actually think more strategically, rather than whether to embrace the latest shiny upgrade from the default vendor? I guess what I’m asking is whether it’s possible to change the buying dynamic. Or should I just quiet down, accept the way the game is played, and try to like it? Share:

Recently Michael Zalewski posted a rant about the state of security engineering in Security engineering: broken promises. I posted my initial response to this on Twitter: “Great explanation of the issue, zero thoughts on solutions. Bored now.” I still stand behind that response. As a manager, problems without potential solutions are useless to me. The solutions don’t need to be deep technical solutions – sometimes the solution is to monitor or audit. Sometimes the solution is to do nothing, accept the risk, and make a note of it in case it comes up in conversation or an audit. But as I’ve mulled over this post over the last two weeks, there is more going on here. There seems to be a prevalent attitude among security practitioners in general, and researchers in particular, that if they can break something it’s completely useless. There’s an old Yiddish saying that loosely translates to: “To a thief there is no lock.” We’re never going to have perfect security, so picking on something for being imperfect is just disingenuous and grandstanding. We need to be asking ourselves a pragmatic question: Does this technology or process make things better? Just about any researcher will tell you that Microsoft’s SDL has made their lives much harder, and they have to work a lot more to break stuff. Is it perfect? No, of course not! But is it a lot better then it used to be for all involved (except the researchers Microsoft created the SDL to impede)? You betcha. Are CWE and CVSS perfect? No! Were they intended to be? No! But again, they’re a lot better than what we had before. Can we improve them? Yes, CVSS continues to go through revisions and will get better. As will the Risk Management frameworks. So really, while bitching is fun and all, if you’re not offering improvements, you’re just making things worse. Share:

We get a lot of requests to sponsor this blog. We got several this week. Not just the spammy “Please link with us,” or “Host our content and make BIG $$$” stuff. And not the PR junk that says “We are absolutely positive your readers would just love to hear what XYZ product manager thinks about data breaches,” or “We just released 7.2.2.4 version of our product, where we changed the order of the tabs in our web interface!” Yeah, we get fascinating stuff like that too. Daily. But that’s not what I am talking about. I am talking about really nice, personalized notes from vendors and others interested in supporting the Securosis site. They like what we do, they like that we are trying to shake things up a bit, and they like the fact that we are honest in our opinions. So they write really nice notes, and they ask if they can give us money to support what we do. To which we rather brusquely say, “No”. We don’t actually enjoy doing that. In fact, that would be easy money, and we like as much easy money as we can get. More easy money is always better than less. But we do not accept either advertising on the site or sponsorship because, frankly, we can’t. We just cannot have the freedom to do what we do, or promote security in the way we think best, if we accept payments from vendors for the blog. It’s like the classic trade-off in running your own business: sacrifice of security for the freedom to do things your own way. We don’t say “No,” to satisfy some sadistic desire on our part to be harsh. We do it because we want the independence to write what we want, the way we want. Security is such a freakin’ red-headed stepchild that we have to push pretty hard to get companies, vendors, and end users to do the right thing. We are sometimes quite emphatic to knock someone off the rhythm of that PowerPoint presentation they have delivered a hundred times, somehow without ever critically examining its content or message. If we don’t they will keep yakking on and on about how they address “Advanced Persistant Threats.” Sometimes we spotlight the lack of critical reasoning on a customer’s part to expose the fact that they are driven by politics without a real plan for securing their environment. We do accept sponsorship of events and white papers, but only after the content has gone through community review and everyone has had a chance to contribute. Many vendors and a handful of end-users who talk with us on the phone know we can be pretty harsh at times, and they still ask if they economically support our research. And we still say, “No”. But we appreciate the interest, and we thank you all for for participating in our work. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s Dark Reading article on What Oracle Gets In The Secerno Buy. Rich quoted in a Dark Reading article on database passwords. Did we mention Rich was on NPR Science Friday? The full transcript is up. Unfortunately – since it has all the “you knows” and “ums” in it. Adrian’s DAM Deployment Issues to Avoid launched this week. Rich on the Network Security Podcast. Adrian quoted in CRN Tech on database security. Mike quoted in SC Magazine. Favorite Securosis Posts Rich: Code Re-engineering. This applies to so much more than code. I’ve been on everything from mountain rescues to woodworking projects where the hardest decision is to stop patching and nuke it from orbit. We are not mentally comfortable throwing away hours, days, or years of work; and the ability to step back, analyze, and start over is rare in any society. Mike Rothman: Code Re-engineering. Adrian shows his development kung fu. He should get pissed off more often. David Mortman: Gaming the Tetragon. Adrian Lane: The Secerno Technology. Just because you need to understand what this is now that Oracle has their hands on it. Other Securosis Posts Understanding and Selecting SIEM/LM: Aggregation, Normalization, and Enrichment. Quick Wins with DLP Presentation. Incite 5/26/2010: Funeral for a Friend. Understanding and Selecting SIEM/LM: Data Collection. A Phish Called Tabby. Thoughts on Diversity and False Diversity. FireStarter: The Only Value/Loss Metric That Matters. The Laziest Phisher in the World. Favorite Outside Posts Rich: Data Loss Prevention and Enterprise Rights Management; Complimentary or alternative? For 6 months or so I’ve been getting a lot of “which is better, DRM or DLP?” questions. The problem is that they are not alternative technologies, but complementary. The trick is to figure out which one might be more appropriate to implement first, not which can replace the other. Besides, I think they are on the path to complete convergence in the long term, and we already have early samples of combined solutions. Adrian: Bejtlich’s Forget Pre-Incident Cost, How Much Did Your Last Incident Cost? Almost picked Rich’s post The Only Value/Loss Metric That Matters for my internal fave of the week, but this is like a two-fer. Mike Rothman: Google Secure Search and Security Overkill. Boaz makes the point that not all security is worth it. Playing at a security theater near you…. David Mortman: Privacy Theater. Project Quant Posts DB Quant: Discovery And Assessment Metrics (Part 2) Identify Apps. DB Quant: Discovery And Assessment Metrics (Part 1) Enumerate Databases. DB Quant: Planning Metrics (Part 4). Research Reports and Presentations Understanding and Selecting a Database Encryption or Tokenization Solution. Low Hanging Fruit: Quick Wins with Data Loss Prevention. Report: Database Assessment. Top News and Posts TabNabbing was the big news this week. Three indicted on $100M Rogue Software Scam. Mozilla Plugin Check via Brian Krebs. Supposed Vuln in iPhone Encryption. Oopsie. Why does the IRS never have a problem like this? Your Privacy in Their Hands via LiquidMatrix. Can you have a PCI Compliant Virtual Site? Good question. New School blog announces The

When I was abroad on vacation recently, the conversation got to the relative cost of petrol (yes, gasoline) in the States versus pretty much everywhere else. For those of you who haven’t travelled much, fuel tends to be 70-80% more expensive elsewhere. Why is that? It comes down to the fact that the US Government bears many of real costs of providing a sufficient stream of petroleum. Those look like military, diplomatic, and other types of spending in the Middle East to keep the oil flowing. I’m not going to descend into either politics or energy dynamics here, but suffice it to say we’d be investing a crapload more money in alternative energy if US consumers had to directly bear the full brunt of what it costs to pull oil out of the Middle East. With that thought in the back of my mind, I checked out one of Bejtlich’s posts last weekend which talked about the R&D costs of the bad guys. Basically these folks run businesses like anyone else. They have to invest in their ‘product’, which is finding new vulnerabilities and exploiting them. They also have to invest in “customer service,” which is basically staying invisible once they are inside to avoid detection. And these costs are significant, but compared to the magnitude of the ‘revenue’ side of their equation, I’m sure they are happy to make the investment. Cyber-fraud is big business. But what about other hidden costs of providing security? We had a great discussion on Monday with the FireStarter talking about value/loss metrics, but do these risk models take into account some of the costs we don’t necessarily see as part of security? Like our network traffic. How much bandwidth is wasted on reconnaissance traffic looking for holes in our perimeters? What about the amount of your inbound pipe congested with spam, which you need to analyze and then drop. One of the key reasons anti-spam services took off is because the bandwidth demand of spam was transferred to the service provider. What would we do differently if we had to allocate those hidden costs to the security team? I know, at the end of the day it’s all just overhead, but what if? Would it change our behavior or our security architectures? I suspect we’d focus much more on providing clean pipes and having more of our security done in the cloud, removing some of these hidden costs from our IT stack. That makes economic sense, and we all know most of what we do ultimately is driven by economics. How about the costs of cleaning up an incident? Yes, there are some security costs in there from the standpoint of investigation and forensics, but depending on the nature of the attack there will be legal and HR resources required, which usually don’t make it into the incident post-mortem. Or what about the opportunity cost of 1,000 folks losing their authentication tokens and being locked out of the network? Or the time it takes a knowledge worker to jump through hoops to get around aggressive web filtering rules? Or the cost of false positives on the IPS that block legitimate business traffic and break critical applications? We know how big the security budget is, but we don’t have a firm grasp of what security really costs our businesses. If we did, what would we do differently? I don’t necessarily have an answer, but it’s an interesting question. As we head into Memorial Day weekend here in the US, we need to remember obviously, all the soldiers who give all. But we also need to remember the ripple effect of every action and reaction to the bad guys. Every time I go through a TSA checkpoint in an airport, I’m painfully aware of the billions spent each month around the world to protect air travel, regardless of whether terrorists will ever attack air travel again. I guess the same analogy can be used with security. Regardless of whether you’re actually being attacked, the costs of being secure add up. Score another one for the bad guys. Share:

In the last post on Data Collection we introduced the complicated process of gathering data. Now we need to understand how to put it into a manageable form for analysis, reporting, and long-term storage for forensics. Aggregation SIEM platforms collect data from thousands of different sources because these events provide the data we need to analyze the health and security of our environment. In order to get a broad end-to-end view, we need to consolidate what we collect onto a single platform. Aggregation is the process of moving data and log files from disparate sources into a common repository. Collected data is placed into a homogenous data store – typically purpose-built flat file repositories or relational databases – where analysis, reporting, and forensics occur; and archival policies are applied. The process of aggregation – compiling these dissimilar event feeds into a common repository – is fundamental to Log Management and most SIEM platforms. Data aggregation can be performed by sending data directly into the SIEM/LM platform (which may be deployed in multiple tiers), or an intermediary host can collect log data from the source and periodically move it into the SIEM system. Aggregation is critical because we need to manage data in a consistent fashion: security, retention, and archive policies must be systematically applied. Perhaps most importantly, having all the data on a common platform allows for event correlation and data analysis, which are key to addressing the use cases we have described. There are some downsides to aggregating data onto a common platform. The first is scale: analysis becomes exponentially harder as the data set grows. Centralized collection means huge data stores, greatly increasing the computational burden on the SIEM/LM platform. Technical architectures can help scale, but ultimately these systems require significant horsepower to handle an enterprise’s data. Systems that utilize central filtering and retention policies require all data to be moved and stored – typically multiple times – increasing the burden on the network. Some systems scale using distributed processing, where filtering and analysis occur outside the central repository, typically at the distributed data collection point. This reduces the compute burden on the central server and allows processing to occur on smaller, more manageable data sets. It does require that policies, along with the code to process them, be distributed and kept current throughout the network. Distributed agent processes are a handy way to “divide and conquer”, but increase IT administration requirements. This strategy also adds a computational burden o the data collection points, degrading their performance and potentially slowing enough to drop incoming data. Data Normalization If the process of aggregation is to merge dissimilar event feeds into one common platform, normalization takes it one step further by reducing the records to just common event attributes. As we mentioned in the data collection post, most data sources collect exactly the same base event attributes: time, user, operation, network address, and so on. Facilities like syslog not only group the common attributes, but provide means to collect supplementary information that does not fit the basic template. Normalization is where known data attributes are fed into a generic template, and anything that doesn’t fit is simply omitted from the normalized event log. After all, to analyze we want to compare apple to apples, so we throw away an oranges for the sake of simplicity. Depending upon the SIEM or Log Management vendor, the original non-normalized records may be kept in a separate repository for forensics purposes prior to later archival or deletion, or they may simply be discarded. In practice, discarding original data is a bad idea, since the full records are required for any kind of legal enforcement. Thus, most products keep the raw event logs for a user-specified period prior to archival. In some cases, the SIEM platform keeps a link to the original event in the normalized event log which provides ‘drill-down’ capability to easily reference extra information collected from the device. Normalization allows for predicable and consistent storage for all records, and indexes these records for fast searching and sorting, which is key when battling the clock in investigating an incident. Additionally, normalization allows for basic and consistent reporting and analysis to be performed on every event regardless of the data source. When the attributes are consistent, event correlation and analysis – which we will discuss in our next post – are far easier. Technically normalization is no longer a requirement on current platforms. Normalization was a necessity in the early days of SIEM, when storage and compute power were expensive commodities, and SIEM platforms used relational database management systems for back-end data management. Advances in indexing and searching unstructured data repositories now make it feasible to store full source data, retaining original data, and eliminating normalization overhead. Enriching the Future In reality, we are seeing a number of platforms doing data enrichment, adding supplemental information (like geo-location, transaction numbers, application data, etc.) to logs and events to enhance analysis and reporting. Enabled by cheap storage and Moore’s Law, and driven by ever-increasing demand to collect more information to support security and compliance efforts, we expect more platforms to increase enrichment. Data enrichment requires a highly scalable technical architecture, purpose-built for multi-factor analysis and scale, making tomorrow’s SIEM/LM platforms look very similar to current business intelligence platforms. But that just scratches the surface in terms of enrichment, because data from the analysis can also be added to the records. Examples include identity matching across multiple services or devices, behavioral detection, transaction IDs, and even rudimentary content analysis. It is somewhat like having the system take notes and extrapolate additional meaning from the raw data, making the original record more complete and useful. This is a new concept for SIEM, so the enrichment will ultimately encompass is anyone’s guess. But as the core functions of SIEM have standardized, we expect vendors to introduce new ways to derive additional value from the sea of data they collect. Other Posts in Understanding and Selecting SIEM/LM Introduction. Use Cases,