As you may already know, I’m attending the 2010 RSA Conference in San Francisco, CA.  I’ve been spending so much time talking with vendors, going to keynote talks and going to track sessions I haven’t had much time to finish writing and editing any full blog posts yet.  Rather than rush to publish, I want to take my time and write up my thoughts and experiences fully.  As a result, there will probably be a number of delayed posts in the coming days and weeks about my experiences here.  For now, I’ll leave you with these teasers from my first day at RSA:

• Art Coviello (RSA) believes that the emergence of cloud computing will be our opportunity as an industry to turn the way security is delivered inside out.
• Paul Maritz (VMWare) thinks the formula for embracing cloud computing is simple: improve efficiency, improve agility, improve security.
• Mark Benioff (salesforce.com) stated Lotus Notes was conceived before Mark Zuckerberg was; enterprise software needs to change, and become more like Facebook.
• As evidenced by having Brian Snow, NSA on the Cryptographers Panel: the commercial and academic communities still have a lot of distrust and suspicion of the NSA.

Other items I’ll be writing about: a lunch I had with F-Secure’s Mikko Hypponen where he discussed cyber crime, and a session I attended called “Winnovation- Security Zen through Disruptive Innovation and Cloud Computing”.  Stay tuned!

Let’s face it. There are a lot of broken web apps and software out there. These web apps and software can oftentimes lead to major security holes being opened up due to their vulnerabilities. You don’t want to be the guy/girl responsible for the next major security breach just because you forgot to sanitize some input, or check that your sessions were secure.

I would love to provide you a great tutorial on how to avoid many of the hardships that developers face, especially in security these days, but I don’t think I could do it better than the people over at the OWASP WebGoat project. It’s a web application that purposefully has many vulnerabilities right out in the open. The site is laid out with exercises for you to complete. It will offer hints, and even a full solution for when you get stuck. It even tracks your progress through a report-card like page showing how many times you’ve attempted an exercise, how many times you got help, and whether it was completed or not. You can grab WebGoat from OWASP.org directly and install it on your own tomcat server, or grab it in a fully enclosed environment through Dojo or OWASP Broken Web App VM. Either way you choose, I’d highly recommend either one. The VM’s provide much more on top of WebGoat but I feel the way the site is laid out and structured, it provides a very good tutorial-based approach to learning what not to do or at least learn what to avoid in your own applications.

Today, in advance of the 2010 RSA Conference, I had the benefit of attending the 10th CSO Council Bay Area Round Table: The Last Mile: The End of Paper. It has been an interesting exercise with a mock trial (moderated by two Judges) involving three wills signed with three different technologies: ink signature, closed system electronic signature, and digital signature.

You would think this would be an easily decided scenario; the digital signature is a superior and more trustworthy technology, right?  Well, not when you change the rules a bit. Basically they made the strength of process the inverse of the strength of the technology.  Here are the key points from today’s trial, and I’d like your suggestions on which one you’d pick.

• Will 1: Ink Signature: happened a long time ago, seems to be in order but there are no surviving attesters to the signature. Gives the entire estate to his wife, and if she predeceases him, his son.  As of today, the wife did predecease him, and his son has become estranged, will #2 being part of the reason.
• Will 2: Electronic Signature: signature is just a hash of the user name and the document being signed.  Gives 1/2 the estate to Stanford University, and the other 1/2 to his son.  The signature was not attested to by any other individuals.  There are no security controls over the log files and no way to prevent modification. However, everything seems to be in order with the signature.
• Will 3: Digital Signature: signature uses the internal PKI of a legal firm which stores private keys on USB memory sticks (not cryptographic devices). A paralegal of the firm who helped create the PKI process is the sole beneficiary.  The signature was counter-signed by two other individuals.  The paralegal (“Bubbles”) administers the PKI system and theoretically could have recreated signatures or digital IDs.

So, if you had to vote for one of these as a juror, which one would you choose?  Personally? I think all 3 are terrible and I fear the entire estate may need to go to probate.  Let us know what you would choose as a juror in the comments.

In general, Windows does a decent enough job with securing software keys in CAPI. Sure, you can open up Windows Explorer, browse to C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys, and take a look at your private key files. These bare files, of course, are not exactly plain text. The RSA Machine Keys (which include private keys corresponding to software certificates), are encrypted using the Data Protection API (DPAPI).

The DPAPI encryption method is based on the use of a Master Key – a 512 bit random blob that is created using PKCS #5 Password-Based Key Derivation. This process takes the user’s account password, applies the SHA-1 hash algorithm, sends the hash plus a salt to the key derivation algorithm, and then iteratively calls another PKCS #5 function at least 4000 times to make brute-forcing the secret key even harder. Et Voila! Master Key.

The Master Key is then used to create session keys by generating 16 bits of random data, hashing that with the Master Key, optionally appending the result with entropy data and the user’s password, and passing that blob into a few CryptoAPI calls to derive a session key. This session key is used to encrypt the actual data.

Whew!

This process actually does a very good job of securing key files such that, if you got a copy of the key files as they exist on disk, you’d have a difficult time brute-forcing your way into the software key data. They’re basically useless unless you have an utterly stupefying amount of disposable processing power. However, for as strong as the key protection is, it’s just software.

A well-known scientist (some say it was Bertrand Russell) once gave a public lecture on astronomy. He described how the earth orbits around the sun and how the sun, in turn, orbits around the center of a vast collection of stars called our galaxy. At the end of the lecture, a little old lady at the back of the room got up and said: “What you have told us is rubbish. The world is really a flat plate supported on the back of a giant tortoise.” The scientist gave a superior smile before replying, “What is the tortoise standing on?” “You’re very clever, young man, very clever”, said the old lady. “But it’s turtles all the way down!”
-Stephen Hawking, A Brief History of Time

That’s essentially what software keys are protected by – software, all the way down. Well, that’s not completely accurate. It’s software all the way down except for the mythical final turtle, which is our old friend, the password!

Now, I’m not suggesting that I know how to crack DPAPI, even if I do know a user’s password…that is, unless I have physical access to the device. Then all I’d need to do is log in, and Windows conveniently will take care of the rest, and allow me to use the keys however I see fit. (Un)fortunately, I don’t actually even need that to unlock a software key. All I need is a way of impersonating the user’s logon session, whether through remote desktop, exploiting Windows vulnerabilities, installing a rogue ActiveX control, or any number of countless ways to get a user to run some code.

So, how are we supposed to protect our private keys, then? Well, the simple and pretty inexpensive answer to that question, is Hardware Tokens. You can get a good FIPS-140 validated cryptography token for about $50-100, which will generate keys on the device, and the keys will never, ever be available to software (all cryptography operations are executed on the token). The tokens are tamper resistent (all memory is destroyed if the token is tampered with), and brute forcing won’t work, either (after a set number of failed logins, the token is locked and, optionally, all data is wiped). Now, this isn’t necessary for some applications, but if your encrypted data is worth more than $50 to you, why would you want to protect it with something as flimsy as a password?

Message Authentication Codes (MACs) are special pieces of data used to prove the authenticity and integrity of a message– to show that the message originated from a certain source and that it has not been modified. Consider a scenario in which Alice wants to send Bob an email. Upon receiving the email, Bob would like to be fairly certain that Alice was indeed the author and that the letter hasn’t been changed. When creating her email, Alice needs to have some technique that satisfies Bob’s concerns.

• First, she appends a secret word to the very end of the message. This secret word is only known by Alice and Bob.
• Next, she creates a unique “footprint” of her email by running it through a hash function (along with the secret appended at the end).
• Finally, she sends the original message (sans the secret word) to Bob. She also sends him the digest/hash/footprint.

When Bob gets the message:

• First he adds the secret word to the very end of the message (just like Alice did).
• Then he runs the message + secret through the exact same hash function that Alice did.
• Finally, he compares the resulting “footprint” with the one Alice sent him. If they match, the he can be confident that Alice sent it (since she’s the only other one who knows their secret) and that the message hasn’t been tampered with (since any change in the message would result in a different footprint).

This is almost identical to the way digital signatures work. However, MACs rely on a shared secret and, therefore, aren’t inherently based on public key theory. In addition, digital signatures are able to establish non-repudiation, which is not the case with MACs. In the above example, Bob could create an email from Alice to himself and Alice would not be able to prove she didn’t send it using just the MAC.

For this reason, MACs are most commonly used for inter-system communication. Webservers, specifically, make use of MACs to protect against cross-site request forgery (CSRF) attacks.

However, a common misconception with creating MACs is that any strong hash function alone is sufficient when creating an effective MAC. In reality, MAC-specific algorithms are designed to address some weakness with recklessly using block-level iterative hash functions (MD5, SHA, etc) concatenated to some shared secret. Specifically, the use of a Hash(message || secret) approach is susceptible to attack since someone could use information on known message/hash combinations to construct a new, working message/hash. By using a MAC-specific algorithm, such as HMAC or CMAC, these weaknesses can be mitigated or avoided altogether. So if you’re ever in a situation where you could benefit from a hastily-implemented MAC, be sure to consider both its strengths and weaknesses.

Today Slashdot had a story about how a news story about an Australian transportation plan was broken early by a newspaper. The transport minister said the access of this information was akin to the newspaper trying to “pick the lock off a secure office and take highly confidential documents”.  What was the brilliant security plan that was supposed to be protecting this information?  The information was all stored on an unpublished URL with no security or authentication in place.

We in the security industry call this “security by obscurity“.  And it is not security at all. Read the rest of this entry »

FIPS stands for Federal Information Processing Standards, and is “run” by NIST. It is a set of standards that dictates how information is stored, processed, and managed in the federal government. It’s also leaked into the commercial sector through government contractors and the concept of “If it’s good enough for the government…”

Almost all of the FIPS standards are relevant to security. Ever hear of FIPS 197? It’s AES. A list of all FIPS documents is available through NIST, and if you’ve worked in information security, you’ve likely heard of at least 3-4 of them. The one I hear most often is FIPS 140-2. This is the standard for cryptographic implementation. An entire industry has grown up among independent testing laboratories that test a specific cryptographic implementation for compliance. And to feed that – the government won’t accept a cryptographic implementation unless it’s been certified. NIST issues a “certificate” and everything.

The FIPS 140-2 testing is quite rigorous, and until now was generally accepted as an “all clear to use” signal. There are some implementation problems that have just cropped up, and until someone knows what happened – bad testing, different implementation, etc., we won’t know if the FIPS testing program is broken or if it was just a bad apple.

An uproar was recently started in reference to some privacy concerns about the new release from Google, Google Buzz. One of the first to sound the alarm was a blogger who was quite explicit about disliking some of its default options (and by explicit I mean “NSFW language” explicit, the post is here) which prompted some quick changes from Google.  In order to start using Buzz, you have to create/modify your Google public profile which will appear next to all of your activity in the Buzz feed.  By default, the public profile would display all those you follow. Chances are you’ve followed everyone in your contact list, so you just made your whole contact list public.  Now in the new behavior:

A box titled “How do you want to appear to others” will now include a check-box that says “Show the list of people I’m following and the list of people following me on my public profile.” To hide your followers, click the box, or click the “View and edit the people you follow” to customize your account.

The interesting thing here to me is that Buzz is essentially a service like Facebook or Twitter, designed to let other folks know what you are up to.  The fact that there is a privacy uproar around it is somewhat amusing, because it is designed to provide the opposite of privacy – to provide your followers information about what you are doing.  If you don’t want to share this information, don’t use Google Buzz!

I’ll enlist a famous quote from Scott McNealy, then CEO of Sun Microsystems: “You have zero privacy anyway. Get over it.”

It is amusing to me what people – especially young people – are willing to post online.  As a child, my parents once told me that once you say something you can’t take it back.  In today’s Internet-connected age, this holds true and is even more significant: once you say something online, hundreds if not thousands of people will see it instantly, and potentially billions of people will be able to track it down in archives, Google searches, the wayback machine, or in countless other ways.  Be careful what you share online.  Be careful what you say.  It might–probably will–come back to haunt you.

When companies create security policies designed to keep their information secure, they are often most focused upon the threat of an outsider.  Certain measures, like using secure protocols such as SSL and TLS, or using S/MIME encrypted email can help keep your information from being viewed by third parties when it is sent over untrusted networks.  Other measures, like performing hard disk encryption on your laptops help keep your information secure when a laptop is lost or stolen, or a hard drive is sold on eBay.  None of these measures will help in the scenario of a trusted insider getting access to over 1300 documents that they have no business having.

According to the complaint, Jhaveri admitted being employed by Bristol-Myers-Squibb as a Technical Operations Associate from November of 2007 until his termination on February 2, 2010. The complaint further alleges that during his employment, Jhaveri stole numerous trade secrets as part of a plan to establish a pharmaceutical firm in his native India which would compete with Bristol-Myers-Squibb in various markets around the world.

How do you protect against the insider threat?  It is one of the more complicated issues of information security and there are a lot of opinions on how to deal with it.  Certainly it has to start with understanding what information you have which needs to be protected, how damaging that information could be if it were to be lost/stolen, and then making some cost/benefit analysis decisions on the best ways to protect it.  Everything from a rights management services type of solution to a strong security event and information management (SEIM) system could be useful in preventing and detecting insider threats.

The first night of ShmooCon is a wrap, at least for the presentations. First off, my shout-outs to all those that actually made it this year. The DC weather hasn’t been too kind to any of us, especially those traveling in specifically for this Con. But to those who made it, I salute you (even more so to those who had to walk a couple miles to get to their hotel because they didn’t make or take reservations at the Marriot).

Read the rest of this entry »