Research

I’ve been a bit erratic with my Dark Reading posts, but finally have a new one up. This one is dedicated to the topic du jour – cloud computing security. The article is The Only Two Reliable Cloud Security Controls and here’s an excerpt: It seems that we in the information technology profession are just as fickle as the fashionistas strutting around Milan or New York. While we aren’t quite as locked to a seasonal schedule, we do have a tendency to fawn over the latest technology advances as if they were changing colors or hem lengths. Some are new, some are old, some are incredibly useful, and others are completely frivolous, but we can’t deny their ability to enter and steer our collective consciousness – at least until the next spring. Take cloud computing. But definitional maturity doesn’t necessarily mean technological maturity, and is always a far cry from security maturity. While we now understand the different flavors and components of the cloud, and even have some relatively good ideas of potential security controls, the diversity of real world offerings and the traditional lack of security prioritization bring all the usual security challenges. The cloud is a collection of various proprietary technologies (mostly) from diverse vendors (mostly), all with different ways of doing things (mostly). Not that I’m complaining: if you work in security and don’t enjoy these kinds of challenges, you should probably consider a different career path. There are really only two reliable security controls – our service level agreements (SLAs) and personal education and knowledge of the cloud implementation. Share:

I can’t entirely promise tonight’s episode makes a lot of sense. Martin is back from Kyoto, and seriously jetlagged, and I don’t think I was a whole lot better. Sure, we cover the usual collection of security news, but the episode is filled with non-sequitors and other dissociated transitions. On the other hand, we do stick fairly closely to security related topics. In other words, listen at your own risk. Network Security Podcast, Episode 157, duration: 25:08 Show Notes Microsoft 0day being exploited in the wild. China is as scared of us as we are of them. See? Your mom was right. iPhones are vulnerable over SMS. I highly doubt the iPhone is the only phone with this problem. A “security guard” hacks a hospital’s HVAC system. Then goes to jail for additional stupidity. Good thing most bad guys are dumb, or we’d really be in trouble. More nails in the coffin that holds your Social Security Number. Share:

I had a weird discussion with someone who was firmly convinced that you couldn’t possibly have data security without starting with classification and labels. Maybe they read it in a book or something. The thing is, the longer I research and talk to people about data security, the more I think labels and classification are little more than a way to waste time or spend a lot of money on consulting. Here’s why: By the time you manually classify something, it’s something (or someplace) else. Labels aren’t necessarily accurate. Labels don’t change as the data changes. Labels don’t reflect changing value in different business contexts. Labels rarely transfer with data as it moves into different formats. Labels are fine in completely static environments, but how often do you have one of those? The only time I find them remotely useful is in certain databases, as part of the schema. Any data of value moves, transforms, and changes so often that there’s no possible way any static label can be effective as a security control. It stuns me that people still think they can run around and add something to document metadata to properly protect it. That’s why I’m a big fan of DLP, as flawed as it may be. It makes way more sense to me to look inside the box and figure out what something is, instead of assuming the label on the outside is correct. Even the DoD crowd struggles mightily with accurate labels, and it’s deeply embedded into their culture. Never trust a label. It’s a rough guide, not a security control. Share:

An interesting news item on how social security numbers can be guessed with surprising accuracy made this morning’s paper. Researchers say they can determine much of someone’s social security number from birth date and location. Hopefully this will shine yet another spotlight on our over-reliance on social security numbers as a method of identification. From the San Jose Mercury news: For people born after 1988 – when the government began issuing numbers at birth – the researchers were able to identify, in a single attempt, the first five Social Security digits for 44 percent of individuals. And they got all nine digits for 8.5 percent of those people in fewer than 1,000 attempts. … The predictability of the numbers increases the risk of identity theft, which cost Americans almost $50 billion in 2007 alone, Acquisti said. That is fairly accurate, all things considered. When researchers Alessandro Acquisti and Ralph Gross make their research public, just as with most efforts of this type, we will see the research community at large make improvements in the methodology and accuracy of results. And in the long run, who says that the ‘guesser’ only gets one try? What made me crack up in this news report was the Social Security Administration’s Mark Lassiter’s response that “… there is no foolproof method for predicting a person’s Social Security number,” and his statement that “The public should not be alarmed …”. Identity thieves and criminals don’t need 100% accuracy; a few million legitimate numbers ought to be sufficient. Share:

Going through my feed reader this morning when I ran across this post on Dark Reading about Your First Three Steps for database security. As these are supposed to be your first steps with database security, the suggestions not only struck me as places I would not start, it offered a method that I would not employ. I believe that there there is a better way to proceed, so I offer you my alternative set of recommendations. The biggest issue I had with the article was not that these steps did not improve security, or that the tools were not right for the job, but the path you are taken down by performing these steps are the wrong ones. Theoretically its a good idea to understand the scope of the database security challenge when starting, but infeasible in practice. Databases are large, complex applications, and starting with a grand plan on how to deal with all of them is a great way to grind the process to a halt and require multiple restarts when your plan beaks apart. This article advises you start your process by cataloging every single database instance, and then try to catalog all of the sensitive data in those databases. This is the security equivalent to a ‘cartesian product’ with a database select statement. And just as it is with database queries, it results in an enormous, unwieldy amount of data. You can labor through the result and determine what to protect, but not how. At Securosis, we’re all about simplifying security, I am a personal advocate of the ‘divide and conquer’ methodology. Start small. Pick the one or two critical databases in your organization, and start there. Your database administrator knows which database is the critical one. Heck, even your CFO knows which one that is: it’s that giant SAP/Oracle one in the corner that he is still pissed off he had to sign the $10 million dollar requisition for. Now, here are the basics steps: Patch your databases to address most known security issues. Highly recommended you test the patch prior to operational deployment. Configuring your database. Consult the vendor recommendations on security. You will need to balance these suggestions with operational consistency (i.e. don’t break you applications). There are also third party security practitioners who offer advice on their blogs for free, and free assessment tools that will help a lot. Get rid of the default passwords, remove unneeded user accounts, and make sure that nothing (users, web connections, stored procedures, modules, etc) is available to the ‘public’. Consider this an education exercise to provide base understanding of what needs to be addressed and how best to proceed. At this point you should be ready to a) you can document what exactly your ‘corporate configuration policies’ are and b) develop a tiered plan of action to tackle databases in descending order of priority. Keep in mind that these are just a fraction of the preventative security controls you might employ, and does not address active security measures or forensic analysis. You are still a ways off from employing more intermediate and advanced security stuff … like Database Activity Monitoring, auditing and Data Loss Prevention. Share:

As it’s the middle of summer, it’s freakin’ hot here. Rich and I have been cranking away like crazy since RSA on a couple different projects and are in need of a break. Now it’s time for a little R&R, so like you, we going on a mini summer break. That means no Friday Summary this week. We’ll be back around the 7th, and return to normal Friday posts on the 10th. Until then, enjoy yourself over the July 4th holiday (even if you’re not in the U.S.)! If you haven’t yet taken the Project Quant survey, go ahead and stop by SurveyMonkey on your way out for the long weekend. Share:

I have a half dozen books on Thomas Jefferson’s life, but this is a pretty cool story I had never heard before. The Wall Street Journal this morning has a story about a Professor Robert Patterson, who had developed what appears to be a reasonably advanced cipher, and sent an enciphered message to President Jefferson in 1801. He provided Jefferson with the the message, the cipher, and hints as to how it worked, but it is assumed that Jefferson was never able to decrypt the message. The message was only recently decrypted by Dr. Lawren Smithline, a 36-year-old mathematician who works at the Center for Communications Research in Princeton, N.J., a division of the Institute for Defense Analyses. The key to the code consisted of a series of two-digit pairs. The first digit indicated the line number within a section, while the second was the number of letters added to the beginning of that row. For instance, if the key was 58, 71, 33, that meant that Mr. Patterson moved row five to the first line of a section and added eight random letters; then moved row seven to the second line and added one letter, and then moved row three to the third line and added three random letters. Mr. Patterson estimated that the potential combinations to solve the puzzle was “upwards of ninety millions of millions.” After about a week of working on the puzzle, the numerical key to Mr. Patterson’s cipher emerged – 13, 34, 57, 65, 22, 78, 49. Using that digital key, he was able to unfurl the cipher’s text: “In Congress, July Fourth, one thousand seven hundred and seventy six. A declaration by the Representatives of the United States of America in Congress assembled. When in the course of human events…” I am not sure why I am fascinated by this discovery. Perhaps it’s a bit like discovering hidden treasure. Share:

When I interview database candidates, I want to asses their skills in three different areas; how well they can set-up and maintain a database, how well they can program to a database, and how well they can design database systems. These coincide with the three roles I would typically hire: database administrator, database programmer and database architect. Even though I am hiring for just one of these roles, and I don’t expect any single candidate to be fully proficient in all three areas, I do want to understand the breadth of their exposure. It is an indicator of how much empathy they will have for their team members when working on database projects, and understand the sometimes competing challenges each faces. While there will always be some overlap, the divisions of responsibility are broken down as follows Database administrator – Installs, configures, manages the database installation. This will include access control, provisioning and patch management. Typically provide analysis into resource usage and performance. Database architect – Selects and designs the platforms, and designs or approves schema. It’s the architect’s responsibility to understand how data is used, processed and stored within the database. They typically select which database platform is appropriate, and will make judgment calls whether or not to use partitioning, replication, and other advanced features to support database applications. Database programmer – Responsible for coding the queries and use of the database infrastructure. Selection of data types and table design, and assists with We talk a lot about database security on this blog, but we should probably spend more time talking about the people who affect database security. In my experience database programmers are the least knowledgeable about the database, but have the greatest impact on database security and performance. I have been seeing a disturbing trend of development teams, especially web application programmers, who perform every function in the application and regard the database as a bucket where they dump stuff to save application state. This is reflected in the common choice of smaller, lighter databases that provide less functionality, and the use of abstraction techniques that clean up the object model but lose native functions that benefit performance, data integrity and security. Worse, they really don’t care the details of how it works as long as their database connection driver is reasonably reliable and the queries are easy to write. Why this is important, especially as it pertains to database security, is that you need to view security from these three perspectives and leverage these other practitioner skills within the organization. And if you have the luxury of being able to afford to employ all of these three disciplines, then by all means, have them cooperate in development, deployment and maintenance of database security. You architect is going to know where the critical data is and how it is moved through the system. Your DBA is going to understand how the databases are configured and what operations would be best moved into the database. If you are not already doing it, I highly recommend that you have your DBA’s and Architects do a sanity check on developer schema designs, review any application code that uses the database, and provide support to the development in team access control planning and data processing. It’s hard to willingly submit code for review, but better fix it prior to deployment than after. Share:

Technically the title should be Things to do With Encryption…, but then I wouldn’t have a semi-obscure movie reference. Cory Doctorow of BoingBoing linked to a column of his over at The Guardian entitled If I’m dead how will my loved ones break my password?. As a new father myself, I recently went through the estate planning process with my lawyer, and this is one issue I’ve long thought needed more attention. A few years ago I even considered building a startup around it. Much of my important data is encrypted – especially logins to bank accounts and such. Also, a fair bit of my other data is either encrypted, or protected in ways many of you fair readers could circumvent, but my family members can’t. I also have a ton of “personal institutional knowledge” in my head – everything from how to keep this blog running, to locations of family photos, to all the old email correspondence I kept when my wife and I started dating. If I get hit by a truck (or, more likely, kill myself in some bizarrely stupid way right after saying, “okay, check this out”), all of that would either be lost to the ether, or complex to recover. Heck, I have content that might be important to my family in applications in virtual machines on encrypted drives. Part of my estate planning process is ensuring that not only do my family and business partners have access to this information if I’m not around, but that they’ll know where the important bits are in the first place. Unlike Cory I’m not concerned with using split keys in different countries to prevent exposure to the government, but I also don’t think I’m as organized as he is in terms of where I keep everything. Thus, as part of my estate planning, I’m looking at the best way to make this information available on the off chance my sense of self-preservation fails to mature. Here’s the plan right now: Compile my passphrases, locations of important information, and other documentation into a single repository. I’m considering using 1Password since it already has the logins to nearly everything, I use it daily, and it can export to an encrypted PDF or a few other formats. 1Password supports secure notes for random instructions and other documentation. On a regular basis, I will export the information to an encrypted file which I’ll provide to my lawyer, and store in a secure online repository. I have a lot of options for this, but for the rest of you it might be better to set up a Hotmail/Yahoo/Whatever email account you don’t ever use for anything else, and send it there. You can then give your lawyer or executor access to that account (remember, the contents up there are still encrypted). This makes it easy to keep the information up to date, and it’s protected from your lawyer’s office burning down with your encrypted hard drive. It may be worth it to use two different services, just in case. Remember that if your lawyer doesn’t have direct access, it may be difficult for him/her to legally obtain access after death. I’ll give my lawyer the locations of the information and the passphrase for my 1Password export in a sealed envelope. Since he’s my brother in law, and might be with me when I accidentally blow up that propane tank, I’ll make sure his partner also has a copy in a separate physical location. That should cover it – my information is still protected (assuming I trust my lawyer), and it includes logins, locations of important electronic documents, and so on. I’m in the middle of setting this up, and haven’t even talked to my lawyer about the details yet, but it’s as important as any other aspects of my trust. A separate issue, and the other half of my vaporware startup, is what happens to all my correspondence/photos/movies after I die? Historically, the archives of individuals, handed down through generations, are an important part of the human record. This isn’t just an ego thing – letters and photos of regular folks are as important to historians over the ages. Right now, as a society, this isn’t an issue we’ve really addressed. Share:

Martin is off in Japan this week, so I’m joined by our good friend Amrit Williams from BigFix and the Techbuddha blog. Amrit and I start off by talking about the rolling blackouts in California and disaster preparedness, before jumping into the week’s security news. Network Security Podcast, Episode 156 Time:  41:28 Show Notes: The New York Times and Wikipedia censor reports of a captured reporter to protect him. Dave Shackleford on 10 things your auditor doesn’t want you to know. Trojan steals FTP credentials Juniper pulls ATM hacking talk from Black Hat Most systems have unpatched software. Is anyone surprised? Tonight’s Music:  Since I haven’t figured out how to get the podcasting rights to Jimmy Buffett’s entire collection, there’s no music for tonight’s close. Share: