Research

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:

Thursday was totally shot. I wasted the entire day standing around. Eight hours and twenty nine minutes standing in line. I got in line at 5:50 AM and did not get back in my car until 3:00. Yep, it was Apple iPhone day. And I did not have a reservation. If you like people-watching, this is about as much fun as you will ever have. There were some 700 people at the mall by 6:30 AM. Close to me in line were two women with infants, and they were there all day. There were small children with their grandparents. The guy next to me had a shattered foot from a recent car accident. There were people calling their bosses, not to call in sick, but to tell them they were taking the day off to buy iPhones. These people were freakin’ dedicated. I have not stood in line for any length of time since 1983, trying to get a good seat for Return of the Jedi. I have not stood in line without knowing whether I would get what I was there for since the Tutankhamun exhibit in, what, 1979? This is not something I do, but I wanted the phone. And actually I did not want the ‘phone’, but everything else. I wanted a (mostly) secure way to get email on the road. I wanted a mobile device to surf the web. I wanted a way to find Thai food. I wanted a better camera. I wanted a way to get directions when traveling. I wanted to have music with me. I wanted to access files in Dropbox whenever and wherever. And the BlackBerry did none of these thing well, if at all. Plus, as a device, the BlackBerry is a poorly-engineered turd in comparison. I was just done with it, and I wanted the iPhone, and I wanted it before Black Hat. So there I stood, for eight and a half hours, holding a place in line for a guy with a broken foot so he could sit on the mall couch. I have to say the Apple employees were great. Every 30 minutes they brought us water and Starbucks coffee. Every 15 minutes they brought snacks. They sent employees into the line to chat. They brought sample phones and sat with us, in line, to demo the differences. They thanked us for sticking it out. They asked us if we needed anything, holding places in line and bringing food. They took care of every part of the transaction, including dealing with AT&T and their inability to process credit cards without dialing up Equifax. Great products and great service … it’s like I was transported back in time to an age when those things mattered. All in all I am glad I waited it out and got my phone. Camera is amazing. Display is crystal-clear. The phone does not have the hideous ‘pops’ in audio that blow my ears out, or randomly shut off for 20 seconds like the BlackBerry. And the FaceTime feature works really well, for what it’s worth. Would I do it again? Would I stand there for 8.5 hours? Ask me in another 25 years. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Chris Pepper gives us The Sun Also Sets. Time to kick Oracle a little. What a bloody fiasco! Adrian’s Dark Reading post on Open Source Database Security Issues. Rich on the Network Security Podcast, number 202. Favorite Securosis Posts Rich: Understanding and Selecting SIEM/LM: Deployment Models. Adrian and Mike do a great job of diagramming out the different deployment models. Really clear. Mike Rothman: The Open Source Database Security Project. Adrian needs to flex his database security kung-fu, and we aren’t going to get in his way. Help him out – it’s a great project. Adrian Lane: Trustwave Acquires Breach. I have not seen anyone openly discuss the apparent conflicts of interest, nor how this changes PCI compliance, the way Rich has captured it. Other Securosis Posts Understanding and Selecting a Tokenization Solution: Introduction. Are Secure Web Apps Possible? Incite 6/23/2010: Competitive Fire. FireStarter: Is Full Disk Encryption without Pre-Boot Secure?. Return of the Security Start-up? Friday Summary: June 18, 2009. Doing Well by Doing Good (and Protecting the Kids). Favorite Outside Posts Rich: Why the Disclosure Debate Doesn’t Matter. Dennis nails it. Bad guys don’t give a rat’s ass what we think of disclosure, they still have plenty to own us with. Mike Rothman: Security Intelligence: Defining APT Campaigns Good analysis of what’s involved in detecting a multi-faceted complex intrusion from Mike Cloppert. If you have a great forensics person who is good at this, pay them more. Those skills are gold. Adrian Lane: Anti-WAF Software Only Security Zealotry. Only because Jeremiah wrote this before I did. Project Quant Posts DB Quant: Manage Metrics, Part 1, Configuration Management. DB Quant: Protection Metrics, Part 4, Web Application Firewalls. DB Quant: Protect Metrics, Part 3, Masking. DB Quant: Protect Metrics, Part 2, Encryption. DB Quant: Protect Metrics, Part 1, DAM Blocking. NSO Quant: Manage IDS/IPS Process Map. DB Quant: Monitoring Metrics, Part 2, Audit. DB Quant: Monitoring Metrics, Part 1, DAM. NSO Quant: Manage Firewall Process Map. DB Quant: Secure Metrics, Part 4, Shield. DB Quant: Secure Metrics, Part 3, Restrict Access. DB Quant: Secure Metrics, Part 2, Configure. 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. Report: Database Assessment. Top News and Posts Firefox & Opera updates. Improving HTTPS Side Channel Attacks Google wins Viacom suit. 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, not days or even months. iPhone PIN code worthless. Rich published on this a long time ago, but automounting on Ubuntu is new and disturbing. Previously people believed you had to jailbreak

Believe it or not, we are down to our final metrics post! We’re going to close things out today with change management – something that isn’t specific to security, but comes with security implications. Our change management process is: Monitor Schedule and Prepare Alter Verify Document Monitor Variable Notes Time to gather change requests Time to evaluate each change request for security implications Schedule and Prepare Variable Notes Time to map request to specific actions/scripts Time to update change management system Time to schedule downtime/maintenance window and communicate Alter Variable Notes Time to implement change request Verify Variable Notes Time to test and verify changes Document Variable Notes Time to document changes Time to archive scripts or backups Other Posts in Project Quant for Database Security An Open Metrics Model for Database Security: Project Quant for Databases Database Security: Process Framework Database Security: Planning Database Security: Planning, Part 2 Database Security: Discover and Assess Databases, Apps, Data Database Security: Patch Database Security: Configure Database Security: Restrict Access Database Security: Shield Database Security: Database Activity Monitoring Database Security: Audit Database Security: Database Activity Blocking Database Security: Encryption Database Security: Data Masking Database Security: Web App Firewalls Database Security: Configuration Management Database Security: Patch Management Database Security: Change Management DB Quant: Planning Metrics, Part 1 DB Quant: Planning Metrics, Part 2 DB Quant: Planning Metrics, Part 3 DB Quant: Planning Metrics, Part 4 DB Quant: Discovery Metrics, Part 1, Enumerate Databases DB Quant: Discovery Metrics, Part 2, Identify Apps DB Quant: Discovery Metrics, Part 3, Config and Vulnerability Assessment DB Quant: Discovery Metrics, Part 4, Access and Authorization DB Quant: Secure Metrics, Part 1, Patch DB Quant: Secure Metrics, Part 2, Configure DB Quant: Secure Metrics, Part 3, Restrict Access DB Quant: Monitoring Metrics: Part 1, Database Activity Monitoring DB Quant: Monitoring Metrics, Part 2, Audit DB Quant: Protect Metrics, Part 1, DAM Blocking DB Quant: Protect Metrics, Part 2, Encryption DB Quant: Protect Metrics, Part 3, Masking DB Quant: Protect Metrics, Part 4, WAF Share:

We security folks are a tough crowd, and we have trouble understanding why stuff that is obvious to us isn’t so obvious to everyone else. We wonder why app developers can’t understand how to develop a secure application. Why can’t they grok SDL or run a damn scanner against the application before it goes live? Q/A? Ha. Obviously that’s for losers. And those sentiments aren’t totally misplaced. There is a tremendous amount of apathy regarding software security, and the incentives for developers to do it right just aren’t there. But it’s not all the developers fault, because for the most part secure coding is a dream. Yeah, maybe that’s harsh and I’m sure the tool vendors will be hanging me in effigy soon enough, but that’s how it seems to me. Says the guy who hasn’t developed real code for 18+ years and leaves the application security research to folks (like Adrian) who are qualified to have an opinion. But not being qualified never stopped me from having an opinion before. I come to this conclusion after spending some time trying to digest a post by Errata Security’s Rob Graham on the AT&T iPad hack. Rob goes through quite a few application security no-nos, quoting chapter and verse, pointing them out in this rather simple attack. This specific attack vector doesn’t appear in the OWASP Top 10 list, nor should it. But it underscores the difficulty of really securing an application and the need to not just run a scanner against the code, but to really exercise the business logic before turning the app loose on the world. Rob’s post talks about information leakage, security via obscurity, the blurring line between internal and external, and other ways to make an application do unintended things, usually ending in some kind of successful attack. So does that mean we give up, which seemed to be one of the messages from the Gartner show this week (hat tip to Ed at Securitycurve)? Not so much, but we have to continue aggressively managing expectations. If you have smart guys like Rob, RSnake, or Jeremiah beat the crap out of your application, they will find problems. Then you’ll have an opportunity to fix them before the launch. In a perfect world, this is exactly what you would do, but it certainly isn’t the cheapest or fastest option. On the other hand, you can run a scanner against the code and eliminate much of the lowest-hanging fruit that the script kiddies would target. That’s certainly an option, but the key to this approach is to make sure everyone knows a talented attacker specifically targeting your stuff will win. So when an attack not explicitly mentioned in your threat model (like the AT&T/iPad attack) happens, you will have to deal with it. And if you have some buddies in the FBI, maybe you can even get the hacker arrested on drug charges… Or you could do nothing like most of the world, and seem surprised when a 12-year-old in Estonia sells your customers on a grey-market website. To think we can really develop secure web applications is probably a pipe dream – depending on our definition of ‘secure’, obviously. But we certainly can make our apps more secure and outrun our slower competitors, if not the bear. Most of the time that’s enough. Share:

I’ve always been pretty competitive. For instance, back in high school my friends and I would make boasts about how we’d have more of this or that, and steal the other’s wife, etc. Yes, it was silly high school ego run rampant, but I thought life was a zero sum game back then. Win/win was not in my vocabulary. I win, you lose, that’s it. I carried that competitive spirit into the first 15 years or so of my working career. At META, it was about my service selling more than yours. About me being able to stake out overlapping coverage areas and winning the research battle. In the start-up world, it was about raising the money and beating the other companies with similar stories & models. Then in a variety of vendor gigs, each in very competitive market spaces, it was about competing and winning and having a better story and giving the sales team better tools to win more deals. Nothing was ever good enough – not at work, not at home, and not in my own head. Yeah, I was frackin’ miserable. And made most of the people around me miserable as well. When I was told my services were no longer needed at CipherTrust, I saw it as an opportunity to go in a different direction. To focus on helping folks do better, as opposed to winning whatever ‘needed’ to be won. It wasn’t exactly a conscious decision, but I knew I needed a change in focus and attitude. For the most part, it worked. I was much happier, I was doing better, and I was less grumpy. Then I stepped back into corporate life, but to be honest, my heart wasn’t in it. I didn’t care if we lost a specific deal because we should be able to get into a lot of deals and statistically we’d be OK. Of course, I had to mask that indifference, but ultimately for a lot of reasons it didn’t make sense for me to continue in that role. So I left and got back to where I could help folks, and not worry about winning. But you can’t entirely escape competition. Now I play softball on Sundays with a bunch of old guys like me. But some of them still have that competitive fire burning and to be honest it gets annoying. When someone boots a ground ball or lines out with runners on, these guys get all pissed off. We lost a one-run game last Sunday, after coming back from 3 runs down in the last inning. I was happy with that effort – we didn’t give up. Others were pissed. Personally, I play softball because it’s fun. I get outside, I run around, I get my couple of at-bats and make a few plays in the field. But when guys get all uppity about not winning or someone making a mistake, it’s demotivating to me. I’ve got to find a way to tune out the negativity and still have fun playing. Or I’ll need to stop, which is the wrong answer. But I am working too hard to be positive (which is not my default mode) to hang around with negatives. Yes, I like to win. But I don’t need to win anymore. And I’m a lot happier now because of it. But that’s just me. – Mike. Photo credits: “win win” uploaded to Flickr by TheTruthAbout… Recent Securosis Posts Understanding and Selecting SIEM/LM: Deployment Models. Trustwave, Acquisitions, PCI, and Navigating Conflicts of Interest. FireStarter: Is Full Disk Encryption without Pre-Boot Secure? Return of the Security Start-up? Doing Well by Doing Good (and Protecting the Kids). Take Our Data Security Survey & Win an iPad. Incite 4 U Different NAC strokes for different folks – A few weeks ago, Joel Snyder talked about what went wrong with NAC. It was a good analysis of the market issues. Joel’s conclusion is that there isn’t really a standard set of NAC features, but rather a number of different breeds. Which basically means there is no market – not a consistent one, anyway. No wonder the category has struggled – nobody can agree on what problem the technology is supposed to solve. Joel also points out some of the political issues of deploying a solution that spans network, endpoint, and security teams. This week, NetworkWorld published the Joel’s review. He does likes some of the products (those based on 802.1X like Avenda, Enterasys, and Juniper), and has issues with some of the others (ForeScout and TrustWave). But ultimately the review highlights the reality of the market, which is that there isn’t one. – MR DRM dreams – Designing DRM systems in 1996, I had big hopes that digital lockers would be a popular choice to secure content for people to share on the Internet. I thought everyone from banking systems to media distribution could benefit. By 1998 that dream faded as nobody was really interested in secure content storage or delivery. But it turns out someone has the same dreams I did: hackers embrace DRM as a way to hide pirated content as reported on Yahoo! News. Basically pirated video is wrapped up in a protective blanket of encryption, which can then be moved and stored freely, without detection by content analysis tools. Porn, pirated movies, and whatever else, can be distributed without fear of being inspected and discovered. And this model works really freaking’ well when the buyer and seller want to keep their activity a secret. Hollywood may have complained bitterly about pirated DVDs, but this particular delivery model will be near impossible to stop. No, Cyber-nanny will not cut it. There are only a handful of ways to catch and prosecute this type of crime. Law enforcement will have to figure out how to police the exchange of decryption keys for money. – AL Disclosure is religion – I’ve been known to write and talk about the disclosure debate, but I’m starting to wonder if it’s

I am thinking about writing a guide to secure open source databases, including verification queries. Do you all think that would be useful? For the most part, when I write about database security, I write about generic approaches that apply to all database platforms. I think this is helpful for database managers, as well as security and IT professionals who have projects that span multiple database types. When writing the Database Security Fundamentals series, my goal was to provide a universal checklist of the database security basics that anyone with basic DBA skills could accomplish in a week. DBAs who work in large enterprise may have established guidelines, but small and medium sized firms generally don’t, and I wanted the series to provide an awareness on what to look for and what to do. I also find that mainstream Oracle DBAs tune out because I don’t provide specific queries or discuss native features. The downside is that the series covers what to do, but not how to do it. By taking a more abstract look at the problems to be solved across security and compliance, I cannot provide specific details that will help with Oracle, Sybase, Teradata, PostgreSQL, or others – there are simply too many policies for too many platforms for me to sufficiently cover. Most DBAs know how to write the queries to fulfill the policies I outlined. For the non-DBA security or IT professional, I recognize that what I wrote leaves a gap between what you should do and how to do it. To close this gap you have a couple of options: Acquire tools like DAM, encryption, and assessment from commercial vendors Participate on database chat boards and ask questions RTFM Make friends with a good DBA Yes, there are free tools out there for assessment, auditing, and monitoring. They provide limited value, and that may be sufficient for you. I find that the free assessment tools are pretty bad because they usually only work for one database, and their policies are miserably out of date. Further, if you try to get assessment from a commercial vendor, they don’t cover open source databases like Derby, PostgreSQL, MySQL, and Open Ingres. These platforms are totally underserved by the security community but most have very large installed user bases. But you have to dig for information, and cobble together stuff for anything that is not a large commercial platform. So here is what I am thinking: through the remainder of the year I am going to write a security guide to open source databases. I will create an overview for each of the platforms (PostgreSQL, Derby, Ingres and MySQL), and cover the basics for passwords, communications security, encryption options, and so forth, including specific assessment polices and rules for baselining the databases. Every week I’ll provide a couple new rules for one platform, and I will write some specific assessment policies as well. This is going to take a little resourcefulness on my part, as I am not even sure my test server boots at this point, and I have never used Derby, but what the heck – I think it will be fun. We will post the assessment rules much like Rich and Chris did for the ipfw Firewall Rule Set. So what do you think? Should I include other databases? Should I include under-served but non-open-source such as MS Access and Teradata? Anyone out there want to volunteer to test scripts (because frankly I suck at query execution plans and optimization nowdays)? Let me know because I have been kicking this idea around for a while, but it’s not fully fleshed out, and I would appreciate your input. Share:

This morning Trustwave announced their acquisition of Breach Security, the web application firewall vendor. Trustwave’s been on an acquisition streak for a while now, picking up companies such as Mirage (NAC), Vericept (DLP), BitArmor (encryption), and Intellitactics (log management/SIEM). Notice any trends? All these products have a strong PCI angles, none of the companies were seeing strong sales (Trustwave doesn’t do acquisitions for large multiples of sales), and all were more mid-market focused. Adding a WAF to the mix makes perfect sense, especially since Trustwave also has web application testing (both controls meet PCI requirement 6.6). Trustwave is clearly looking to become a one-stop shop for PCI compliance. Especially since they hold the largest share of the PCI assessment market. To be honest, there are concerns about Trustwave and other PCI assessment firms offering both the assessment and remediation services. You know, the old fox guarding the henhouse thing. There’s a reason regulations prohibit financial auditors from offering other services to their clients – the conflicts of interest are extremely difficult to eliminate or even keep under control. When the person making sure you are compliant also sells you tools to help become compliant, we should always be skeptical. We all know how this goes down. Sales folks will do whatever it takes to hit their numbers (you know, they have BMW payments to make), and few of them have any qualms about telling a client they will be compliant if they buy both their assessment services and a nice package of security tools and implementation services. They’ll use words like “partners” and “holistic” to seem all warm and fuzzy. We can’t really blame Trustwave and other firms for jumping all over this opportunity. The PCI Council shows no interest in controlling conflicts of interest, and when a breach does happen the investigation in the kangaroo court will show the company wasn’t compliant anyway. But there is also an upside. We also know that every single client of every single PCI assessment, consulting, or product firm merely wants them to make PCI “go away”, especially in the mid-market. Having firms with a complete package of services is compelling, and companies with big security product portfolios like Symantec, McAfee, and IBM aren’t well positioned to provide a full PCI-related portfolio, even though they have many of the pieces. If Trustwave can pull all these acquisitions together, make them good enough, and hit the right price point, the odds are they will make a killing in the market. They face three major challenges in this process: Failing to properly manage the conflicts of interest could become a liability. Unhappy customers could lead to either bad press and word of mouth, or even changes in PCI code to remove the conflicts, which they want to avoid at all costs. The actual assessors and consultants are reasonably well walled off, but they will need to aggressively manage their own sales forces to avoid problems. Ideally account execs will only sell one side of the product line, which could help manage the potential issues. Customers won’t understand that PCI compliance isn’t the same as general security. Trustwave may get the blame for non-PCI security breaches (never mind the real cardholder data breaches), especially given the PCI Council’s history of playing Tuesday morning QB and saying no breached organization could possibly be compliant (even if they passed their assessment). Packaging all this together at the right price point for the mid-market won’t be easy. Products need real integration, including leveraging a central management console and reporting engine. This is where the real leverage is – not merely services-based integration, which is not good enough for the mid-market. So the Breach acquisition is a smart move for Trustwave, and might be good for the market. But as an assessor, Trustwave needs to carefully manage their acquisition strategy in ways mere product mashup shops don’t need to worry about. Share:

We have covered the major features and capabilities of SIEM and Log Management tools, so now let’s discuss architecture and deployment models. Each architecture addresses a specific issue, such as coverage for remote devices, scaling across hundreds of thousands of devices, real-time analysis, or handling millions of events per second. Each has advantages and disadvantages in analysis performance, reporting performance, scalability, storage, and cost. There are four models to discuss: ‘flat’ central collection, hierarchical, ring, and mesh. As a caveat, none of these deployment models is mutually exclusive. Some regions may deploy a flat model, but send information up to a central location via a hierarchy. These are not absolutes, just guidelines to consider as you design your deployment to solve the specific use cases driving your project. Flat The original deployment model for SIM and log management platforms was a single server that collected and consolidated log files. In this model all log storage, normalization, and correlation occurs within a central appliance. All data collection methods (agent, flow, syslog, etc.) are available, but data is always stored in the same central location. A flat model is far simpler to deploy. All data and policies reside in a single location, so there are no policy or data synchronization issues. But of course ultimately a flat central collection model is limited in scalability, processing, and the quantity of data it can manage. A single installation provides a fixed amount of processing and storage, and reporting becomes progressively harder and slower as data sets grow. Truth be told, we only see this kind of architecture for “checkbox compliance”, predominately for smaller companies with modest data collection needs. The remaining models address the limitations of this base architecture. Hierarchical In the Ring model – or what Mike likes to call the Moat – you have a central SIEM server ringed by many log collection devices. Each logger in the ring is responsible for collecting data from event sources. These log archives are also used to support distributed reporting. The log devices send a normalized and filtered (so substantially reduced) stream of events to the master SIEM device. The SIEM server sitting in the middle is responsible for correlation of events and analysis. This architecture was largely designed to address scalability limitations with some SIEM offerings. It wasn’t cost effective to scale the SIEM engine to handle mushrooming event traffic, so surrounding the SIEM centerpiece with logging devices allowed it to analyze the most critical events while providing a more cost-effective scaling mechanism. The upside of this model is that simple (cheaper) high-performance loggers do the bulk of the heavy lifting, and the expensive SIEM components provide the meat of the analysis. This model addresses scalability and data management issues, while reducing the need to distribute code and policies among many different devices. There are a couple issues with the ring model. The biggest problem remains a lack of integration between the two systems. Management tools for the data loggers and the SIEM may be linked together with some type of dashboard, but you quickly discover the two-headed monster of two totally separate products under the covers. Similarly, log management vendors were trying to graft better analysis and correlation onto their existing products, resulting in a series of acquisitions that provided log management players with SIEM. Either way, you end up with two separate products trying to solve a single problem. This is not a happy “you got your chocolate in my peanut butter,” moment, and will continue to be a thorny issue for customers until vendors fully integrate their SIEM and log management offerings as opposed to marketing bandaids dashboards as integrated products. Mesh The last model we want to discuss is the mesh deployment. The mesh is a group of interrelated systems, each performing full log management and SIEM functions for a small part of the environment. Basically this is a cluster of SIEM/LM appliances; each a functional peer with full analysis, correlation, filtering, storage, and reporting for local events. The servers can all be linked together to form a mesh, depending on customer needs. While this model is more complex to deploy and administer, and requires a purpose-built data store to manage high-speed storage and analysis, it does solve several problems. For organizations that require segregation of both data and duties, the mesh model is unmatched. It provides the ability to aggregate and correlate specific segments or applications on specific subsets of servers, making analysis and reporting flexible. Unlike the other models, it can divide and conquer processing and storage requirements flexibly depending on the requirements of the business, rather than the scalability limitations of the product being deployed. Each vendor’s product is capable implementing two or more of these models, but typically not all of them. Each product’s technical design (particularly the datastore) dictates which deployment models are possible. Additionally, the level of integration between the SIEM and Log Management pieces has an effect as well. As we said in our introduction, every SIEM vendor offers some degree of log management capability, and most Log Management vendors offer SIEM functions. This does not mean that the offerings are fully integrated by any stretch. Deployment and management costs are clearly affected by product integration or lack thereof, so make sure to do your due diligence in the purchase process to understand the underlying product architecture and the limitations and compromises necessary to make the product work in your environment. Share: