Research

I’m going to keep this short. Dave Lewis (@gattaca)’s wife was diagnosed with leukemia yesterday. Dave is one of our Contributing Analysts and a hell of a great guy, and while I haven’t met her, everyone says his wife is even better (seems to be a common trend). James Arlen (@myrcurial) posted with details over at Liquidmatrix. You may not know this, but Dave’s wife is the second person in our security community suffering from a blood-related disease (the other being Barkode, a fellow Defcon goon). If you aren’t signed up as a bone marrow donor, do it now. Only 1 in about 540 people in the registry are ever matched, so they need massive numbers. A lot of people used to tell me how cool it was that I was “saving lives” when I was working fire/rescue/ambulance. Donating your bone marrow is a far more effective and direct way to save someone. I’m not sure I actually saved too many lives in those days, but I do know that if I’m a match the odds are damn high someone will live who nature tried to take out. Do it. Now. Share:

Some days I think that in fitness, I’m getting wrong everything I advise people in security. I’ve been an athlete all my life – including some stints competing at a reasonably high (amateur) level. Like the time I went to nationals for my martial art. Cool, eh? Other than the part about getting my butt whipped by a 16-year-old. It seems cutting weight in a sport where knockouts aren’t the goal isn’t necessarily a good thing (me strong… me slow… puny teenager stand still so Hulk can kick in head, pleeze?). But running a startup and having kids seriously crimps my workout style. No more 20 hours of training a week, with entire weekends spent climbing or skiing some mountain. Here are a few of the ways in which I’m an idiot: I’m addicted to the toys. I currently use the Rolex of heart rate monitors (the Polar RS800CX). This thing connects to up to 4 external sensors at once to track my heart rate, position, and (I think) the fungus level of my little toe. Does it make me faster? Er… nope. So I’m spending for capabilities far beyond my needs. But damn, I really want that watch that counts my swimming laps. I bet I’d really use that one every day. I promise – now can I buy it? I’m a binge/purge sort of athlete. Rather than hitting a steady state of training and sticking with it, I’m on and off my program like a child actor at rehab. Oh, I always have great excuses like kids and travel, but as much time as I dedicate to working out, I tend to blow it with a bad month here or there. In other words some days I feel like I flit around worse than a horny butterfly with a narcissism problem. I get hurt. A lot. Then instead of fixing the root cause I freak out that I’m getting out of shape, jump back in at full speed, and get hurt again. I suppose I’m consistent (I have been on this cycle since I was a kid). On the upside, I get my money’s worth from insurance. I have delusions of grandeur. If some dude passes me on the bike I take it personally. Which is inconvenient, since most folks pass me on the bike. Or the run. Or… whatever. So I try to keep up, ignoring the fact that I train in places that attract professional athletes. Yeah, that doesn’t last too long. What really sucks is that as easy as it is to identify these problems, and much as I do (sometimes) work on them, I still make the same mistakes over and over. Okay, age has mellowed me a bit, but I’d quit my job and work out 8 hours a day in a heartbeat… … which I can measure with extreme accuracy thanks to my watch. And heck, after blowing out my knee by hour 6 I can go start work again. This is depressing. I think I’ll go sign up for a race… On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian quoted on DAM market trends. Rich quoted in eWeek Europe. Rich on NetSecPodcast. Adrian’s Dark Reading Post on Federated Data. Mike’s monthly post on Dark Reading: Low And Slow, Persistence, Loud And Proud, And The Fundamentals. Favorite Securosis Posts Mike Rothman: Friction and Security. Wouldn’t it be great if we had KY Jelly for making everyone in IT work better together? Adrian Lane: Incite: The King of the House. Chicken McNuggets for vegetarians. Priceless. Rich: Call off the (Attack) Dogs. Other Securosis Posts (for 2 weeks because we skipped last week’s summary) Security Marketing FAIL: Claims of Risk Reduction. Tokenization vs. Encryption: Healthcare Data Security. Tokenization vs. Encryption: Personal Information Security. How to Encrypt or Tokenize for SaaS (and Some PaaS). Smart Card Laggards. Simple Isn’t Simple. Social Media Security 101. Incite 7/6/2011: Reading Between the Lines. Favorite Outside Posts Mike Rothman: Space Shuttle: good riddance. Count on Rob Graham to look at the situation, not the nostalgia, then bring it around to security. Compelling arguments about complexity and risk. Adrian Lane: How Digital Detectives Deciphered Stuxnet. Best article documenting Stuxnet I have read. Very entertaining. Rich: While not security specific, James Staten at Forrester has a good summary of this week’s cloud announcements. These are all pretty big developments that will affect your datacenter operations. Eventually. Pepper: Evgeny Kaspersky interviewed by Spiegel. Wide ranging and pretty interesting. Research Reports and Presentations Security Benchmarking: Going Beyond Metrics. Understanding and Selecting a File Activity Monitoring Solution. Database Activity Monitoring: Software vs. Appliance. React Faster and Better: New Approaches for Advanced Incident Response. Measuring and Optimizing Database Security Operations (DBQuant). Network Security in the Age of Any Computing. The Securosis 2010 Data Security Survey. Monitoring up the Stack: Adding Value to SIEM. Top News and Posts Anti-Sec is not a cause, it’s an excuse. Azeri Banks Corner Fake AV, Pharma Market via Krebs. SIEM Montage. Gotta have a montage! Anonymous Declares War on .mil. Microsoft Patches Bluetooth Hole in July’s Patch Tuesday. Intego Releases iPhone Malware Scanner. Jury’s still out. Google Removes All .CO.CC Subdomains Over Phishing, Spam Concerns. A Journey to the Cloud (Part 2). Inside the Chinese Way of Hacking. Police: Internet providers must keep user logs. Sony Exec Calls PlayStation Network Hack ‘A Great Experience’. In other news, he’s also really into S&M. Blog Comment of the Week Remember, for every comment selected, Securosis makes a $25 donation to Hackers for Charity. This week’s best comment goes to Michael, in response to Incomplete Thought: HoneyClouds and the Confusion Control. We will not be able to tell if the effectiveness of these Proteus tactics actually works, although I would welcome it. I do actually believe these tactics will work against certain people / bots. I am a big believer in time, the longer time it takes the more a person / bot is prone to give up and move

A few weeks ago I posted on different methods for encrypting IaaS volumes, which tends to be one of the top questions I get about data security in the cloud. Also high on that list is encrypting (or tokenizing) for SaaS and (some) PaaS. I call this the “Salesforce.com Problem”, because more often than not I’m talking to someone on the larger side, specifically about Salesforce.com. Before I go into options, I need to explain why I’m only talking about some PaaS. PaaS covers a very wide range of technologies – from Database as a Service, to things like Google APIs, to full-on application environments like CloudFoundry and Elastic Beanstalk. For this post I’m mostly restricting myself to SaaS-related PaaS like Force.com. In other words, API interfaces to things you can also run completely via a web interface. I know this is a grey line, and in some future post I’ll go more into detail on encrypting for the rest of PaaS. Just recognize that the core architecture described here works for cases beyond this scope, but some of the issues & details may not apply. There are only two options for SaaS encryption: Encrypt it at the SaaS provider. Encrypt it before you send it. To review quickly, when analyzing encryption systems we look at the locations of three components: the data, the encryption engine, and key management. If your SaaS provider handles the encryption on their side, they hold all three components, so this option requires trust in your provider. Yes, there are many subtleties and options that dramatically affect security, but at the core the provider needs the key and the data at some point. The advantage (for you) is simplicity and flexibility. But if you don’t trust your SaaS provider, you’ll need to encrypt on your side… which means increased cost and complexity. If you encrypt it before you send it, there are two options: Encrypt in a client application before uploading the data. Proxy connections and encrypt at the proxy. The first option is common for things like backup applications, but as I mentioned that’s more PaaS – the part we aren’t talking about here. Espcially because the vast majority of the apps I am talking about today are web-based. So most organizations I know which are looking to do this are evaluating proxy-based solutions such as CipherCloud, PerspecSys (maybe – their website sucks and doesn’t mention how they work), and Navajo Systems. These are application-aware web proxies that intercept browser calls to the SaaS provider and replace sensitive data with encrypted or tokenized values. Instead of connecting directly to the SaaS provider, users go through the proxy. You configure it to encrypt or tokenize sensitive data, although instead of defining every field on every form you should be able to say “account number” and have the product automagically replace it everywhere. In some future post I’ll delve into this architecture in more depth, but there are three main challenges to this approach: The product needs to stay totally up to date with any changes with the SaaS provider UI/application. When you are intercepting and rewriting HTML fields on the fly, you really need to know exactly where they are. Users need to connect back through your enterprise, or a trusted web-based host (e.g., running the proxy at Rackspace). For your internal network, this means you’re back to running VPNs. If you host on the outside, you have another party to trust but can handle it with bookmarks or such. If you use a cloud-based web proxy for URL filtering and content security, you might be able to map it up there. You might break application functionality/usefulness. This requires a lot of translation, which affects SaaS features that rely on the protected data. This becomes more of an issue as you protect more fields and data types – the more you obfuscate, the less your SaaS app can process. (It can still process the un-tokenized data). Because of these challenges I tend to regard this proxy approach as a band-aid for SaaS. It’s definitely not ideal, and a heck of a lot of work for the vendor to keep up and running. I believe it makes more sense for PaaS, where you rely more on APIs than HTML interfaces. In all cases I think the web proxy approach is best used for very discrete and limited data – otherwise there is too much potential loss of core application functionality, at which point you might as well stick to internal systems. Share:

I have to admit that some days I have no idea what will resonate with readers. For example, my latest column over at Dark Reading seems to be generating a lot more interest than I expected. For a few months now I’ve been bothered by all the pile-ons every time some organization gets hacked. Sure, some of them really are negligent, and others are simply lazy or misguided, but the rest really struggle to keep the bad guys out. There’s never any shortage of experts with hindsight bias ready to say X attack would have been stopped if they only used Z security best practice. It’s like a bunch of actors sitting around going “I could have done it better”. Frequently this ‘advice’ is applied to a large organization which “should know better”. But these critics consistently fail to account for the cost and complexity of doing anything at scale, or for (universal) resource constraints. This was the inspiration behind Simple Isn’t Simple. Here’s a quote: This isn’t one of those articles with answers. Sure, I can talk all day about how users need to operationalize security more, and vendors need to simplify, consolidate, and improve functionality. But in the end those problems are every bit as hard as everything else I’m talking about and won’t be solved anytime soon. Especially since the economics aren’t overly favorable. But we can recognize that we rely on complex solutions to difficult problems, and blaming every victim for getting hacked isn’t productive. Especially since you’re next. Security is hard. It’s even harder at scale. And we need to stop pretending that even the most basic of practices are always simple, and start focusing on how to make them more effective and easier to manage in a messy, ugly, real world. I thought is was the usual analyst BS, but I guess there’s something more to it… Share:

It won’t surprise any of you to learn that I don’t follow Fox News on Twitter. I know, I can see the shock in your eyes, but I’m not the biggest fan of our friends on the right. Actually, I hate all 24 hour news stations – Fox biased to the right, MSNBC to the left, and CNN to the stupid. So I missed their announcement of to the demise of our commander in chief. It seems one of their Twitter accounts was hacked, and the attackers had a little fun with some bogus tweets. If you read this blog you probably know everything I’m about to write, but it’s probably a good time to review it anyway. If you use these services for business purposes, there are a few precautions to put in place: If you use social media in your business, make sure you set up accounts (or use your personal accounts) to monitor your official account. Be very cautious in how you handle your account credentials (who you give them to, how they are secured, etc.). The list of people with access should definitely be very short. Use an OAuth-based service or application to allow employees to tweet to your account without having to give them your account password. This is how most Twitter clients work today, for example. If you are large enough, talk to your provider ahead of time to understand how to report problems, and who to report them to. The last thing you want to be doing is hanging out waiting for a help desk person to see your request in the queue. Make contact, get a name, and establish a validation process to prove you are the owner of the account in an incident. You’ll also use this process if an employee goes rogue. Simple stuff, but I suspect very few businesses follow these basics. Share:

I don’t really know how to take this article on Eugene Kaspersky’s interview at InfoSec The iPhone will be niche in 5 years because it’s closed? We should have databases of smartphone users? I’m really hoping some if it is few translation and context issues, which is quite possible. And I’m glad he didn’t say the iPhone is less secure because it’s closed, which is a common trope from a few folks in the AV world. I believe that closed systems can actually be better for security, when designed properly. Otherwise why are we all obsessed with FIPS-140 tamper resistance? Perhaps it’s because ‘closed’ has multiple meanings – and we need to differentiate between three of them for security: Closed as in locked down. The platform uses controls to restrict what can run on it. Closed as in proprietary. In other words, not Open Source. Closed as in super secret. Code/hardware/etc. is hidden and/or obfuscated. The common argument for proprietary or hidden being bad is that you can’t see what’s inside and evaluate it (or fix it). I do think this is true for things like crypto algorithms, but not for complex applications. A little obfuscation could help security, and to be honest your odds of crawling the code and finding problems are pretty low. Especially since dynamic analysis/fuzzing are so effective at finding holes. There is a ton of testing you can do without access to the source code. But the closed I think is important to security is the locked platform. If done properly, this reduces attackers’ ability to run arbitrary commands/code, and thus improves security. This assumes the vendor is responsive when cracks are discovered. So back to the iPhone. It sufferings far fewer real-world security incidents than Android because it’s closed. It’s not perfect, but how many apps has Apple had to pull? Compared to Google? If they can even pull them (there are other marketplaces, remember)? And hardware controls make it pretty darn hard to perform deep exploitation (so some really smart researchers tell me). In an interview last week I suggested that Apple should do the same thing with the App Store on Macs, but there make it optional. Opt in and the system will only let you install App Store apps. Us geeks can opt out and continue to do what we want. I suspect this would go a heck of a long way toward protecting nontechnical users, especially from things like phishing attacks. Anyway, just some random thoughts. And keep them in context – I’m not saying closed is always better, but that it can be. Share:

Encrypting IaaS storage is a hot topic, but it’s time to drop the esoterica and provide some technical details. I will use a lot of terminology from last week’s post on IaaS storage options, so you should probably read that one first if you haven’t already. Within the cloud you have all the same data storage options as in traditional infrastructure – from the media layer all the way up to the application. To keep this post from turning into a white paper, we will limit ourselves to volume storage, such as Amazon Elastic Block Storage (EBS), OpenStack volumes, and Rackspace RAID volumes. We’ll cover object storage and database/application options in future posts. Before we delve into the technology we should cover the risk/use cases. Volume encryption is very interesting, because it highlights some key differences between cloud and traditional infrastructure. In your non-cloud environment the only way for someone to steal an entire drive is to walk in and yank it from the rack, or plug in a second drive, make a byte-level copy, and walk out with that. I’m simplifying a bit, but for the most part they would need some type of physical access to get the entire drive. In the cloud it’s very different. Anyone with access to your management plane (with sufficient rights) can snapshot a volume and move it around. It only takes 2-3 command lines to snapshot a drive off to object storage, make it public, and then load it up in a hostile environment. So IaaS encryption: Protects volumes from snapshot cloning/exposure. Protects volumes from being explored by the cloud provider (and private cloud admins). Protects volumes from being exposed by physical loss of drives (more for compliance than a real-world security issue). Personally I worry much more about management plane/snapshot abuse than a malicious cloud admin. Now let’s delve into the technology. The key to evaluating data at rest encryption is to look at the locations of the three main components: The data (what you are encrypting). The encryption engine (the code/hardware that encrypts). The key manager. For example, our entire Understanding and Selecting a Database Encryption or Tokenization Solution paper is about figuring out where these bits to satisfy your requirements. IaaS volume encryption is very similar to media encryption in physical infrastructure. It’s a coarse control designed to encrypt entire ‘drives’, which in our case are virtual instead of physical. Whenever you mount a cloud volume to an instance it appears as a drive, which actually makes our lives easier. This protects against admin abuse, because the only way to see the data is to go through a running instance. It protects against snapshot abuse, because cloning only gets encrypted data. Today there are three main models: Instance-managed encryption: The encryption engine runs within the instance, and the key is stored in the volume but protected by a passphrase or public/private keypair. We use this model in the CCSK cloud security training – the volume is encrypted with the standard Linux dm-crypt (managed by the cryptsetup utility), with the key protected by a SHA-256 passphrase on the volume. This is great for portability – you can detach and move the volume anywhere you need, or even snapshot it, and can only open it if you have the passphrase. The passphrase should only be in volatile memory in your instance, which isn’t recorded during a snapshot. The downside is that if you want to automatically mount volumes (say as you spin up additional instances or if you need to reboot) you must either embed the passphrase/key in the instance (bad) or rely on a manual process (which can be automated with cloud-init, but that’s another big risk). You also can’t really build in integrity checking (which we will discuss in a moment). This method isn’t perfect but is well suited to many use cases. I don’t know of any commercial options, but this is free in many operating systems. Externally managed encryption The encryption engine runs in the instance, but the keys are managed externally and issued to the instance on request. This is more suitable for enterprise deployments because it scales far better and provides better security. One great advantage is that if your key manager is cloud aware, you can run additional integrity checks via the API and get quite granular in your policies for issuing keys. For example, you can automate key issuance if the instance was launched from a certain account, has an approved instance ID, or other criteria. Or you can add a manual check into the process where the instance requests the key and a security admin has to approve it, providing excellent separation of duties. The key manager can run in any of 3 locations: as dedicated hardware/server, as an instance, or as a service. The dedicated hardware or server needs to be connected to your cloud and is used only in private/hybrid clouds – its appeal is higher security or convenient extension of an existing key management deployment. Vormetric, SafeNet, and (I believe) Voltage offer this. Running in an instance is more convenient and likely relatively secure if you don’t need FIPS-140 certified hardware, and trust the hypervisor it’s running on. No one offers this yet, but it should be on the market later this year. Lastly, you can have a service manage your keys, like Trend SecureCloud. Proxy encryption In this model you connect the volume to a special instance or appliance/software, and then connect your instance to the encryption instance. The proxy handles all crypto operations, and may keep keys either onboard or in an external manager. This model is similar to the way many backup encryption tools work. The advantage is that even the engine runs (hopefully) in a more secure environment. Porticor is an option here. This should give you a good overview of the different options. One I didn’t mention, since I don’t know of any commercial or freeware options, is hypervisor-managed encryption. Technically you could have

Ever hear of File Activity Monitoring? You know, that cool new data security tech I published a white paper on? This Wednesday at 11 PT I will be giving a webinar on FAM (sponsored by Imperva – a guy’s gotta eat). I’ll cover the basics of the technology, why it’s useful, and some deployment scenarios/use cases. I do think this is something most of you are going to be looking at over the next few years (even if you don’t buy it), so might as well get started early 🙂 If you’re interested, you can register now. Share:

I started writing up a post on IaaS encryption options and quickly realized I should probably precede it with a post outlining the IaaS storage options first. One slightly confusing bit is that IaaS storage really falls into two categories: storage as a service where the storage itself is the product, and storage for IaaS compute instances, where the storage is tied to running virtual machines. IaaS storage options include: Raw storage: As far as I can tell, this is only available for private clouds, and not on every platform. For certain high-speed operations it allows you to map a virtual volume to dedicated raw media. This skips abstraction layers for increased performance, but you lose many of the advantages of cloud storage. It’s rarely used, and may only be available on VMWare. Volume storage: The easiest way to think of volume storage is as a virtual hard drive for your instances. There are a few different architectures, but volumes are typically a clump of assigned blocks (often stored redundantly in the back end). When you create a volume the volume controller assigns the blocks, distributes them onto the physical storage infrastructure, and presents them as a raw volume. You then need to attach the volume to an instance, install partitions and file systems on it, and manage it like a drive. Although it presents as a single drive to your instance, volume storage is more like RAID – each block is replicated in multiple locations on different physical drives. Amazon EBS and Rackspace RAID volumes are examples. Object storage: Object storage is sometimes referred to as file storage. Rather than a virtual hard drive, object storage is more like a file share. Object storage performs more slowly, but is more efficient. The back end can be structured in different ways – most often a database / file system hybrid, with a bunch of processes to keep track of where everything is stored, replication, cleanup, and other housekeeping functions. Amazon S3, Rackspace Cloud Files, and OpenStack Swift are examples. For our purposes, we will consider cloud databases part of PaaS. So when we talk about IaaS storage, we are mostly talking volumes and objects. Volumes are like hard drives, and object storage is effectively a file share with a nifty API. An additional piece is important for running IaaS instances: image management. Images (such as Virtual Machine Images and Amazon Machine Images) can be stored in a variety of ways, but most often in object storage because it’s cheaper and more efficient. Layered on top is an image manager such as OpenStack Glance, which tracks the images and ties them into the compute management plane. When you create an IaaS instance you pick an image, which the image manager then pulls from object storage and streams to the hypervisor/system that will host the instance. But the image manager doesn’t need to use object storage. Glance, for example, can use pretty much anything – including local file storage, which is particularly handy in test environments. Lastly, we can’t forget about snapshots. Snapshotting an instance essentially makes a block-level copy of the volume it’s running on or attached to. Snapshot creation is just about instantaneous, but they need not be kept as volumes. The snapshot may be sent off to more-efficient object storage instead. If you want to turn a snapshot back into a volume you send a request, storage is assigned, and the image streams back into volume storage from object storage; you can then attach it to instances. You’ll notice some nice interplays between object and volume storage to keep things as efficient as possible. It’s one of the cool things about cloud computing. Hopefully this gives you a better idea of how the back end works. In a future post I will talk about volume encryption and the relationship between volume and object storage. Share:

There’s something I need to admit. I’m not proud of it, but it’s time to get it off my chest and stop hiding, no matter how embarrassing it is. You see, it happened way back in 1994. I was working as a paramedic at the time, so a lot of my decisions were affected by sleep deprivation. Oh heck – I’ll just say it. One day I walked into a store, pulled out my checkbook, and bought a copy of OS/2 Warp. To top it off I then installed it on the only (dreadfully underpowered) laptop I could afford at the time. I can’t really explain my decision. I think it was that geek hubris most of us pass through at some point in our young lives. I fell for the allure of a technically superior technology, completely ignoring the importance of the application ecosystem around it. I tried to pretend that more efficient memory management and true multitasking could make up for little things like being limited to about 1.5 models of IBM printers. It wouldn’t be the last time I underestimated the power of ecosystem vs. technology. I’m also the guy who militantly avoided iPods in favor of generic MP3 players. I was thinking features, not design. Until I finally broke down and bought my first iPod, that is. The damn thing just worked, and it looked really nice in the process, even though it lacked external storage. After Dropbox’s colossal screwup I started looking at alternatives again. I didn’t need to look very hard, because people emailed and tweeted some options pretty quickly. A few look very interesting, and they are all dramatically more secure. The problem is that none of them look as polished or simple – never mind as stable. I’m not talking about giving up security for simplicity – Dropbox could easily keep their current simplicity and still encrypt on the client. I mean that Dropbox nailed the consumer cloud storage problem early and effectively, quickly building up an ecosystem around it. It’s this ecosystem that provides the corporate-level stability all the alternatives lack. These alternatives do have a chance to make it if they learn the lessons of Dropbox and Apple; and pay as much attention to design, simplicity, and ecosystem as they do to raw technology. But none of them seem quite that mature yet, so I will mostly watch and play rather than dump what I’m doing and switch over completely. Which is too bad. Because I’m starting to regret paying for Dropbox based on their latest error. If they address it directly, then it won’t be a long term problem at all. If they don’t I’ll have to eat my own dog food and move to an alternative provider that meets my minimum security requirements, even though they are at greater risk of failing. Which also forces me to always have contingency options so I don’t lose my data. Sigh. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich quoted on RSA at The Street. Rich at Newsweek on Mac Defender. Rich on iPad security at Macworld. (Yes, I’m a major media whore this week). Our Dropbox story bit BoingBoing. Adrian over at Network Computing on GreenSQL. Favorite Securosis Posts Adrian Lane: How to Encrypt Your Dropbox Files, at Least until Dropbox Wakes the F* up. Great product but they need to fix both server and client side security architectures. David Mortman: Tokenization vs. Encryption: Payment Data Security. Rich: My older Securing Cloud Data with Virtual Private Storage post. Other Securosis Posts 7 Myths, Expanded. IaaS Storage 101. Is Your Email Address Worth More Than Your Credit Card Number? New White Paper: Security Benchmarking: Going Beyond Metrics. Favorite Outside Posts Adrian Lane: Creating Public AMIs Securely for EC2. This is difficult to do correctly. David Mortman: Security Expert, Gunnar Peterson, on Leveraging Enterprise Credentials to connect with Cloud applications. Rich: Why Sony is no surprise. A true must-read. Simplicity doesn’t scale. Chris Pepper: Fired IT manager hacks into CEO’s presentation, replaces it with porn. I’m more amused than the fired manager or the CEO. Research Reports and Presentations Security Benchmarking: Going Beyond Metrics. Understanding and Selecting a File Activity Monitoring Solution. Database Activity Monitoring: Software vs. Appliance. React Faster and Better: New Approaches for Advanced Incident Response. Measuring and Optimizing Database Security Operations (DBQuant). Network Security in the Age of Any Computing. The Securosis 2010 Data Security Survey. Monitoring up the Stack: Adding Value to SIEM. Top News and Posts Dropbox Left User Accounts Unlocked for 4 Hours Sunday. Feeling like a sooper-genius for encrypting my stuff Saturday. Antichat Forum Hacker Breach. Shocker – they used weak passwords. Teen Alleged Member of LulzSec. Interesting Graphic on data breaches. Toward Trusted Infrastructure for the Cloud Era. Pentagon Gets Cyberwar Guidelines. New views into the 2011 DBIR. Mozilla retires Firefox 4 from security support. Northrop Grumman constantly under attack by cyber-gangs. Analysis: LulzSec trackers say authorities are closing. WordPress.com hacked. Amazon’s cloud is full of holes. 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 Mark, in response to Is Your Email Address Worth More Than Your Credit Card Number?. Spot on Rich. NIST already defines Email address as PII under 800-122. It seems everyone’s turning a bind eye to the contextual aspect today – conveniently. http://csrc.nist.gov/publications/nistpubs/800-122/sp800-122.pdf “One of the most widely used terms to describe personal information is PII. Examples of PII range from an individual’s name or email address to an individual’s financial and medical records or criminal history.” In my opinion, what’s often worse is that an email address is also now a primary index to social networking sites (facebook, LinkedIn etc) which immediately presents more gold to mine for a spearphishing attack to present a APT payload – even if the attacker doesn’t have complete access, its all too easy these days to build a personal profile from one data