Research

Now that you thoroughly understand the use cases and technology underpinning of SIEM and Log Management platforms, it’s time to flex your knowledge and actually buy one. As with most of our research at Securosis, we favor mapping out a very detailed process, and leaving you to decide which steps make sense in your situation. So we don’t expect every organization to go through every step in this process. Figure out what will work for your organization and do that. Define Needs Before you start looking at any tools you need to understand why you might need a SIEM/LM; how you plan on using it; and the business processes around management, policy creation, and incident handling. You can (and should) consult our descriptions of the use cases (Part 1 & Part 2) to really understand what problem you are trying to solve and why. If you don’t do this, your project is doomed to fail. And that’s all we’ll say about that. Create a selection committee: Yeah, we hate the term ‘committee’ as well, but the reality is a decision to acquire SIEM – along with the business issues it is expected to address – comes from multiple groups. SIEM/LM touches not only the security team, but also any risk management, audit, compliance, and operational teams as well. So it’s best to get someone from each of these teams (to the degree they exist in your organization) on the committee. Basically you want to ensure that anyone who could say no, or subvert the selection at the 11th hour, is on board from the beginning. Yes, that involves playing the game, but if you want to get the process over the finish line, you’ll do what you need to. Define the systems and platforms to monitor: Are you looking to monitor just security devices or also general-purpose network equipment, databases, applications, VMs and/or anything else? In this stage, detail the monitoring scope and the technical specifics of the platforms involved. You’ll use this list to determine technical requirements and prioritize features and platform support later in the selection process. Remember that your needs will grow over time and you may be limited by budget during the initial procurement, so break the list into a group of high priority things with immediate needs, and other groups of other data sources you may want to monitor later. Determine security and/or compliance requirements: The committee really helps with collecting requirements, as well as mapping out reports and alerts. The implementation will involve some level of correlation, analysis, reporting, and integration– which needs to be defined ahead of time. Obviously that can and will change over time, but give this some thought because these requirements will drive your selection. You don’t need to buy a Rolls-Royce if a Nissan Sentra would solve your requirements. In this step map your security and compliance needs to the platforms and systems from the previous step, which helps determine everything from technical requirements to process workflow. Outline process workflow, forensics, and reporting requirements: SIEM/LM workflow is highly dependent on use case. When used in a security context, the security team monitors and manages events, and will have an escalation process to verify attacks and remediate. When used to improve efficiency, the key is to leverage as many rules and alerts as possible, which is really a security team function. A forensics use case will involve the investigative/incident team. In most cases, audit, legal, and/or compliance will have at least some sort of reporting role, since compliance is typically the funding source for the project. Since different SIEM/LM platforms have different strengths and weaknesses in terms of management interfaces, reporting, forensics, and internal workflow, knowing your process before defining technical requirements can prevent headaches down the road. Product versus managed service – Are you open to using a managed service for SIEM/LM? Do you have the internal resources/expertise to manage (and tune) the platform? Now is the time to decide whether a service is an option, since that impacts the rest of the selection process. By the end of this phase you should have defined key stakeholders, convened a selection team, prioritized the systems to protect, determined protection requirements, and roughed out workflow needs. Formalize Requirements This phase can be performed by a smaller team working under the mandate of the selection committee. Here the generic needs determined in phase 1 are translated into specific technical features, and any additional requirements are considered. This is the time to come up with criteria for collection and aggregation, additional infrastructure integration, data storage/archival, deployment architecture, management and identity integration, and so on. You may need to dig into what information your devices provide to ensure you can collect the necessary data to reliably feed the SIEM platform. You can always refine these requirements as you proceed through the selection process and get a better feel for how the products work. At the conclusion of this stage you develop a formal RFI (Request For Information) to release to vendors, and a rough RFP (Request For Proposals) that you’ll clean up and formally issue in the evaluation phase. Evaluate Products All the SIEM/LM vendors tell similar stories, which makes it difficult to cut through the marketing and figure out whether a product really meets your needs. The following steps should minimize your risk and help you feel confident in your final decision: Issue the RFI: Larger organizations should issue an RFI though established channels and contact a few leading SIEM/LM vendors directly. If you’re a smaller organization, start by sending your RFI to a trusted VAR and email a few SIEM/LM vendors which seem appropriate for your organization. Define the short list: Before bringing anyone in, match any materials from the vendor or other sources to your RFI and draft RFP. Your goal is to build a short list of 3 products which can satisfy most of your needs. You should also use outside research sources and product comparisons. Understand that you’ll likely

Justifying an investment in tokenization is actually two separate steps – first justifying an investment to protect the data, and then choosing to use tokenization. Covering all the justifications for protecting data is beyond the scope of this series, but a few common drivers are typical: Compliance requirements Reducing compliance costs Threat protection Risk mitigation We’ve published a full model (and worksheet) on this problem in our paper The Business Justification for Data Security. Once you’ve decided to protect the data, the next step is to pick the best method. Tokenization is designed to solve a very narrow but pervasive and critical problem: protecting discreet data fields within applications, databases, storage, and across networks. The most common use for tokenization is to protect sensitive key identifiers, such as credit card numbers, Social Security Numbers, and account numbers. Less commonly, we also see tokenization used to protect full customer/employee/personal records. The difference between the two (which we’ll delve into more in our architectural discussion) is that in the first case the tokenization server only stores the token and the sensitive field, while in the second case it includes additional data, such as names and addresses. Reasons to select tokenization include: Reduction compliance scope and costs: Since tokenization completely replaces a sensitive value with a random value, systems that use the token instead of the real value are often exempt from audits/assessments that regulations require for the original sensitive data. For example, if you replace a credit card number in your application environment with tokens, the systems using the tokens may be excluded from your PCI assessment – reducing the assessment scope and cost. Reduction of application changes: Tokenization is often used to protect sensitive data within legacy application environments where we might previously have used encryption. Tokenization allows us to protect the sensitive value with an analogue using the exact same format, which can minimize application changes. For example, encrypting a Social Security Number involves not only managing the encryption, but changing everything from form field logic to database field format requirements. Many of these changes can be avoided with tokenization, so long as the token formats and sizes match the original data. Reduction of data exposure: A key advantage of tokenization is that it requires data consolidation. Sensitive values are only stored on the tokenization server(s), where they are encrypted and highly protected. This reduces exposure over traditional encryption deployments, where cryptographic access to sensitive data tends to show up in many locations. Masking by default: Since the token value is random, it also effectively functions as a data mask. You don’t need to worry about adding masking to applications, since the real value is never exposed (the exception being where even the token value could lead to misuse within your environment). Tokenization solutions do not offer as many formatting options to preserve value for reporting and analytics, but fully tokenized solutions provide greater security and less opportunity for data leakage or reverse engineering. For the most part, the primary reason organizations select tokenization over alternatives is cost reduction: reduced costs for application changes, followed by reduced audit/assessment scope. We also see organizations select tokenization when they need to update security for large enterprise applications – as long as you have to make a lot of changes, you might as well reduce potential data exposure and minimize the need for encryption at the same time. Understanding and Selecting a Tokenization Solution: Part 1, Introduction Share:

I spent some time on the road this week, and it was great to see some old friends, meet some new ones, come up to speed on some topics, and more than anything take some time to listen. With my head full of dancing fairies relative to what’s really going on out there, I was interested when I came across Jack Freund’s post on the RiskAnalysis blog called “Executives are not Stupid.” Jack leads off the discussion by mentioned that “You don’t fall into a job to run a company or a line of business.” Actually in my experience, continually validated by my primary research, many executives are in over their heads. The Peter Principle is not only alive and well, it gets in the way of the security professional’s charter on a daily basis. Come on, don’t make like you’ve never asked yourself what kind of pictures said executive has on the CEO to keep falling upward. You know you have, and you are probably right. Success in corporate life isn’t just restricted to the talented, that’s for sure. The lore has been known for years that to be good at security you have to think like a hacker. All that really means is that you have to understand the attacker’s motivations, get familiar with the tools they use, and use that knowledge to discover the path of least resistance (which tends to be the most significant attack vector). When we recommend that you systematically hack yourself, this is really to familiarize yourself with what the attacker sees. The same goes for dealing with senior management. A lot of folks just get grumpy when a decision doesn’t go their way. They grumble about how senior management “doesn’t get it,” but in reality it’s a failure on our part to anticipate the (often obvious) reaction of the senior team. Most executives are, frankly, predictable. They act in their own best interests, always. And that means if you want to get anything done, you have to convince the executive that going down the path your suggest is in their best interest. I know, this clearly involves political machinations and that is likely deplorable to many of you. It’s not my favorite thing to do, which is why I work with Rich and Adrian. But if you want the big title (or even a little title), part of that is playing the game. So you need to plan for success. That means before you pitch a senior exec on your pet project, you need to actively plan a strategy for lining up support. It’s not that hard, but it doesn’t happen by itself. You have to sit down and understand the playing field. Start by asking yourself two questions, but you need to answer as the executive(s) rather than as yourself. And no, the questions do not include which new BMW you want or which Four Seasons you will visit on holiday. How will this make my life better? You need to have a crisp understanding of why it’s in this executive’s best interest to support your project, and that usually gets down to two things: more money or making him/her look good. If you can position your project for either of these, you have a chance. What is the risk? There is no risk without reward, so you need to really consider the downside for the executive. Where can this go wrong? How would this alienate him/her with peers or higher ups? Basically you have to build a threat model from the executive’s perspective. And you then you need to be able to overcome those objections, or he/she will kill your project. Guaranteed. Building the threat model and overcoming the objections isn’t easy, which is why so many security folks don’t get what they want. Always remember, it’s not about protection or security. It’s about understanding the goals and success criteria for your organization and every executive that can say no. I know your senior executives aren’t necessarily adversaries, but since they can get in your way and derail your plans you need to map out a strategy to bring them to your side – or at least neutralize them. And keep in mind that you will not win every battle. Sometimes they’ll still say no, regardless of your strategy or efforts. Keep each setback in context of the entire war, and move on to the next battle. Or decide it was more fun to configure firewalls. That’s always an option. Photo credit: The Peter Principle: Why Things Go Wrong available on Amazon Share:

IBM continues to be aggressive with acquisitions, grabbing BigFix today for an undisclosed amount. Given BigFix’s aspirations (they were moving toward a public offering), I’m a bit surprised the economics weren’t disclosed, but it was likely a decent sized deal. IBM and BigFix have a fairly long history of working together, and strategically this deal makes a lot of sense – especially given that IBM’s Tivoli systems management offerings weren’t very competitive on the endpoint. Once we got past the “Smarter Planet” branding hogwash on the analyst conference call, the leverage of IBM/BigFix became apparent. First, BigFix always positioned itself as a platform, driven by content and their Fixlets: applications that plug into the platform. You have to figure the IBM Global Services folks are drooling a bit to finally control an endpoint management integration platform – and the billable hours to build thousands more Fixlets. BigFix as a stand-alone company wasn’t a long-term option. Small companies don’t get to play in the platform space, not over long periods of time anyway. But hats off to the BigFix folks – they focused on bringing specific use cases to market to show the power of their platform and knock down some big enterprise deployments. On the other hand, IBM is strictly a platform player, so the idea of Big Blue rolling out a comprehensive endpoint management offering is a no-brainer. If anything, this solves a big operational problem for IBM, given their 500,000+ employees around the world (they plan to eat their own dog food with an enterprise-wide deployment) and millions of endpoints managed through their outsourcing business. From that perspective, this is very much like the HP/Opsware deal a few years ago. Yes, the deal gets justified by the big opportunity to sell the software, but the internal operational leverage of the technology is a big sweetener (and likely a deal size multiplier). Additionally, IBM needed to make a move to bolster their security product capabilities, which are getting a bit long in the tooth. They’ve seen the former ISS erode to irrelevance; they moved the ISS products into the Tivoli group, but it’s too little too late. With BigFix they ger an opportunity to bring a far more strategic offering into the bag. Symantec has this capability through their Altiris acquisition and EMC/RSA bought ConfigureSoft a while back to get better endpoint management. You have to wonder if McAfee was a player in this deal, because they’ve got a big hole in their offering around endpoint management. Customer Impact If you are a BigFix customer, you likely have mixed feelings. Now you get to deal with IBM, which can be a nightmare. And if you have a very heterogenous environment, over time that is at risk. Of course, both IBM and BigFix will maintain their commitment to supporting a heterogeneous world, but you figure IBM platforms will get priority for new features and Fixlets. That’s the way of the world. IBM outsourcing customers should be tickled. If you can get an endpoint change request through the gauntlet of change orders, contract (re)negotiations, and the other roadblocks IBM puts in your way, they’ll actually have a slick way to make the change. This also adds a number of other cool service offerings (energy management, endpoint remediation, asset management, etc.) that may actually add value to your services relationship. Imagine that. Obviously you’ll see all the competition, both big (Symantec, RSA, HP) and little (LanDesk, Lumension, Shavlik) throw some FUD (fear, uncertainty, and doubt) balloons your way during the procurement process. Clearly there will be some impact to the product roadmap, and likely support, as the newly wealthy BigFixers move on and Tivoli starts putting their imprint on company operations. If anything, you should be able to use the FUD as more leverage to get additional pricing and T&C concessions when negotiating your purchase or renewal. Issues Like any other deal, most of the risk is in integration. Can IBM maintain the people and continue to drive the product to take advantage of the leverage they just paid for? I can say I was impressed with the three-phase integration plan IBM presented during the analyst call. The first phase is to get more exposure for BigFix within the customer base and good things should happen. After that, they integrate with the existing Tivoli stuff from a product and console standpoint. Given the existing relationship, the integration issues are somewhat manageable. That doesn’t mean they don’t exist or that IBM won’t screw it up – just ask ISS about that. But given the work already done to drive integration (you’ve got to figure the deal has been in the works for a while) and the existing partnership, they have done what they can to contain the risk. Bottom Line The only outstanding question is how much of a premium did BigFix cost? From almost every other standpoint the strategic rationale of this deal is strong and even the issues are not that big. This likely means other big Security/IT companies (think McAfee, BMC, Oracle, etc.) need to grab some real estate in the endpoint management space. So not only is this a good day for the folks at BigFix, but Shavlik, Lumension, and LanDesk (once their emancipation from Emerson goes through) are well positioned to be next. Share:

They say that no man is an island, and in the security space that’s very true. No system is, either – especially those tasked with some kind of security management. We get caught up in SIEM and Log Management platforms to suck in every piece of information they can to help with event correlation and analysis, but when it comes down to it security management is just one aspect of an enterprise’s management stack. SIEM/Log Management is only one discipline in the security management chain, and must feed some portion of its analysis to supporting systems. So clearly integration is key, both to getting value from SIEM/LM, and to making sure the rest of the organization is on board with buying and deploying the technology. For a number of enterprise IT management systems it is important to integrate with the SIEM/Log Management platform, ranging from importing data sources, to sending alerts, even up to participating in an IT organization’s workflow. We’ve broken the integrations up into inbound (receiving data from another tool) and outbound (sending data/alerts to another tool). Inbound integration Security management tools: We discussed this a bit when talking about data collection, regarding the importance of broadening the number of data sources for analysis and reporting. These systems include vulnerability management, configuration management, change detection, network behavioral analysis, file integrity monitoring, endpoint security consoles, etc. Typically integration with these systems is via custom connectors, and most SIEM/LM players have relationships with the big vendors in each space. Identity Management: Identity integration was discussed in the last post on advanced features and is another key system for providing data to the SIEM/LM platform. This can include user and group information (to streamline deployment and ongoing user management) from enterprise directory systems like Active Directory and LDAP, as well as provisioning and entitlement information to implement user activity monitoring. These integrations tend to be via custom connectors as well. Because these inbound integrations tend to require custom connectors to get proper breadth and fidelity of data, it’s a good idea to learn a bit about each vendor’s partner program. Vendors use these programs to gain access to the engineering teams behind their data sources; but more importantly devote the resources to developing rules, policies, and reports to take advantage of the additional data. Outbound integration IT GRC: Given that SIEM/Log Management gathers information useful to substantiate security controls for compliance purposes, clearly it would be helpful to be able to send that information to a broader IT GRC (Governance, Risk, and Compliance) platform that is presumably managing the compliance process at a higher level. So integration(s) with whatever IT GRC platform is in use within your organization (if any) is an important consideration for deciiding to acquire of SIEM/Log Management technology. Help Desk: The analysis performed within the SIEM/Log Management platform provides information about attacks in progress and usually requires some type of remediation action once an alert is validated. To streamline fixing these issues, it’s useful to be able to submit trouble tickets directly into the organization’s help desk system to close the loop. Some SIEM/Log Management platform have a built-in trouble ticket system, but we’ve found that capability is infrequently used, since all companies large enough to utilize SIEM/LM also have some kind of external help desk system. Look for the ability to not only send alerts (with sufficient detail to allow the operations team to quickly fix the issue), but also to receive information back when a ticket is closed, and to automatically close the alert within the SIEM platform. CMDB: Many enterprises have also embraced configuration management databases (CMDB) technology to track IT assets and ensure that configurations adhere to corporate policies. When trying to ensure changes are authorized, it’s helpful to be able to send indications of changes at the system and/or device level to the CMDB for confirmation. Again, paying attention to each vendor’s partner program and announced relationships can yield valuable information about the frequency of true enterprise deployment, as large customers demand their vendors work together – often forcing some kind of integration. It also pays to as vendor references about their integration offerings – because issuing a press release does not mean the integration is functional, complete, or useful. Share:

Earlier this week I was at the gym. I’d just finished a pretty tough workout and dropped down to the cafe area to grab one of those adult candy bars that tastes like cardboard and claims to give you muscles, longer life, and sexual prowess while climbing mountains. At least, that’s what I think they claim based on the pictures on the box. (And as a former mountain rescue professional, the technical logistics of the last claim aren’t worth the effort and potential injuries to sensitive bits). Anyway, there was this woman in front of me, and her ordering process went like this: Ask for item. Ask for about 5-6 different options on said menu item, essentially replacing all ingredients. Look surprised when a number following a dollar sign appears on the little screen facing her on the cash register. Reach down to gym bag. Remove purse. Reach into purse. Remove wallet. Begin scrounging through change. See salad in cooler out of corner of eye. Say, “Oh! I didn’t see that!” Walk to cooler, leaving all stuff in front of register, with transaction in the middle. Fail to see or care about line behind her. At this point, as she was rummaging through the pre-made salads, the guy behind the register looked at me, I looked at him, and we both subconsciously communicated our resignation as to the idiocy of the display in front of us. He moved over and unlocked the next register so I could buy my mountain-prowess-recovery bar, at which point the woman returned to the register and looked surprised that he was helping other (more decisive and prepared) customers. One of my biggest pet peeves is people who lack awareness of the world around them. Which is most people, and probably explains my limited social life. But they probably hate judgmental sanctimonious jerks like me, so it all works out. Just think about how many fewer security (and other) problems we’d have in the world if people would just swivel their damn heads and consider other people before making a turn? John Lennon should write a song about that or something. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Mike and Adrian on Open Network Podcast. Talking Open Source software vulnerabilities. Rich, Martin and Zach on the Network Security Podcast. Rich quoted on DLP in eWeek. Favorite Securosis Posts Adrian Lane: IBM gets a BigFix for Tivoli Endpoint Management. Congratulations to the BigFix team! Mike Rothman: IBM gets a BigFix. Normally I don’t toot my own horn, but this was a good deal of analysis. Fairly balanced and sufficiently snarky… David Mortman: Understanding and Selecting a Tokenization Solution: Introduction. Rich: Ditto. Other Securosis Posts Understanding and Selecting SIEM/LM: Integration. Know Your Adversary. Tokenization: the Business Justification. Understanding and Selecting SIEM/LM: Advanced Features. Incite 6/30/2010: Embrace Individuality. Understanding and Selecting SIEM/LM: Data Management. DB Quant: Manage Metrics, Part 3, Change Management. Favorite Outside Posts Adrian Lane: Full Disclosure: Our Turn Not only does this show just how easily this can happen – to anyone – but it underscores the difficulty for sites built from dozens of components from different vendors. The “weakest link in the chain” rule applies. David Mortman: Same for me – Full Disclosure, Our Turn. Rich: A great TED talk on self deception. I really love better understanding our own biases. 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 Rich and Adrian in Essentials Guide to Data Protection. Justices Uphold Sarbanes-Oxley Act. Laughably, some parties complained SOX is not being followed by foreign companies! Heck, US comapnies don’t follow SOX! Off balance-sheet assets? Synthetic CDO’s? Please, stop pretending. Alleged Russian agents used high-tech tricks. Review of how the alleged Russian spies allegedly moved data. Interesting mix of old techniques and new technologies. But as any information can be digitized, the risk of being caught is far less, and prosecution much more difficult, if spy and spy-handler are never in the same spot together. Twitter mandated to establish information security program. Destimation Hotels breached. FBI fails to crack TrueCrypt. Top applications fail to leverage Windows security protections. This is a huge deal – if the apps don’t opt into anti-exploitation, they are essentially a dagger straight to the heart of the OS if an attacker finds a vuln. 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 The Open Source Database Security Project. Adrian – thanks for the reply. Maybe risk assessment wasn’t the right word – I was thinking of some sort of market analysis to determine which open source databases to focus on. I was using selection criteria like “total number of installations” and “total size in bytes”, etc, but user groups is indeed a good criterion to use, since you are targeting an audience of actual ordinary users, not mega companies like facebook and twitter that should be managing the security themselves. Maybe these types of distributed databases (bigtable, Cassandra) should be the focus of separate project? A quick search of Securosis shows one mention of bigtable, so while I don’t want to expand the scope of the current project, these “storage systems” do offer some interesting security problems. For example here Peter Fleischer from Google discusses the difficulty in complying with the EU Data Protection Directive: http://peterfleischer.blogspot.com/2009/04/cloud-policy-consequences-for-privacy.html Share:

I still go see a lot of live music. Yes, it’s a luxury, but I’d rather give something else up than my handful (OK, maybe two handfuls) of shows every year. On Monday night we saw Sting with his big orchestra. It was definitely a more mellow show than when we saw him a few years ago with his band (right, The Police), but it was a good show nonetheless. I usually go to shows with the Boss and we each have different things that we like and don’t like about live music. Over the past few years we’ve learned to accept each other’s show angst. She likes to sit close and sometimes when the budget and availability work out, we get decent seats. In the event we don’t get close, she’s usually looking for an opportunity to move up. That gives me angst. Bordering on paranoia. When I’m in someone else’s seat I’m figuring each person who walks by wants their seats back and will probably hit me with a bat. I know, it’s not logical, but it causes me angst. It kills my proverbial show buzz. The Boss has no irrational seat squatting fear, so she just waits to be ejected and is cool with that. But she’s got show issues too. It makes her nuts when someone around us is talking. I mean nuts. I should call her Ms. Shush. Since she’ll usually just tell them to uh, quiet down. She does have a point in that these people pay a hundred bucks to go to a show and then talk about their goiters or sports teams or some asshat at work. Go figure. But the extraneous noise doesn’t bother me. I focus on the performer and tune everything else out. I could get annoyed that she’ll disappear for most of a show and meet me later if she gets a better seat. And she could get annoyed that the chatter doesn’t bother me. But that’s not productive. Now we know each other’s angsts and we accommodate. I let her go walkabout and if she does stay in our seats, I’ve become a burgeoning Mr. Shush because I know her experience is better if everyone shuts their traps. And it works for us. But only if you embrace your partner’s individuality and learn to roll with it. Maybe I have learned something after 13+ years of marriage. – Mike. Photo credits: “Individuality Redux” originally uploaded by spaceamoeba Recent Securosis Posts Friday Summary: June 25, 2010 Understanding and Selecting a Tokenization Solution: Introduction Are Secure Web Apps Possible? NSO Quant: Manage Firewall Process Map NSO Quant: Manage IDS/IPS Process Map Adrian and Rich are wrapping up DB Quant Incite 4 U Toothless FTC ‘Settles’ with Twitter – So it seems Twitter got a slap on the wrist recently from the Federal Trade Commission for misleading consumers about protecting their privacy. The Twitter folks settled to make the problem go away, which was the right thing to do. Twitter is now barred for 20 years “from misleading consumers about the extent to which it maintains and protects the security, privacy, and confidentiality of nonpublic consumer information.” That’s a relief. And they need to be subjected to a security program review every other year for 10 years. Again, what major service provider doesn’t do this? In the article it does talk about some stuff that Twitter was (or wasn’t) doing, which are good practices. Like requiring strong admin passwords and not allowing administrators to store those passwords in their personal email. Duh. Anyhow, the FTC getting involved is fine, but if they want organizations to be more serious about privacy, they need more impactful consequences. – MR Assured Integrity on Bogus Data – Richard Bejtlich’s post on Dealing with Security Instrumentation Failures, along with the referenced articles on Si(EM)lent Witness hits on a trifecta of weaknesses in security monitoring devices at large: dropped or missing events, capturing only one side of a conversation, and touting the integrity of an already suspect data stream. In everything from IDS to DAM, dropped transactions are a real problem. Network monitoring that captures a request but fails to capture the response is a real problem. Both receive hand-waves from vendors and surprisingly from security practitioners as well, who assume the other 98% of events is enough. But have they quantified the loss, or the percentage of records that are missing? The percentage that are missing a portion of the data? Examine carefully the claims of SIEM, DAM, and other event storage vendors that the data is totally secure – privacy and integrity are typically 100% assured. But the stream before it arrives at its destination? Suspect! I used to play the injection game, throwing garbage statements on the wire that were completely ignored by the application, but picked up by the monitor because it had the right IP and port. Since they failed to collect response codes, this counted as legit traffic. I am not saying that you can necessarily do anything about it, but give it some thought, and have some test cases to verify how your tools handle them, or what the packet loss expectancy really is. – AL A Different Kind of Disclosure – We all know the disclosure debate will never end. It’s basically religion on all sides; with few willing to change their positions and little more than anecdotal evidence available, you can spin it however you want. But I think we can all agree that no one wants to find out about a vulnerability like WellPoint did. A customer figured out she could see others’ records by manipulating the URL (yes, about the most basic vulnerability a web application can have). Instead of reporting it to WellPoint she called her lawyer. WellPoint found out they were vulnerable when she sued them for breach of privacy. Then again, it seems the exposure may have mostly been limited to her and her lawyers poking around. WellPoint fixed the problem in

We’ve already discussed the basic features of a SIEM/Log Management platform, including collection, aggregation and normalization, correlation and alerting, reporting and forensics, and deployment architectures. But these posts cover the core functions, and are part of what each products in the space will bring to the table. As markets evolve and vendors push to further differentiate themselves, more and more capabilities are integrated into the platforms. In the case of SIEM/LM, this means pumping more data into the analysis engine, and making engine smarter. The idea is to make 1+1 produce 5, as multiple data types provide more insight than a single source – that’s the concept, anyway. To be clear, having more data does not make directly the product any better. The only way to really leverage additional data is to build correlation rules and alerts and reports that utilize the extra data. Let’s take a tour through some of the advanced data types you’ll see integrated into SIEM/LM platforms. Flow Network flow data is the connection records that stream out of a router or switch. These small and simple data files/streams typically list source, destination, and packet type. Flow data was really the first new data type which, when integrated with event and log data, really made the systems smarter. Flow data allowed the system to establish a baseline and scan for anomalous network traffic as the first indication of a problem. An entire sub-market of network management – network behavioral analysis – revolves around analyzing and visualizing flow data to understand the traffic dynamics of networks, and pinpointing performance and capacity issues before they impact users. Many of the NBA vendors have been unsuccessfully trying to position their products in the security market; but in combination with events and logs, flow data is very useful. As an example, consider a typical attack where a web server is compromised and then used as a pivot to further compromise an application server and the backend database server. The data needs to be exfiltrated in some way, so the attackers establish a secure pipe to an external zombie device. But the application server doesn’t typically send data to an external device, so flow data would show an anomalous traffic flow. At that point an administrator could analyze the logs, with correlated activity showing a new account created on the database server, and identifying the breach. Could an accurate correlation rule have caught the reconnaissance and subsequent compromise of the servers? Maybe. But the network doesn’t lie, and at some point the attackers need to move the data. These types of strange network flows can be a great indicator of a successful attack, but remember strange flows only appear after the attack has occurred. So flow data is really for reacting faster to attacks already underway. Even more powerful is the ability to set up compound correlation rules, which factor in specific events and flow scenarios. Of course setting up these rules is complicated and they require a lot of tuning, but once the additional data stream is in place, there are many options for how to leverage it. Identity Everyone wants to feel like more than just a number, but when talking about SIEM/Log Management, your IP address is pretty much who you are. You can detect many problems by just analyzing all traffic indiscriminately, but this tends to generate plenty of false positives. What about the scenario where the privileged user makes a change on a key server? Maybe they used a different device, which had a different IP address. This would show up as an unusual address for that action, and could trigger an alert. But if the system were able to leverage identity information to know the same privileged user was making the change, all would be well, right? That’s the idea behind identity integration with SIEM/LM. Basically, the analysis engine pulls in directory information from the major directory stores (Active Directory & LDAP) to understand who is in the environment and what groups they belong to, which indicates what access rights they have. Other identity data – such as provisioning and authentication information – can be pulled in to enable advanced analysis, perhaps pinpointing a departed user accessing a key system. The holy grail of identity integration is user activity monitoring. Yup, Big Brother lives – and he always knows exactly what you are doing. In this scenario you’d be able to set up a baseline for a group of users (such as Accounting Clerks), including which systems they access, who they communicate with, and what they do. There are actually a handful of other attributes that help identify a single user even when using generic service accounts. Then you can look for anomalies, such as an accounting clerk accessing the HR system, making a change on a sensitive server, or even sending data to his/her Gmail account. This isn’t a smoking gun, per se, but it does give administrators a place to look for issues. Again, additional data types beyond plain event logs can effectively make the system smarter and streamline problem identification. Database Activity Monitoring Recently SIEM/LM platforms have been integrating Database Activity Monitoring (DAM), which collects very detailed information about what is happening to critical data stores. As with the flow data discussed above, DAM can serve up activity and audit data for SIEM. These sources not only provide more data, but add additional context for analysis, helping with both correlation and forensic analysis. Securosis has published plenty of information on DAM, which you can check out in our research library. The purpose of DAM integration is to drive analysis deeper into database transactions, gaining the ability to detect patterns which indicate successful compromise or misuse. As a simple example, if a mobile user gets infected at Starbucks (like that ever happens!) and then unwittingly provides access to the corporate network, the attacker then proceeds to compromise the database. The DAM device monitors the transactions to and from the database, and should see

Updated: 06/30/2010 One of the most daunting tasks in information security is protecting sensitive data in (often complex and distributed) enterprise applications. Even the most hardened security professionals enters these projects with at least a modicum of trepidation. Coordinating effective information protection across application, database, storage, and server teams is challenging under the best of circumstances – and much tougher when also facing the common blend of legacy systems and conflicting business requirements. For the most part our answer to this problem has been various forms of encryption, but over the past few years we’ve seen increasing interest in and adoption of tokenization. Encryption, implemented properly, is one of the most effective security controls available to us. It renders information unreadable except to authorized users, and protects data both in motion and at rest. But encryption isn’t the only data protection option, and there are many cases where alternatives make more sense. Sometimes the right choice is to remove the data entirely. Tokenization is just such a technology: it replaces the original sensitive data with unsensitive placeholders. Tokenization is closely related to encryption – they both mask sensitive information – but its approach to data protection is different. With encryption we protect the data by scrambling it using a process that’s reversible if you have the right key. Anyone with access to the key and the encrypted data can regenerate the original values. With tokenization the process is not reversible. Instead we substitute a token value that’s only associated with the “real” data within a well-protected database. This token can even have the exact same format (size & structure) as the original value, helping minimize application changes. But the token is effectively random, rather than a scrambled version of the original data. The token cannot be compromised to reveal sensitive data. The power of tokenization is that although the token value is usable within its native application environment, it is completely useless outside. So tokenization is ideal to protect sensitive identifying information such as credit card numbers, Social Security Numbers, and the other personally identifiable information bad guys tend to steal and use or sell on the underground market. Unless they crack the tokenization server itself to obtain the original data, stolen tokens are worthless. Interest in tokenization has accelerated because it protects data at a lower overall cost. Adding encryption to systems – especially legacy systems – introduces a burden outside the original design. Making application changes to accomodate encrypted data can dramatically increase overhead, reduce performance, and expand the responsibilities of programmers and systems management staff. In distributed application environments the need to encrypt, decrypt, and re-encrypt data in different locations results in exposures that attackers can take advantage of. More instances where systems handle keys and data mean more opportunities for compromise. For example, one growing attack is the use of memory parsing malware: malicious software installed on servers and capable of directly accessing memory to pull encryption keys or data from RAM, even run without administrative privileges. Aside from minimizing application changes, tokenization also reduces potential data exposure. When properly implemented, tokenization enables applications to use the token throughout the whole system, only accessing the protected value when absolutely necessary. You can use, store, and transact with the token without fear of exposing the sensitive data it represents. Although at times you need to pull out the real value, tokenization allows you to constrain its usage to your most secure implementations. For example, one of the most common uses for tokenization is credit card transaction systems. We’ll go into more depth later, but using a token for the credit card number allows us to track transactions and records, only exposing the real number when we need to send a transaction off to the payment processor. And if the processor uses tokenization as well, we might even be able to completely eliminate storing credit card numbers. This doesn’t mean tokenization is always a better choice than encryption. They are closely related and the trick is to determine which will work best under the particular circumstances. In this series we’ll dig deep into tokenization to explain how the technology works, explore different use cases and deployment scenarios, and review selection criteria to pick the right option. We’ll cover everything from tokenization services for payment processing and PCI compliance to rolling your own solution for internal applications. In our next post we’ll describe the different business justifications, and follow up with a high-level description of the different tokenization models. After that we’ll post on the technology details, deployment, use cases, and finally selection criteria and guidance. If you haven’t figured it out by now, we’ll be pulling all this together into a white paper for release later this summer. Just keep this in mind: sometimes the best data security choice is to avoid keeping the data at all. Tokenization lets us remove sensitive data while retaining much of its value. Share:

We covered SIEM and Log Management deployment architectures in depth to underscore how different models are used to deal with scalability and data management issues. In some cases these deployment choices are driven by the underlying data handling mechanism within the product. In other words each platform stores and manages data differently – these decisions have significant impact on product scalability, data management, and reporting & forensics capabilities. Here we discuss the different internal data storage models, with advantages and disadvantages of each. Relational Database In the early days of this technology, most SIEM and log management systems were built on relational database engines to store events and log records. In this model the SIEM platform maps data attributes from each data source into database columns, so each event is stored in a single database row. There are numerous advantages to this model, including: Data Validation – As data is inserted into the column, the database verifies data type and range settings. Integrity check failures indicate corrupted files and are omitted from the import, with notification to administrators. Event Consistency – An event from a Cisco router now looks just like an event from a Juniper router, and vice-versa, as events are normalized before being stored in the table. Reporting – Reports are easier to generate from validated data columns, and the database can format data when generating the report. Reports run far faster thanks to column indices, effectively filtering and ordering events. Analytics – An RDBMS facilitates complex queries across all available attributes, inspected content, and correlation. This model for data storage has fallen out of favor due to the overhead of data insertion: as each row is inserted the database must perform the checks and periodically rebuild indices. As daily event volumes scaled from millions to hundreds of millions and billions, this overhead became problematic and resulted in significant scalability issues with SIEM offerings built on RDBMS. Further, data that does not fit into the tables defined in the relational model is typically left out. Unless there is some other method to maintain the fidelity and integrity of the original event records, this is problematic for forensics. This “selective memory” can also result in data accuracy issues, as truncated records may not correlate properly and can hamper analysis. As a result SIEM/LM architectures based on RDBMS are waning, as products in this space re-architect their backend data stores to address these issues. On the other hand, RDBMS storage is not totally dead – some vendors have instead chosen to streamline data insertion, basically by turning off some RDBMS checks and integrity verification. Others use an RDBMS to supplement a flat file architecture (described below), leveraging the advantages above for reporting and forensics. Flat File Flat files, or just ‘files’, are now the most common way to store events for SIEM and Log Management. Files are serve as a blank canvas for the vendor; as they can introduce any structure they choose to help define, format, and delineate events. Anything that helps with correlation and speeds up future searches is included, and each vendor has their own secret sauce for building files. Each file typically contains a day’s events, possibly from a single source, with each event clearly delineated. The files (in some cases each event) can be tagged with additional information – this is called “log enrichment”. These tags offer some of the contextual benefits of a relational database, and help to define attributes. Some even include a control structure similar to VSAM files. The events may be stored in their raw form, or be normalized prior to insertion. Flat files offer several advantages. Performance – Since normalization (to the degree necessary) happens before data insertion, there is very little work to be performed prior to insertion compared to a relational database. Data is stored as quickly as the physical media can handle, and often available immediately for searching and analysis. Flexibility – Stored events are not limited to specific normalized columns as they are in a relational database, but can take any form. Changes to internal file formats are much easier. Search – Searches can be performed without understanding the underlying structures, using simple keyword search. At least one log management vendor provides a Google-style search capability across data files. Alternately, search can rely upon tags and keywords established by the vendor. The flat file tradeoffs are twofold. First, any data management capabilities – such as indexing and data integrity – must be built from scratch by the vendor, since no RDBMS capabilities are provided by the underlying platform. This means the SIEM/LM vendor must provide any needed facilities for data integrity, normalization, filtering, and indexing. Second, there is an efficiency tradeoff. Some vendors tag, index, and normalize prior to insertion; others initially record raw events, later re-reading the data in order to normalize it, and then rewrite the reformatted data. The later method offers faster insertion, at the expense of greater total storage and processing requirements. The good news is that a few years ago most vendors saw the scalability wall of RDBMS approaching, and began investing in their own back-end data management environments. At this point many platforms feature purpose-built high-performance data stores, and we believe this will be the underlying architecture for these products moving forward. Of course, we don’t live in an either/or world, so many of the platforms combine some RDBMS capabilities with flat file aspects. Yes, the answer can be ‘both’. Share: