Research

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: