Wednesday, September 23, 2009

SANS September 2009 Report - The Top Cyber Security Risks

A report titled “The Top Cyber Security Risks” was recently released by SANS and TippingPoint that may be useful for background on the current internet security risks.

You are encouraged to review findings in this report if you have the time.

Notable in the report is that vulnerabilities within applications now exceed more traditional OS level vulnerabilities.

That said, the security community is mixed on the findings as we would like to see more supporting data as evidenced by this post:

Wednesday, July 1, 2009

July 2009 is “Month of Twitter Bugs” (MoTB)

In an effort to raise awareness for issues within Twitter API as well as 3rd party integration, the “Month of Twitter Bugs” (MoTB) has officially commenced.

More information here:

If you use Twitter (or know colleagues who do), you may want to share this information with them and also make note of which 3rd party apps you have given access to your Twitter account.

It might even be a good time to change your Twitter password right about now, .. =)

New bugs will be posted here daily throughout the month:

Tuesday, May 19, 2009

Respect Experience and Trust Your Gut

I was inspired to write this post after reading a recent paper/post by Marcus Ranum titled "Ranum's Rants - The Anatomy of Security Disasters" available here. Thank you Ivan for the link.

This post is also available in pdf format here.

So as I was reading Marcus, I felt as though I was connecting with every word he wrote:

I’ve seen major security-critical business decisions get made based on whose golf buddy runs what business unit – I’m very skeptical of the notion that "Risk Management" has any value beyond the butt-covering obviousness of having made an attempt.

Brilliant. Insightful. Spoken from experience. Perhaps a dash (or three) of cynicism. But all true.

As security professionals, we see a lot. We learn a lot. We are all about the details and we HATE TO BE BLIND-SIDED!

If you are new to information security, you need to ingest the words from Marcus as if they were your own.

In the most dysfunctional organizations, you get senior (or sometimes mid-level) executives who 'shop a bad idea' until they find someone who is willing to tell them it is good. One security disaster I was involved with happened in exactly this manner: a senior executive hit upon a bad idea and asked the security team for their input. The security team explained why it was a bad idea; in fact they wrote a brilliantly clear, incisive report that definitively framed the problem. So the executive asked the web design team, who declared it a great idea and "highly do-able" and implemented a prototype. Months later, the "whiners" in the security team were presented with a fait accompli in the form of "we're ready to go live with this, would you like to review the security?"

Like it or not, this is our world! Security is now and will always be the enemy of convenience. Deal with it!

The only way to prevent security disasters is to have a security team that is fearless about feeding back information up to the top of the chain of command, and to have senior executives who make decisions based on reality rather than a projection of their fantasies.

Over the years I have realized that I bring 3 valuable assets with me to the table as a security professional:

1) my experience
2) my professional colleagues/relationships
3) my gut

The first two just naturally come over time but the third takes confidence and a foundational trust in both your abilities and your judgement. As I get longer in the tooth, I have grown to trust this "gut feeling" even more and I venture to speculate that once you learn to trust *your* gut feeling, you too will be a better and more effective security professional, as well.

Sure I have made my share of bad decisions and I do not mean to imply that I have seen every possible iteration of a specific event or incident, .. only that over time, I have learned to appreciate that many events are simply variations of prior events and that it is my gut that allows me to connect the dots and recognize the similarities between these events when this connection may not otherwise be readily apparent.

I have also come to expect, foster and appreciate a work environment that I like to call "unbridled candor" where honesty abounds and you had damn well better not ask a question unless you are willing to hear the honest truth. I know from experience that some people can't deal with the truth.

I believe it is my gut that gives me the confidence to speak truth to power in a way that is not seen as confrontational to business decision makers but simply matter-of-fact and authoritative.

Marcus sums it up this way, ...

What can we do to break the cycle? The most important thing is to make sure you are direct and honest about expectations at all times. Do not allow management or clients to believe that they can do dumb things in safety, and do not hide behind bogus probability guesses. "Safety" is not the same thing as "relative safety."

I believe that Marcus trusts his gut and I think you should trust yours as well.

Thursday, May 7, 2009

What is a "canary account"?

A canary account is an account created in a database for the sole purpose of detecting if data has been compromised.

The term "canary account" is based on the notion of a canary detecting changes in the air quality of a coal mine to the point where it was unsafe for humans.  Think of it as a early warning system, ...

Within the context of data protection, the canary account could be monitored to make sure it had not been accessed and if the account is accessed, then you have a high likelihood that the data may have been compromised.

This is somewhat related to the notion of a "honey pot" that acts as 'bait' for attackers drawing their attention away from the real crown jewels in favor of pseudo crown jewels that have been crafted to look even more appealing to the attacker, ..

In a post by Robert Graham related to the phpbb hack earlier this year, canary accounts are mentioned as a possible means for alerting to the attack sooner:

The first is to create "canary" accounts. Create accounts that have e-mail addresses, like "". This account is not going to get any spam e-mail. When it does get its first spam, you'll know that it came from your database. When I create recommendations for clients, this is always one of the first things I suggest. (Likewise, if you are an e-commerce site, you should get dummy credit cards that only exist in your database). This won't stop you from getting hacked, but it will at least tell you when a hack has happened. (I suspect that this isn't the first time phpbb has been hacked - just the first time it's been made public).

I am not saying that canary accounts are appropriate in all cases but just trying to get you thinking of the possibilities, ..

Wednesday, May 6, 2009

Security Peer Review Checklist

Here is a very nice checklist for use with Peer Security Reviews

Also, here is original post announcing availability of the checklist:

Thursday, April 30, 2009

Update on Adobe JBIG2 0-Day from February

The video below from Matthew Watchinski of SourceFire VRT offers some interesting information on the events surrounding the Adobe JBIG2 0-Day from February

If you have a few moments (and you are a complete geek) you might find it interesting.

Notable from the presentation:

  • JBIG2 vulnerability sold on the black market on Jan 1st to a buyer in China for $75K
  • first exploit related to this vuln was observed in the wild on January 11th
  • ShadowServer crew posted their notification on February 19th
  • Adobe knew about it before but sat on it and did nothing
  • exploit was used in the wild for approx a month before it became public
  • All pdf readers including Foxit and Mac OSX Preview were vulnerable to this exploit
  • All of the risk mediation that we were told at the time concerning the 0-day proved to be wrong
  • PDF vulnerabilities are easy to find
  • PDF vulnerabilities are highly sought after in the darker corners of the internet

Thursday, January 8, 2009

RMS Titanic was compliant!

This was posted to an interesting blog that I follow and thought that it may interest you all.

From the post:

the problem here was that the Titanic indeed did meet all of the safety requirements of the time. And that a big part of the problem was that the safety requirements were drafted in 1894 at a time when there were rapid changes and in the size and design of ships of this kind. Those regulations indicated that all passenger ships over 10,000 tons required 16 life boats, and that’s how many the Titanic had.

The Titanic incorporated many innovative design features but only included the minimum number of lifeboats to satisfy compliance.

Also from this post:

So, the bottom-line was that when the Titanic was reviewed by the safety accountants, they took out their check-list and went over the ship with a fine tooth comb. When the day was done the ship fully met all the safety criteria and was certified as safe.

As technology leaders in our industry, we need to be aware of the consequences for only doing the minimum amount in order to satisfy our compliance concerns since we, too, are one iceberg away from a very bad day.

Just some food for thought, ...