Agility Loop

I know there are other tools out there to find out what has been interesting on the web over the last week.  However, the overwhelming flow of information on Google Buzz and Twitter sometimes makes it difficult to keep up.  So, I am going to start a weekly post that will highlight some interesting articles from the web, mostly the blogosphere, in relation to security, cyber, and government contracting.  Don’t be surprised though if I sneak in a couple of goofy links from time to time.

Bill Puts Contractors Out of Work – NextGov
There a ton of articles that document the government’s efforts to trim down the contractor workforce.  This particular article focuses in on how the beltway bandit establishment are fighting against change that may effect their wallets.

Understanding and Selecting a Tokenization Solution: Introduction – Securosis Blog
An in-depth introduction to tokenization in enterprise applications.  I actually stumbled upon this blog a couple of weeks ago and it is well worth following.  They cover a variety of security topics including log management, network data flow, and secure application development.

Paying for Classified Security – NextGov
An article that details the $$$s spent by the federal government on information security.  Ironically enough the costs were actually down between 2008 and 2009, although the number is still at $4.26 billion dollars…not including what the intelligence community spends.

Nightwatch
This less about an article and more about Nightwatch overall.  Great feed to follow to read in-depth goings on in the rest of the world.  Most updates feature editor commentary that give greater insight into situation such as the North Korean/South Korean submarine debacle.

Cryptography Success Story – Schneier on Security
A link to an article showcasing where encryption of a hard drive actually foiled both Brazilian authorities and the FBI.  Certainly a good thing from a protection perspecitve, but maybe not so good from an inteligence collecting angle.  The comments on Schneier’s blogs are always insightful (and entertaining) as well.

In today’s post, Jack Goldsmith and Melissa Hathaway contributed an article entitled “The cybersecurity changes we need“.  The authors criticize the current administration in their approach to cybersecurity and state that it is focusing on short term gains rather than the long term.

I have become a little exasperated by all of the sword rattling and cheesy commercials using the public’s fear of “taking down the power grid”.   I had hope for the article when it started:

The news is filled with scary stories about the insecurity of the computer and telecommunication systems on which our nation’s prosperity depends: malicious software planted in electricity-grid computers; rampant state-sponsored and criminal cyber-espionage and theft; and the possibility of cyberattacks on banking and transportation systems.

However, rather than make suggestions on what should be done, they take the rest of the article to criticize the administration for paying lip service  to cybersecurity and policies that have been established.  I don’t necessarily disagree with that thought, but I also think it is always more useful for all if a plan, even a high level one, is proposed. 

Cybersecurity (or insecurity) is DEFINITELY a threat as we all become increasingly “plugged in”.  BUT, like most topics that have billions associated with it, they hype can become quickly overblown into fears that the Chinese are hacking into the power grid on a regular basis.  A plan is all well and good, but a lack of high level influence within the administration has been a deterrent to actually getting things done.  The establishment of a cyber command, although somewhat scary due to its ties to the NSA, is a good first step.  One thing that I have learned while working in the military is that when shit hits the fan, it actually gets done.

Blippy,  a company that enables users to share their credit card purchases, today provided details on a breach of credit card information.  Turns out that four credit card numbers were searchable via Google.  The beginning of their response:

Today someone discovered a Google search that displays the credit card numbers of 4 Blippy users.

We take security seriously and want to assure Blippy users that this was an isolated incident from many months ago in our beta test, and doesn’t affect current users.

While it looks super-scary and certainly sucks for those few people who were affected, and is embarrassing to us, it’s a lot less bad than it looks.

Although I feel a “less bad” for these four folks, WHAT THE !@!$@!$ DID YOU EXPECT?  It is one thing to use your credit card online for purchases, but it is a whole new level of voyeurism that drives you to share your credit card number for the purposes of telling the world what you are buying.

“Hello world…I just bought an fully capable inflatable sheep for $19.99.  I promise it is just as a gag…honest.”

A article over at PCWorld yesterday entitled Hacking Impresario: ‘Windows Safer Than Mac’ quotes the organizer of Pwn2Own stating that Windows 7 is more secure than Snow Leopard.

Contest organizer Aaron Portnoy, who is the security research team lead with 3Com TippingPoint, the sponsor of Pwn2Own, told Computerworld’s Gregg Keizer that:

“Safari will be the first to go. [Safari will] be on Snow Leopard, which isn’t on the same level as Windows 7.”

Of course this stance is disputed by other security impresarios (talk about an author using a thesaurus).

Microsoft has been THE target of hackers for so long that they had to have learned.  Mac has had the privilege of being under the radar for a long time since they were the plucky underdog.  However, as their sales rise, more hackers will start targeting the platform.

And it also shows that marketing is a really king.  For years I have said that a large part of Microsoft’s rise as been marketing.  Mac has been touting its security and I even hear my parent’s telling me Mac’s are more secure!  I doubt this will perception will change any time soon, but it is a little vindicating to see reality starting to bubble up in the press.

President Skroob: [enters after the interrogation of King Roland] Well? Did it work? Where’s the king?
Dark Helmet: It worked, sir. We have the combination.
President Skroob: Great. Now we can take every last breath of fresh air from planet Druidia. What’s the combination?
Dark Helmet: 1 2 3 4 5.
President Skroob: 1 2 3 4 5? That’s amazing! I’ve got the same combination on my luggage! Prepare Spaceball 1 for immediate departure!
Dark Helmet: Yes, sir!
President Skroob: And change the combination on my luggage!

It may seem like a juvenile comparison, but the above is actually not too far off when it comes to the passwords people use.  Almost a month ago, a security firm called iMPERVA analyzed the passwords of the 32 million accounts that were exposed in a recent hack of the RockYou service (full report in this pdf).  As Ars Technica highlights, the results were not pretty.

…about a third are less than six characters, and half are vulnerable to dictionary attacks. The most common password was 123456, and it was followed by 12345, 123456789, and Password. iMPERVA estimates that someone with a slow DSL connection could access one account a second using a dictionary attack.

To exacerbate the problem, it appeared that RockYou was pretty amateurish in their approach to security.  So not only were the passwords weak, it was just as easy to expose the entire password database.  In other words, many sites either don’t care, or don’t care to spend money, on making sure you are secure.

So what constitutes a strong password?  There is plenty of guidance out there.  The report quotes NASA Recommendations, which are fairly consistent with other recommendations.  These are probably the same recommendations some of you deal with at work.

1. The password should be at least eight characters
2. It should contain a mix of four different types of characters – upper case letters, lower case letters, numbers, and special characters such as !@#$%^&*.
3. It should not be a name, a slang word, or any word in the dictionary. It should not include any part of your name or your e-mail address.

The report goes further by recommending you use different strong passwords for each site you visit.  Although this sounds great from a security perspecitive, it is also unrealistic.

Typically my approach is to use a similar password (with slightly different combinations of case and special characters) for sites that I consider throw away.  Yes, they may have some of privacy information, but nothing too damaging.  Think WashingtonPost.com or Slate.  HOWEVER, for important sites like banking and email, I do use a different unique password.  These sites are simply too important if they are compromised.  One technique is to use a sentence to create a password such as “This little piggy went to market” might become “tlpWENT2m”.  That nine-character password won’t be in anyone’s dictionary.”

And of course you need a strong password for Facebook to prevent Statusjacking.

Of course then you have to remember all the different passwords.  There are some apps out there that actually do help with this.  I am going to take some time this week to take a look at solutions that will work on my PC and my Droid.

The real solution is to get rid of passwords completely and adopt stronger forms of authentication.  I blogged about awhile ago, that will only really happen until it becomes prohibitively expensive and painful for banks, credit card companies, etc to support just passwords.

The Certificate Revocation List Distribution Point (CRLDP or CDP) is the attribute in a PKI certificate that tells a relying party where to retrieve the signed binary file that contains a list of revoked certificates (there are other reason codes that can be used, be most clients essentially still interpret those certificates as revoked).  This file is generated by the Certificate Authority (CA) on a regular basis.  This is one way that applications and systems can verify the revocation status of a certificate (there are other methods as well).

The challenge associated with CRLs, and the CRLDP for that matter, is getting those files down to each relying party.  This is mainly a problem is larger PKIs.  In smaller PKIs, the CRLs are small enough that clients and server shouldn’t have too much trouble downloading the files (although some CRL retrieval implementations are very brittle).  For larger PKIs, this becomes more and more of problem as the PKI grows.  The CRL files get larger, and since each CA issues a CRL and larger PKIs may have multiple CAs, there may be multiple files to contend with.  As your users use your PKI more, more relying parties have to verify those certificates.  The bandwidth demands can grow exponentially, stressing your infrastructure and potentially preventing some relying parties from actually retrieving the information.

Early on in PKI, LDAP was used for many CRLDPs.  However, LDAP is actually blocked at some firewalls.  In addition, as LDAP is an older protocol, it doesn’t offer you the same advantages as using a HTTP reference.  By using HTTP in the CRLDP, you can take full advantage of HTTP 1.1 enhancements like resumption and compression.

However, one must be cautious to not get too fancy on how they actually serve the CRL content.  Most PKI implementations on the relying party side are fairly simple.  There is typically no user interaction when retrieving the CRL…it happens in the background.

In my experience, it is best to take advantage of what web servers do best…serve static content.  It is tempting to make use of scripts or applets in serving CRLs.  One not make the reference a “dynamic” URL that includes the passing of a parameter to Java App?  That is certainly an option, but I truly believe that in PKI where you can make it simple, keep it simple. In addition, many web proxies will actually not be able to cache this content without manual intervention (although to be fair, many PKI implementations use http conventions like pragma: no cache to force the retrieval of the freshest CRL).

So instead of http://pki.company.com/crlscript?CA11, use http://pki.company.com/crls/CA11.crl.  Local users and networks can then easily replicate this directory through mirroring using standard scripts, FTP clients, and/ordownload managers.  By locally caching the content, the Infrastructure piece of your PKI will incur less bandwidth stress and you’ll have less headaches.

I actually used WordPress’s “Tag Surfer” feature for the first time today, and stumbled upon a post on Identity Blogger.   In his post, Jeff Bohren discusses the challenge of getting users to adopt passwords.  He also references a post by Mark Dixon on the same topic.

I think both articles make good points…intellectually it makes a TON of sense to get rid of passwords.  Mark actually makes an interesting point that passwords are like seatbelts.

It was ease of use, not a technology-driven obsession with safety,  that led to wide adoption of the seat belt.

What I do not agree with is why seat belts were adopted.  I don’t think it is just because seat belts are easy to use and they make us safer.  A lot of the reason that I think a lot of people started to use seat belts is it because it became law.  States started mandating seat belt use in 1984, and very quickly the states all fell in line and start adopting it.  So instead of choosing to use seat belts, people were required to use seat belts or they broke the law.  A fortunate side effect to making this a law is that now for generations that drive after this law was enacted (like my own), wearing seat belts is second nature.

I believe that a similar kind of action is going to be needed for web applications and enterprises to get off passwords.  However, it may not be the Government that actually steps in to mandate this…at least not directly.  As it stands now, banks and credit card companies have the ability to write off fraud when accounts are stolen.  So the cost is really passed on…they aren’t really paying the $40 billion plus in fraud every year.  But what would happen if banks and credit card companies were limited in how much fraud they could actually write off?  I think that all of a sudden you would see a HUGE uptake in the use of improved identity technologies and the discontinued use of passwords.  Users would be forced to stop using passwords b/c the banks and credit cards would be financially dis-incentivized to support them any longer.  Of course the financial institutions would still find a way to pass the costs onto the consumer or the government…

A quick and dirty case study for you.  DoD has been issuing smart cards to their population of 4+ million for years.  The primary use for a long time was secure email.  It wasn’t until it was mandated by DoD that the cards be used for log on to networks and applications that passwords finally started going away.  Sure it was painful, but the networks are now more secure b/c of it.

In my experience, people don’t necessarily change b/c it is good for them or b/c it is easy.  They do it b/c there is a dis-incentive to continue the status quo.

Tidbit from a recent article on FCW detailing on the Homeland Security Information Network (HSIN) was recently hacked.

The hacker or hackers gained access to the data by getting into the HSIN account of a federal employee or contractor, McDavid said.

And some quick details on the sophisitcation of the hack:

McDavid said he did not know of other successful hacks into the platform. He called the tactics used to gain access to the user account “very sophisticated.” However, he said the amount of data accessed was relatively minor and that officials have been able to map exactly what files were accessed.

Any bets on whether or not this was really just a simple password or social engineering hack?

Saw a couple of posts throughout the Blackberry blogosphere in relation to a product called Cellcrypt that was presented at this past WES.  Cellcrypt enables users to make secure phone calls on their Blackberry.  The calls are encrypted using AES and the product is currently undergoing FIPS 140-2 certification.

I took a quick look at the tech overview on their website.  To oversimplify, Cellcrypt is essentially SSL for voice on a mobile platform.  When the client is installed, a key is generated for that phone so a key doesn’t have to be installed.  Although this is certainly convenient, I wonder if it is possible to import a key or even use a smart card?  This would make this an even better solution for enterprises like DoD who already have a robust PKI.

I can envision that if this works as advertised, that an enterprise could stand up the solution for their “important” mobile users.  It is not clear how the address book is managed, but as long as this is robust, why couldn’t a place like DoD roll this out for the enterprise and their DoD users?

Lastly, it is solutions like this that have to make you re-consider the viability of the SME-PED and other such custom secure devices.  Yes, the crypto on these devices is likely a bit more robust (and secret), but who is to say that a chip couldn’t be swapped in a commercial Blackberry to enable the higher level security?  Even more so, is a solution like Cellcrypt good enough for a lot of the transactions a govt agency uses?  SSL is relied on constantly.

Anyhow, love to see some more geeky details on this product.  Definitely has promise!