Research

Guess what? Back in September we promised to release both the full Data Security Survey results and the raw data, and today is the day. This report is chock full of data security goodness. As mentioned in our original post, here are some highlights: We received over 1,100 responses with a completion rate of over 70%, representing all major vertical markets and company sizes. On average, most data security controls are in at least some stage of deployment in 50% of responding organizations. Deployed controls tend to have been in use for 2 years or more. Most responding organizations still rely heavily on ‘traditional’ security controls such as system hardening, email filtering, access management, and network segregation to protect data. When deployed, 40-50% of participants rate most data security controls as completely eliminating or significantly reducing security incident occurrence. The same controls rated slightly lower for reducing incident severity when incidents occur, and still lower for reducing compliance costs. 88% of survey participants must meet at least 1 regulatory or contractual compliance requirement, with many required to comply with multiple regulations. Despite this, “to improve security” is the most cited primary driver for deploying data security controls, followed by direct compliance requirements and audit deficiencies. 46% of participants reported about the same number of security incidents in the last 12 months compared to the previous 12, with 27% reporting fewer incidents, and only 12% reporting an increase. Over the next 12 months, organizations are most likely to deploy USB/portable media encryption and device control or Data Loss Prevention. Email filtering is the single most commonly used control, and the one cited as least effective. Unlike… well, pretty much anyone else, we prefer to release an anonymized version of our raw data to keep ourselves honest. The only things missing from the data are anything that could identify a respondent. This research was performed completely independently, and special thanks to Imperva for licensing the report. Visit the permanent landing page for the report and data, or use the direct links: Report: The Securosis 2010 Data Security Survey report (PDF) Anonymized Survey Data: Zipped CSV Zipped .xlsx Share:

In our last post we covered organizational structure options for incident response. Aside from the right org structure and incident response process, it’s important to have a few infrastructure pieces (tools) in place, and take some preparatory steps ahead of time. As with all our recommendations in this series, remember that one size doesn’t fit all, and those of you in smaller companies will probably skip some of the tools or not need some of the prep steps. Incident Response Support Tools The following tools are extremely helpful (sometimes essential) for managing incidents. This isn’t a comprehensive list, but an overview of the major categories we see most often used by successful organizations: Multiple secure communications channels: It’s bad to run all your incident response communications over an pwned email server, or to lose the ability to communicate if a cell tower is out. Your incident response team should have multiple communications options – landlines, mobile phones (on multiple carriers if possible), encrypted online tools (via secure systems), and possibly even portable mobile radios. For smaller organizations this might be as simple as GPG or S/MIME for encrypted email (and a list of backup email accounts on multiple providers), or a collaboration Web site and some backup cell phones. Incident management system: Many organizations use their trouble ticket systems to manage incidents, or handle them manually. There are also purpose-built tools with improved security and communications options. As long as you have some central and secure place to keep track of an incident, and a backup option or two, you should be covered. Analysis and forensics tools: As we will discuss later in the series, one of the most critical elements of incident response is the investigation. You need a mix of forensics tools to figure out what’s going on – including tools for analyzing network packet captures, endpoints and mobile devices, and various logs (everything from databases to network devices). This is a very broad category that depends on your skill set, the kinds of incidents you are involved with, and budget. Secure test environment/lab: This is clearly more often seen in larger organizations and those with larger budgets and higher incident rates, but even in a smaller organization it is extremely helpful to have some test systems and a network or two – especially for analysis of compromised endpoints and servers. Network taps and capture/analysis laptops: At some point during an investigation, you’ll likely need to physically go to a location and plug in an inline or passive network tap to analyze part of a network – sometimes even the communications from a single system. This kind of monitoring may not be possible on your existing network – not all routers let you plug in and capture local traffic (heck, you might simply be out of ports), so we recommend you have a small tap and spare laptop (with a large hard drive, possibly external) available. These are very cost-effective and useful even for smaller organizations. Data collection and monitoring infrastructure: As previously discussed. Preparatory Steps Hopefully the idea that tools are only a small part of every security process is starting to set in. Once again, tools are a means to an end. The following steps help set up your infrastructure to support the response process and make the best use of your investment in tools. They cost little aside from time, but will determine the success and/or failure of your response efforts: Define a communications plan: As we mentioned above, it’s important to have multiple communications methods. It’s even more important to have a calling list with all the various numbers, emails, and other addresses you need. Don’t forget to include key contacts outside your team – such as management, key business units, and outside resources like local law enforcement contacts (even for federal agencies) or an outside incident response firm in case something exceeds your own capabilities. Establish a point of contact, promote it, and staff it: It is truly surprising how many organizations fail to provide contact options for users or other IT staff for when something goes wrong. Set up a few options, including phone/email, make sure someone is always there to respond, and promote them. Many organizations route everything through the help desk, in which case you need to educate them on how to identify a potential incident, when to escalate and how to contact you if something looks big enough that adding it to your ticket queue might be a tad too passive. Liaise with key business units: Lay the groundwork for working with different business units before an incident occurs. Let them know who you are, that you are there to help, and what their responsibilities will be if they get involved in an incident (either because it’s affecting their unit, or because they are an outside resource). Liaise with outside resources: If you are on a large dedicated incident response team this might mean meeting with local federal law enforcement representatives, auditors, and legal advisors. For a smaller organization it might mean researching and interviewing some response and investigation firms in case something exceeds your internal response capability and getting to know the folks so they’ll call you back when you need them. You don’t want to be calling someone cold in the middle of an incident. Document your incident response plan: Even if your plan is a single page with a bullet list of steps, have it in writing ahead of time. Make sure all of the folks with responsibility to act in an incident understand what exactly they need to do. In any incident, checklists are your friends. Train and practice: Ideally run some full scenarios on top of training on tools and techniques. Even if you are a single part-time responder, create some practice scenarios for yourself. And practice. And practice. And practice again. It’s a bad time to find a hole in your process, while you are responding to a real incident. Again, we could write an entire paper on building your incident response infrastructure, but these key elements will get you on the

First, for our non-technical readers who want to know more about this Firesheep/sidejacking thing, check out my relatively non-geeky article over at TidBITS. After that, George Ou put together a great sidejacking security scorecard for a double fistful of major online services. He rates each site’s risk across their various services for full hijacking and full and partial sidejacking. Needless to say, very few services fare well. Being a Mac geek, one service not mentioned is Apple’s MobileMe. I did some poking myself, and MobileMe both uses full-session SSL for all sessions, and sets a secure credential cookie so it won’t pass over basic HTTP. Also, the default for all MobileMe sync services is encrypted connections (I don’t have time to confirm with Wireshark, so I’m currently accepting other articles for that statement). See… a reason Apple should buy Twitter 😉 Share:

In our last post we introduced some of the key principles of incident response. Today we will focus on the major roles and organizational structure. Organizational Structure As we return to our IT security focus, the incident response organization consists of two major kinds of resources: those dedicated completely to response, and those with other primary functions who get pulled into incidents as needed depending on the scope or nature. For example, the legal team isn’t necessarily involved in every incident, but clearly plays an important role in anything with legal or regulatory consequences. Also, a smaller organization might have no dedicated resources, while a larger one may have a full time team with defined roles, which deals with multiple overlapping incidents. That’s okay because the structure and system can expand and contract as needed if you follow the ICS principles. Resources These individuals and roles may not spend all their time on incident response, but are the key roles to fill when an incident occurs. One person can fill multiple roles, especially for a smaller incident or organization, but only if they have the right skill set. Team Lead/Incident Commander: The person with overall responsibility and accountability for the direct management of incidents. Typically reports to the CISO, CIO, or even CEO, but following unity of command, should definitely only be accountable to a single manager. When an incident triggers, the first person to respond is the incident lead until they hand off responsibility to someone of equal or higher authority. That way someone is always in charge, even if only for the first few minutes. Command is then handed off to higher and higher levels as needed. When you have a full-time team, the team lead/manager is also responsible for ongoing training, program development, and so on. Network Analysts: Experts in analyzing network packets/traffic, including forensic captures. Analysis includes ongoing monitoring, as well as deeper investigation during incidents. Systems Analysts: Experts in analyzing endpoints and servers. Forensics Analysts: Often a subspecialty of systems analyst, these individuals have deeper training in forensic investigation – which includes both the technical skills for the forensics examination of a system, and the legal training to properly handle evidence if there may be legal considerations (keep in mind that merely firing someone may lead to civil legal action). SIEM/Log Management Analysts: Individuals experienced in monitoring SIEM output and log analysis. Network, Systems, Database, and Application Administrators: Those individuals responsible for the maintenance of systems and networks. It is their responsibility to implement defensive mitigations during and after an incident, and to clean up affected systems. A firewall/IPS administrator might be responsible for closing the entry or egress points being used by the attacker. Systems administrators might roll out patches or configuration changes to host firewalls. A DBA might change account permissions or close out connection methods. This is a rather large bucket, and in most organizations these people operate at the direction of dedicated incident responders or other members of the security team. Legal, Human Resources, and Risk: Any time an incident might involve legal action, employees, or a material costs, you should involve any required combination of these business units. Communications/PR: If an incident has public impact, such as breach notifications, it’s critical to involve those responsible for organizational communications. Accounting/Finance: Incident response costs money. It’s important to include the bean counters early, even if only to pay for the pizza and Red Bull. They can also take responsibility for tracking ongoing incident costs so those of you responsible for stopping and cleaning the problem don’t have to spend your time spinning accounting spreadsheets. Logistics: This role can be a bit nebulous, but includes those responsible for getting the things you need during an incident. It may be someone from finance, the purchasing team, or the security team. Basically it’s someone with a credit card and the authority to use it. They keep people fed, purchase needed hardware and software, and hire outside experts. Communications: Those responsible for making sure responders (and management) can communicate. You might only need this role in a big incident, but make sure you identify people ahead of time who can keep you talking – via cell phones, landlines, email, IM, or whatever other mechanism isn’t totally pwned. Executive Management: We list them last, but they are ultimately responsible for everything in the organization – including incidents. Except in the organization’s very largest incidents, they probably won’t be involved directly. Yes, that is a large number of potential roles, but remember that not all are needed for every incident, and the same person might fill multiple roles based on organization and incident size. For example, in a small or mid-sized organization it isn’t unusual to have the team lead also be the network and systems analyst, and possibly also responsible for cleaning systems or reconfiguring the firewall. In terms of structure, here is one approach:   Finally, don’t forget our key concepts for the organizational structure: People should only report to a single manager. Any manager should only command 3 to 7 other people, ideally 5. The organizational structure fills in resources as needed. You don’t need everything, and what you do need you don’t need all the time. This is a scaffold to build on, not a permanent building. Share:

Imagine you’re a young, skilled techie just starting your career. Maybe you’re fresh out of school, or still in an internship program. Or maybe you’ve been out of school for a few years, working your way up through various companies in the industry. You came from a normal background – possibly you thought about the military at some point, but the allure of working in technology drew you into the private sector. Your skills are solid, you produce at work, and you don’t get into any trouble beyond the usual for your age. Then one day you’re contacted by someone in the government who was sent your way by a buddy from school, or maybe an old professor. They need someone with your skills to help them out with a project. Perhaps it’s to join their agency directly. Or maybe they merely ask you to take a look at something for them – sort of steering you toward a bit of a grey area you wouldn’t normally explore because you don’t want to get in trouble. They tell you it’s a matter of national security, and this is finally your opportunity to give back to your country without having to get shot at. Heck, maybe you spent time in the military and this is a great opportunity to continue your service on a volunteer basis without getting stuck with crappy military pay and travel/deployment requirements. Perhaps you already work for a foreign company your government friends are worried may be a risk to national security. All they want is for you to provide a little information, or maybe plug a USB drive into a system in the office for a few minutes. Or maybe you’ve been working for them on some projects for a while, even if they don’t really pay you and merely “suggest” things for you to look at. You’ve done a good job and they ask you to apply for some work or study abroad in another country. Or for a foreign company in your country. Either way, all they’re asking for is you to further your education and career, maybe helping your country out a little along the way. Ethically this is no different than joining the military, an intelligence agency, or working for a private contractor or university on government projects. You are serving your country while advancing you career – pretty much the best of both worlds. You can’t talk much, if at all, about it with your friends and family, but you sleep at night with the satisfaction that you’re able to blend the needs of your nation with your own personal development goals. Did I mention you grew up outside Shanghai? The thing about espionage is that there are no good guys or bad guys. Merely patriotic individuals living in different places who believe, with complete conviction, that they are doing the right thing and serving the public good. Share:

What a wild few weeks. Talk about been there, done that, got the t-shirt. It all started October 9th, when I finally achieved a goal I’ve been chasing for well over a decade, and completed my first Olympic-distance triathlon. (1.5K swim, 40K bike, 10K run – those are distances, not dollar values). I first learned about triathlon when I was working as a medic for a race in Boulder – probably back in 1992. Being the young, aggressive type, I thought any sport where you write your number on your arms and legs in permanent ink had to be hard core. I spent most of those years competing in a sport where you hit people in the face a lot (I guess that’s kind of hard core too), but in the late 90’s I started traveling a lot for work, which made staying competitive at the level I was at pretty much impossible. Getting frustrated by not being able to make it to the next level (I was competing nationally, but only winning locally), and spending a lot of time injured due to overtraining, I decided to give tri a shot. At least I could run, and often swim or bike, when on the road. But then I got sick… really sick. As in people started calling me “liver boy” because some virus attacked my third favorite part of my body and I couldn’t drink for over a year, never mind sustain hard workouts. But I recovered, started working with a swim coach, and then got distracted by getting married and traveling even more. And then I tore my rotator cuff and had surgery. And then had a kid. And… you get the idea. About 4-5 months ago I was finally injury-free and working out regularly again, and decided to give it another shot. Started riding with a bike group and then joined a masters swim program. I figured another 3 months of training and I’d be ready, but my swim coach pushed me to race and I gave it a shot. I may have finished near the back, but I finished. Easily. And now I’m hooked. Next up is a marathon, and maybe a half-Ironman in a year or so. Then back to the booze. The day after the tri I boarded a plane and headed off to London for RSA Europe. Chris Hoff and I spent a bunch of (platonic) private time together, and it turns out we’ve been working on some extremely complementary research that we’re going to combine for our joint RSA presentation this year. I was also really happy my work passed the sniff test, because Chris spends a heck of a lot more time on cloud than I ever will, and if the research holds up for him I know it’s solid. Then back home for 3 days, and back on a plane to China. I was again presenting with Hoff, and we managed to sneak out for a few hours to visit the Forbidden City. Which is quite welcoming, if you buy a ticket. They have beer. All reds for some reason. On a sour note, the day before the tri I got word that a very good friend died of cancer. Jim launched my technology career and changed the course of my life in ways that are hard to describe. A little over a year ago we started on some collaborative smart grid research, soon after which he found out about the cancer he never recovered from. Jim deserved better. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich in China. In Chinese. Mike quoted in Dark Reading on SIEM and cloud. Dave Lews and David Mortman get a mention in an article on SecTor. Rothman again, this time on consolidation. Rich talks about China and Europe on The Network Security Podcast Favorite Securosis Posts Mike Rothman: The Thing about Espionage. Clearly a fine line between good and bad. But I do think there is right and wrong. And regardless of how you slice it, if it’s called espionage, it’s probably wrong. Adrian Lane: React Faster and Better: Incident Command Principles. Rich: Can we ever break IT?. (We’re light on posts this week, so we’ll leave it at that.) Other Securosis Posts React Faster and Better: Roles and Organizational Structure. SunSec Rises on November 3rd. Incite 10/27/2010: Traffic Ahead. NSO Quant: The Report and Metrics Model. Everything You Ever Wanted to Know about DLP. Favorite Outside Posts Adrian Lane: Robert Graham’s FireSheep analysis. Mike Rothman: Cloud Creates SIEM Blind Spot. Keep in mind the cloud changes the rules for how we do things like monitoring. And I’m quoted. Enjoy the gratuitous pat on my own back… Chris Pepper: iPhone Jailbreak Tool Sets Stage for Mobile Malware. Eric Monti demonstrates that “jailbreak” = “remote root exploit”. Gunnar Peterson: Paypal enables billing and payments on Azure cloud. Project Quant Posts NSO Quant: Index of Posts. NSO Quant: Health Metrics – Device Health. NSO Quant: Manage Metrics – Monitor Issues/Tune IDS/IPS. Research Reports and Presentations Network Security Operations Quant Metrics Model. Network Security Operations Quant Report. Understanding and Selecting a DLP Solution, v2.0. White Paper: Understanding and Selecting an Enterprise Firewall. Understanding and Selecting a Tokenization Solution. Top News and Posts Koobface Worm Targets Java. NSA Declassified Documents. Interesting stuff. Adobe Flash Bug. Perhaps we should leave a permanent reference in the Friday summary for Flash vulnerabilities and just update the link du jour. Idiocy tool. Just to remind people they are insecure. Firesheep launched. Critical Firefox Bug. LinkedIn Drive-by Malware Attack. 19 Arrested in Zeus Malware Bank Heists. Oracle claims Google directly copied Java code. Silver Tail Systems gets In-Q-Tel funding. Banks weak against skimming attacks. PCI Council releases a “sort of” update. 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 Mike Fratto, in response to The Thing About Espionage. Rich, based on your definition, the good guys are us and the bad guys are them for any definition of “us”

For those of you in the Phoenix area, or with way too many frequent flier miles and too much spare time, the Phoenix OWASP chapter is organizing a SunSec meetup after their meeting on November 3rd. It has been a long time since we had a real SunSec, after getting off to a good start a few years ago. This is a great excuse to meet up with local security folks over your favorite frosty beverages. SunSec will be held from 6:30 onward on November 3rd at SunUp Brewing. Share:

I know what you’re thinking to yourself right now: “They promised me a cool series of posts on the cutting edge of incident response, and now we’re talking management principles and boxes on an org chart? What a rip.” But believe it or not, the most important aspect of incident response is the right organization, followed by the right process. How do I know this? Because I’ve been through a ton of incident response training with local and federal agencies, and have directly responded to everything from single-rescuer ski accidents to Hurricane Katrina. (And a few IT things in the middle, but those don’t sound nearly as exciting). While working as an emergency responder I fall under something known as the National Incident Management System, which uses a formalized process and structure called the Incident Command System (ICS). ICS consists of a standard management hierarchy and processes for managing temporary incidents of any size and nature. ICS was originally developed for managing large wildfires in the 1970s, and has since expanded into a national standard that’s also used (and adapted) by a variety of other countries and groups. While our React Faster and Better series won’t to teach you all of ICS, everything we will talk about in terms of process and organization is adapted directly from it. There’s no reason to reinvent the wheel when you have something with over 30 years of battle-hardened testing available. Additionally, those of you in larger companies or verticals like healthcare or public utilities may be required to learn and use ICS in your own incidents. Incident Command System Principles ICS solves a lot of the problems we encounter in incidents. Its focus is on clear communications and accountability, with a structure that expands and contracts as needed, allowing disparate groups to combine even if they’ve never worked together before. ICS includes 5 key concepts: Unity of command: Each person involved in an incident only responds to one supervisor. Common terminology: It’s hard to communicate when everyone uses their own lingo. Common terminology applies to both the organizational structure (with defined roles, like “Incident Commander”, that everyone understands) and use of plain English (or the language of your choice) in incident communications. You can still talk RPC flaws all you want, but when communicating with management and non-techies you’ll use phrases like “The server is down because we were hacked.” Management by objectives: Responders have specific objectives to achieve, in priority order, as defined in a response plan. No running around fighting fires without central coordination. Flexible and modular organization: Your org structure should expand and contract as needed based on the nature and size of the incident. The organizational structure can be as small as a single individual, and as large as the entire company. Span of control: No one should manage less or more than 3-7 other individuals, with 5 being the sweet spot. This one comes from many years of management science, which have repeatedly confirmed that attempting to directly manage more is ineffective, while managing less is an inefficient use of resources. If you want to learn more about ICS you can run through the same self-training course used by incident responders at FEMA’s online training site. Start with ICS 100, which covers the basics. While the process we’ll outline in this series is based on ICS principles, it’s specific to information security incident response. We won’t be using terms like “branch” and “section” because they would distract from our focus, but you can clearly plug them in if you want to standardize on ICS. But if you need the Air Ops branch for a cyberattack, something is very very wrong. For the next post we will focus on three of the key concepts related to organizational structure: unity of command, flexible and modular organization, and span of control, as we talk about the key response roles and structure. Share:

Way back when I converted Securosis from a blog into a company, my very first paper was (no surprise) Understanding and Selecting a DLP Solution. Three or so years later I worried it was getting a little long in the tooth, even though the content was all still pretty accurate. So, as you may have noticed from recent posts, I decided to update and expand the content for a new version of the paper. Version 1.0 is still downloaded on pretty much a daily basis (actually, sometimes a few hundred times a month). The biggest areas of expansion were a revamped selection process (with workflow, criteria, and a selection worksheet) and more details on “DLP features” and “DLP Light” tools that don’t fit the full-solution description. This really encapsulates everything you should need to know up through acquiring a DLP solution, but since it’s already 50+ pages I decided to hold off on implementation until the next paper (besides, that gives me a chance to scrum up some extra cash to feed the new kid). I did, however, also break out just the selection worksheet for those of you who don’t need the entire paper. Not that it will make any sense without the paper. The landing page is here: Understanding and Selecting a DLP Solution. Direct download is at: Whitepaper (PDF) Very special thanks to Websense for licensing the paper and worksheet. They were the very first sponsor of my first paper, which helped me show my wife we wouldn’t lose the house because I quit my job to blog. Share:

So you might have heard there’s this thing called ‘Stuxnet’. I was thinking it’s like the new Facebook or something. Or maybe more like Twitter, since the politicians seem to like it, except Sarah Palin who is totally more into Facebook. Anyway, that’s what I thought until I realized Stuxnet must be a person. Some really bad dude with some serious frequent flier miles – they seem to be all over Iran, China, and India. (Which isn’t easy – I had to get visas for the last two and even a rush job takes 2-3 days unless you live next to the embassy). I know this because earlier today I tweeted: Crap. I just watched stuxnet drive off with my car flipping me the bird. Knew I should have gotten lojack. Then a bunch of people responded: @kdawson: @rmogull Funny, though I would have pictured Stuxnet as more the Studebaker type. @akraut: @rmogull The downside is, Stuxnet can still get your car even after you disable the starter. @st0rmz: @rmogull I heard Stuxnet was running for president with drop database as his running mate. @geoffbelknap: @rmogull Haven’t you seen Fight Club? Turns out you and stuxnet are the same person… That would explain a lot. Especially why my soap smells so bad. But I don’t know how I could pull it off… some random company that promises visas for China has my passport, so it isn’t like I’m able to leave the country. I’m pretty sure I can trust them – the site looked pretty professional, it only crashed once, and there’s a 1-800 number. Besides, it was one of the top 3 Bing results for “China visa” so it has to be safe. And don’t forget to attend the SearchSecurity/Securosis Data Security Event in San Francisco on Oct 26th! On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences James Arlen spoke at the EnergySec conference last week. Rich was mentioned by Alex Williams on ReadWriteWeb about the chance the government will mandate CALEA-type backdoors in any communications or encryption software. Rich also quoted on the same thing at Federal Computer Week Favorite Securosis Posts Adrian Lane: Application Monitoring, Part 1. David Mortman: A Wee Bit on DLP SaaS. Mike Rothman: DLP Light and DLP Features. DLP is evolving and Rich walks you through it. Rich: Proposed Internet Wiretapping Law Fundamentally Incompatible with Security. (Yep, I picked my own. Live with it.) Other Securosis Posts Monitoring up the Stack: Application Monitoring, Part 1. Monitoring up the Stack: DAM, part 2. Incite 9/29/2010: Reading Is Fundamental. NSO Quant: The End is Near! Attend the Securosis/SearchSecurity Data Security Event on Oct 26. Monitoring up the Stack: DAM, Part 1. Favorite Outside Posts Adrian Lane: I know what the law says. Or do I? Interested to see if this holds up to scrutiny. And using the same disclaimer Jack did, the AG’s interpretation does not make sense. David Mortman: Feel the dark side of Intellectual Property Rights. You know you want to… Mike Rothman: Things I hate about security reports, a rant. Most technical folks don’t write very well. It’s a problem and some of these tips are useful. Chris Pepper: CIA Drones May Have Used Illegal, Inaccurate Code. Crazy story & accusations! James Arlen: Good food for thought on the ‘whys’ of the battle: CIO/CSO disconnect. Rich: Why Russia and China think we are fighting cyberwar now. Project Quant Posts NSO Quant: Index of Posts. NSO Quant: Health Metrics – Device Health. Research Reports and Presentations Understanding and Selecting a Tokenization Solution. Security + Agile = FAIL Presentation. Data Encryption 101: A Pragmatic Approach to PCI. White Paper: Understanding and Selecting SIEM/Log Management. 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 LinkedIn Drive-by Malware Attack. 19 Arrested in Zeus Malware Bank Heists. More Stuxnet Details. Tahoe Least Authority File System looks interesting. Microsoft pushes emergency patch for the padding oracle attack. 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 Paul, in response to Understanding DLP Solutions, “DLP Light”, and DLP Features. Rich, nice update! It seems worth amplifying that DLP Light is going to give you multiple reporting points, requiring you to work with each product’s reporting output or console to see what’s going on. SIEM is a solution, but to provide the simplicity the typical DLP Light user might need, the SIEMs are going to need to provide pre-built correlation rules across the DLP Light components. Share: