Research

Securosis is a funny company. We have a very different work objectives and time requirements compared to, say, a software company. And the work we do as analysts is way different than an IT admin or security job. We don’t punch the clock, and we don’t have bosses or corporate politics to worry about. We don’t have a ‘commute’ per se, either, so all of the changes since I left my last company and joined have been for the better and do not take long to adapt to. Another oddity I recently learned was that our vacations days are allocated in a very unusual way: it turns out that our holiday calendar is completely variable. Yes, it is based upon important external events, but only of quasi-religious significance. Last week I learned that all Star Trek premier days are holidays, with a day off to ‘clear your mind’ and be ready to enjoy yourself. This week I learned we get 1/2 days off the afternoon of a Jimmy Buffet concert, and most of the day off following a Jimmy Buffet concert. You see the wisdom in this policy the morning after the show. Last night Rich, I, and his extended family went to Cricket Pavilion for Buffett’s only Phoenix show. I won’t say how many of us actually packed into that tiny motor home for the trip down in case someone from the rental company reads the blog, but let’s say that on a hot summer afternoon it was a very cozy trip. And with something like 24 beers on ice per person, we were well prepared. This was my first Buffett concert and I really enjoyed it! We ended up going in late, so we were a long way from the stage, but that did not stop anyone from having a good time. I will be marking next year’s holiday calendar when I learn his next local tour dates. As this is a Securosis holiday, today’s summary will be a short one. And now for the week in review: Webcasts, Podcasts, Outside Writing, and Conferences Martin and Rich hit a major milestone with the 150th Network Security Podcast, which also hit the 500,000 download mark! Congratulations guys! Favorite Securosis Posts Rich: Adrian’s post on Open Invitation to the University of California at Berkeley IT Dept. Adrian: Rich’s post on The Data Breach Triangle. Data security is not always about preventing the attack. Favorite Outside Posts Adrian: Even though it came out last week, I just ran across Glenn Fleishman’s post on securing home networks. Rich: The PaulDotCom post on SQL Injection with sqlmap. Top News and Posts The cost of patching. Adobe Reader JavaScript Vulnerability at CERT. DoD Official Charged With Handing Over Classified Data To China. Security updates by Apple. Nearly half of IT security budgets deemed insufficient. Only half? Really? Did you see that Obama spoke at the ASU graduation ceremony? Did you see that the opening act was Alice Cooper? Rock on! Blog Comment of the Week This week’s best comment was from Martin McKeay in response to The Data Breach Triangle: Perhaps ‘access’ would be a better term to use than ‘exploit’. A malicious outsider needs an exploit to access the data, whereas a malicious insider usually has access to the data to begin with. You need the loot, a way to get the loot and a way to escape with the loot when you’ve got it. Is there any such thing as a ‘crime triangle’? I’m going to have to give this a bit more thought; I believe you have the right idea, but I think this somehow defines the data breach elements too narrowly. I haven’t figured out exactly what leads me in that direction yet, but it will come to me. Share:

You probably heard the news last week that hackers have infiltrated restricted computer databases at Cal Berkeley. 160,000 current and former students and alumni personal information “may” have been stolen. The University says social security numbers, health insurance information and non-treatment medical records dating back to 1999 were stolen. Within that data set was 97,000 Social Security Numbers, from both Berkeley and Mills College students who were eligible for medical treatment. I am going to make an educated guess that this was a database either for or located at Cowell Hospital, but there are [very few other details available. Not unusual in data breach cases, but annoyingly understandable and the reason I do not post comments on most data breaches. This one is different. This is an offer to help UC Berkeley with their data security challenge. As a security professional and Berkeley alumnus, I want to offer my services to assist with security and product strategy to ensure this does not happen again. Free of charge. I am willing to help. This is a service Securosis provides: free strategic consultation services to end users. Within reason, of course, but we do. So I am extending an open offer of assistance to the University. In 2008, when I was still with my previous employer, we had a couple meetings with IT staff members at UC Berkeley for some of the security challenges and to see if our products were of interest to them. As most initial conversations go, we covered as much background about the environment and goals as we could. While the people we were speaking with were smart and highly educated, the questions they asked and the order of their priorities suggested that they were naive about security. I do not want to provide too many details on this out of respect for confidentiality, but the types of products they were reviewing I would have assumed were already in place, and policies and procedures would have been more evolved. I can even hear Adam Dodge in the back of my head saying “Well … education is a lot different than the private sector”. He’s right, and I get that, but for an organization that has already had a data breach through a lost laptop in March 2005, I expected that they would have gotten ahead of the curve. The liability here goes all the way up to the UC Regents, and this is a problem that needs to be addressed. My goal is not to insult the IT staff at UC Berkeley. Just look at the Privacy Rights web site, or the Open Security Foundation, and you will see that they are no better and no worse than any other university in the country. What pisses me off is that my alma mater, one of the best computer schools in the world, is below average in their data security! Come on!!! This is Berkeley we are talking about. UCLA, OK, I could understand that. But Berkeley? They should be leading the nation in IT security, not the new poster child for University data breaches. Berkeley has among its student body some of the smartest people in computer science, who gather there from all over the world to learn. When I was there if you wanted to know about inner details of the UNIX kernel, say at 2:30 in the morning, there was someone in the lab who could answer your question. Want to know the smallest of details on network architecture? The ‘finger’ daemon could point you to the guys who had all the answers. You might need to pull them away from Larn for a couple minutes, but they knew scary levels of detail on every piece of software and hardware on the campus. It is no different today, and they are clearly not leveraging the talent they have effectively. So go ahead. Ask for help. The university needs assistance in strategy and product suitability analysis, Securosis can help, and we will do it for free. Now I am going to have the Cal fight song in my head for the rest of the day. Share:

This is the next installment in what is now officially the longest running blog series in Securosis history: Database Encryption. In case you have forgotten, Rich provided the Introduction and the first section on Media Protection, and I covered the threat analysis portion to help you determine which threats to consider when developing a database encryption strategy. You may want to peek back at those posts as a refresher if this is a subject that interests you, as we like to use our own terminology. It’s for clarity, not because we’re arrogant. Really! For what we are calling “database media protection” as described in Part 1, we covered the automatic encryption of the data files or database objects through native encryption built into the database engine. Most of the major relational database platforms provide this option, which can be “seamlessly” deployed without modification to applications and infrastructure that use the database. This is a very effective way to prevent recovery of data stored on lost or stolen media. And it is handy when you have renegade IT personnel who hate managing separate encryption solutions. Simple. Effective. Invisible. And only a moderate performance penalty. What more could you want? If you have to meet compliance requirements, probably a lot more. You need to secure credit card data within the database to comply with the PCI Data Security Standard. You are unable to catalog all of the applications that use sensitive data stored in your database, so you want to stop data leakage at the source. Your DBAs want to be ‘helpful’, but their ad-hoc adjustments break the accounting system. Your quality assurance team exports production data into unsecured test systems. Medical records need to be kept private. While database media protection is effective in addressing problems with data at rest, it does not help enforce proper data usage. Requirements to prevent misuse by credentialed users or compromised user accounts, or enforce separation of duties, are outside the scope of basic database encryption. For these reasons and many others, you decide that you need to protect the data within the database through more granular forms of database encryption; table, column, or row level security. This is where the fun starts! Encrypting for separation of duties is far more complex than encrypting for media protection; it involves protecting data from legitimate database users, requiring more changes to the database itself. It’s still native database encryption, but this simple conceptual change creates exceptional implementation issues. It will be harder to configure, your performance will suffer, and you will break your applications along the way. Following our earlier analogy, this is where we transition from hanging picture hooks to a full home remodeling project. In this section we will examine how to employ granular encryption to support separation of duties within the database itself, and the problems this addresses. Then we will delve into the problems you will to run into and what you need to consider before taking the plunge. Before we jump in, note that each of these options are commonly referred to as a ‘Level’ of encryption; this does not mean they offer more or less security, but rather identifies where encryption is applied within the database storage hierarchy (element, row, column, table, tablespace, database, etc). There are three major encryption options that support separation of duties within the database. Not every database vendor supports all of these options, but generally at least two of the three, and that is enough to accomplish the goals above. The common options are: Column Level Encryption: As the name suggests, column level encryption applies to all data in a single, specific column in a table. This column is encrypted using a single key that supports one or more database users. Subsequent queries to examine or modify encrypted columns must possess the correct database privileges, but additionally must provide credentials to access the encryption/decryption key. This could be as simple as passing a different user ID and password to the key manager, or as sophisticated as a full cryptographic certificate exchange, depending upon the implementation. By instructing the database to encrypt all data stored in a column, you focus on specific data that needs to be protected. Column level encryption is the popular choice for compliance with PCI-DSS by restricting access to a very small group. The downside is that the column is encrypted as a whole, so every select requires the entire column to be deencrypted, and every modification requires the entire column to be re-encrypted and certified. This is the most commonly available option in relational database platforms, but has the poorest performance. Table / Tablespace Encryption: Table level encryption is where the entire contents of a table or group of tables are encrypted as one element. Much like full database encryption, this method protects all the data within the table, and is a good option when all more than one column in the table contains sensitive information. While it does not offer fine-grained access control to specific data elements, it more efficient option than column encryption when multiple columns contain sensitive data, and requires fewer application and query modification. Examples of when to use this technique include personally identifiable information grouped together – like medical records or financial transactions – and this is an appropriate approach for HIPAA compliance. Performance is manageable, and is best when the sensitive tables can be fully segregated into their own tablespace or database. Field/Cell/Row Level Encryption, Label Security: Row level encryption is where a single row in a table is encrypted, and field or cell level encryption is where individual data elements within a database table are encrypted. They offer very fined control over data access, but can be a management and performance nightmare. Depending upon the implementation, there might be one key used for all elements or a key for each row. The performance penalty is a sharp limitation, especially when selecting or modifying multiple rows. More commonly, separation of duties is supported by label security.

I first got to know Martin McKeay back when I started blogging. The Network Security Blog was one of the first blogs I found, and Martin and I got to know each other thanks to blogging. Eventually, we started the Security Blogger’s Meetup together. After I left Gartner, Martin invited me to join him as a guest-host on the Network Security Podcast, and it eventually turned into a permanent position. I’ve really enjoyed both podcasting, and getting to know Martin better as we moved from acquaintances to friends. Last night was fairly monumental for the show and for Martin. We recorded episode 150, and a few hours later hit 500,000 total downloads. No, we didn’t do anything special (since we’re both too busy), but I think it’s pretty cool that some security guy with a computer and a microphone would eventually reach tens of thousands of individuals, with hundreds of hours of recordings, based on nothing more than a little internal motivation. Congratulations Martin, and thanks for letting me participate. Now on to the show: This is one of those good news/bad news weeks. On the bad side, Rich messed up and now has to retake an EMT refresher course, despite almost 20 years of experience. Yes, it’s important, but boy does it hurt to lose 2 full weekends learning things you already know. On the upside, this is, as you probably noticed from the title of the post, episode 150! No, we aren’t doing a 12 hour podcast like Paul and Larry did (of PaulDotCom Security Weekly), but we do have the usual collection of interesting security stories. Network Security Podcast, Episode 15, May 12, 2009 Time: 38:18 Show Notes UC Berkeley loses 160K healthcare records. Most people think they will be hacked. Duh. Heartland spends $12.6M on breach response. Possibly half going to MasterCard fines. Rich debuts the Data Breach Triangle, which Martin improves. Tonight’s Music: Neko Case with People Got a Lotta Nerve. Who knew Neko Case had a podsafe MP3 available? Share:

Hey folks, While we aren’t posting everything related to Project Quant here on the site, I will be putting up some major milestones. One of the biggies is to develop a survey to gain a better understanding of how organizations manage their patching processes. I just completed my first rough draft of some survey questions over in the forums. The main goal is to understand to what degree people have a formal process, and how their processes are structured. I consider this very rough and in definite need of some help. Please pop over to this thread in the forums and let me know what you think. In particular I’m not sure I’ve actually captured the right set of questions, based on our priorities for the project (I know survey writing is practically an art form). Please let us know what you think. Once we lock it down we will use a variety of mechanisms to get the survey out there, and will follow it up with some focused interviews. Share:

I’d like to say I first became familiar with fire science back when I was in the Boulder County Fire Academy, but it really all started back in the Boy Scouts. One of the first things you learn when you’re tasked with starting, or stopping, fires is something known as the fire triangle. Fire is a pretty fascinating process when you dig into it. It demonstrates many of the characteristics of life (consumption, reproduction, waste production, movement), but is just a nifty chemical reaction that’s all sorts of fun when you’re a kid with white gas and a lighter (sorry Mom). The fire triangle is a simple model used to describe the elements required for fire to exist: heat, fuel, and oxygen. Take away any of the three, and fire can’t exist. (In recent years the triangle was updated to a tetrahedron, but since that would ruin my point, I’m ignoring it). In wildland fires we create backburns to remove fuel, in structure fires we use water to remove heat, and with fuel fires we use chemical agents to remove oxygen. With all the recent breaches, I came up with the idea of a Data Breach Triangle to help prioritize security controls. The idea is that, just like fire, a breach needs three elements. Remove any of them and the breach is prevented. It consists of: Data: The equivalent of fuel – information to steal or misuse. Exploit: The combination of a vulnerability and/or an exploit path to allow an attacker unapproved access to the data. Egress: A path for the data to leave the organization. It could be digital, such as a network egress, or physical, such as portable storage or a stolen hard drive. Our security controls should map to the triangle, and technically only one side needs to be broken to prevent a breach. For example, encryption or data masking removes the data (depending a lot on the encryption implementation). Patch management and proactive controls prevent exploits. Egress filtering or portable device control prevents egress. This assumes, of course, that these controls actually work – which we all know isn’t always the case. When evaluating data security I like to look for the triangle – will the controls in question really prevent the breach? That’s why, for example, I’m a huge fan of DLP content discovery for data cleansing – you get to ignore a whole big chunk of expensive security controls if there’s no data to steal. For high-value networks, egress filtering is a key control if you can’t remove the data or absolutely prevent exploits (exploits being the toughest part of the triangle to manage). The nice bit is that exploit management is usually our main focus, but breaking the other two sides is often cheaper and easier. Share:

CNET is reporting that last week the European Commission is proposing consumer protection laws be applied to software. Mentioning specifically anti-virus and video game software, commissioners Viviane Reding and Meglena Kuneva have proposed that EU consumer protections for physical products be extended to software in an effort to protect customers and implying that consumers would use more and buy more if the software was better. “extending the principles of consumer protection rules to cover licensing agreements of products like software downloaded for virus protection, games, or other licensed content,” according to the commissioners’ agenda. “Licensing should guarantee consumers the same basic rights as when they purchase a good: the right to get a product that works with fair commercial conditions.” In reality I am guessing some politician took notice that few in the voting public are for crappy software. Or perhaps they took notice that anti-virus software does not really stop malware, spyware, phishing and viruses as advertised? Or perhaps they still harbor resentment for “ET: The Game”? Who knows. I had to laugh at Business Software Alliance Director Francisco Mingorance’s comment that “Digital Content is not a tangible good and should not be subject to the same liability as toasters.” He’s right. If your toaster is mis-wired it could kill you. Or if you used it in the bathtub for that matter. If people are not happy with a $45.00 piece of software, and no one died from its use, do you think anyone is going to prosecute? Sure, Alvin & the Chipmunks really sucked; caveat emptor! Even if you should find a zealous prosecutor, if something should go wrong with the software, who will get the blame? The vendor for producing the code? The customer for they way they deployed, configured, and modified it? How would this work on an application stack or in one of the cloud models? Was the software fully functional to the point in time specification, but the surrounding environment changes created a vulnerable condition? If anti-virus stops one virus but not another, should it be deemed defective? There is not enough time, money or interest to address these questions, so the legislative effort is meaningless. I appreciate the EC’s frustration and admire them for wanting to do something about software quality and ‘efficacy’, but the proposal is not viable. Granted there are the few software developers who look upon their craft to build the best the best possible software, but most companies will continue to sell us the crappiest product that we will still buy. The only people who will benefit are the lawyers who will be needed to protect their clients from liability; you think EULAs are bad now, you have seen nothing yet! Do not be surprised if you see the software quality bandwagon rumble through Washington D.C. as well, but it will not make security software better because you cannot effectively legislate software quality. Meaningful change will come when customers vote with their dollars. Share:

Someone has finally captured my vision of what a data centric society without privacy rights looks like. This video is really funny … and scary. Law enforcement and drug companies have been doing this for years. And even if it is not public knowledge, many insurance companies are doing this as well. Orwell had no idea how deep the rabbit hole goes. Share:

A lot of security related news this week in the mainstream press. What with Nuclear Secrets being a fringe benefit to eBay shopping. Other big names like McAfee exposing users to a CSRF and MI-6’s operations nixed on a missing memory stick. With security this bad, who needs Chinese hackers? What gets me is the simple stuff that gets missed. Unencrypted hard drives and memory sticks. WTF? Fighter jet plans and power grid control systems on networks, directly or indirectly attached to the Internet? Whoever thought that was a good idea needs to be discovered and fired. Anyway, enough negativity, and you don’t need to read my rants when there are this many good articles to read this week. The funniest thing I saw all week was from last night: Rich and I were having dinner, waiting for the 10:00 PM premiere of the new Star Trek movie, when Rich decided he was going to have some fun and do some ‘live #startrek’ tweets. Not real, but live. Rich was on a roll as we started to joke about plot lines and just making up character twists and throwing BS on Twitter. I must say, he has Trekkie cred, because he knows a heck of a lot more than I do about the entire genre. We were having a great time just making $%(# up. After dinner we went to the theater and got dead center seats! We were not 5 minutes into the movie when one of Rich’s tweets came alarmingly close to the real thing. Another 5 minutes, and Rich nailed another plot line. I am not going to say which ones, you will just have to go see the movie. Oh, and we both really liked it! A must-see for Star Trek fans. But for a little amusement, before you go to the movie, check Rich’s tweets. I know Rich said it last week, but I wanted to mention it again – if you’d like to get our content via email instead of RSS, please head over and sign up for the Daily Digest, which goes out every night. And now for the week in review: Webcasts, Podcasts, Outside Writing, and Conferences Martin and Rich on the weekly Network Security Podcast. I did a series of three videos and an executive overview on DLP for Websense. It was kind of cool to go to a regular studio and have it professionally edited. The videos (each about 2 minutes long) and Executive Guide are designed to introduce technical or non-technical executives to DLP. It’s all objective stuff, and cut-down versions of our more extensive materials. Favorite Securosis Posts Rich: Adrian’s post on Oracle’s acquisition of Sun. I haven’t seen anyone else take this perspective! Adrian: Rich’s post on There are no Trusted Sites; the Security Edition. Poignant as always. Favorite Outside Posts Adrian: With all that free time on his hands, Chris has been turning out some good stuff. His post on Cloud Security Will NOT Supplant Patching is dead on the mark. Rich: Rsnake’s Silver Bullet Metric post. Top News and Posts Big news this week was the Torpig Hijack. The paper is long but filled with interesting details. Interesting developments between AdBlock creator Wladimir Palant and NoScript creator Giorgio Maone. Yeah, but so what? We know it is possible, and we know someone will be motivated by fame or fortune and do it again. The problem is someone will eventually do it well. Ryan Naraine’s coverage of the Google Chrome Security Flaws . Ron Gula of Tenable on understanding Vulnerability Assessment Results . I don’t know what the availability of this device is, but MiFi looks pretty cool!. Handy tip on disk wiping . The Marriage of Figaro, oddly sans frogs. New NERC standards. Naraine and Dancho on PowerPoint ZeroDay. Blog Comment of the Week This week’s best comment was from Nick in response to Spam Levels and Anti-Spam: Since the McColo shutdown we have seen a gradual rise in spam only returning to pre-McColo levels about a month ago. We are a small fish and only deal with about 20,000 emails per day including spam. But I have not been able to recognize the “return to normal” that everyone was talking about several months ago. I would actually estimate that after the shutdown, we have been sitting about 20% lower than usual, until this past month. Not including the first period of time after McColo. Share:

It’s kind of Apple Day here. Rich has been stuck in a ‘Genius Bar’ time warp all morning with a handful of dead Mac minis (Probably died from processor envy when the new Mac Pro arrived). Despite the recession, if you lose your appointment slot, you are going to be waiting a long time, as the AZ Apple stores are always packed. I would gladly have switched places with him, as I have spent all morning trying to decipher alien runes AT&T iPhone pricing plans. My cell phone provider, QuestQwest, is dropping all its cellular services and I now need two new phones. I thought this would be an easy decision as everyone I know seems to have an iPhone. Most people I know in the security profession have had their iPhones for a year or more and they love them. They really like to show off their eye-candy apps and what a powerful mobile computer the iPhone really is. But if 95% of your use is going to be phone calls, is it worth it? As bad as the AT&T pricing is, the real issue is service. AT&T coverage and clarity sucks, or SUCKS, depending upon where in the country you live. I get phone calls from from friends and associates, usually someone I know who has some comment about how my recent blog post demonstrated a complete lack of knowledge, and I should really have done my homework prior to posting. And that person is really smart and is probably making really compelling arguments, but it comes across as a small child making motorboat noises while facing away from the phone. I can’t help myself and laugh out loud. My laughter and saying “Dude!” really pisse them off, but the it is really hard to hear! And this is just the Securosis side of things. My wife and I drive lots of places where a clear connection is critical, and might have a life-threatening need to reach out and speak to someone who can help. In cases like this, a cool gadget loses every time to a reliable call. I love all the Apple products I have purchased and will seriously consider the iPhone. But AT&T is not Apple, and when it comes down to it, service is the bulk of what I am paying for. I was really hoping the rumored Verizon branded iPhone Nano would happen as I could get the Apple product and have good coverage. I have been cruising Mac Rumors every day to see what’s new. We’ll see. There is a rumor that AT&T is dropping prices, which is nice, but Verizon is running a 2 for 1 sale on Blackberrys, which is even more compelling. I have another month or two of service before I have to make a decision, by which time the new iPhones should be out, and then I will make the decision. Share: