Security Renaissance

Promoting the art and mindset of information security

Ren - ais - sance:

(lowercase) a renewal of life, vigor, interest, etc.; rebirth; revival: a moral renaissance

StolenID Search follow-up

February 1st, 2007

A couple days ago I wrote about StolenID Search in my Computerworld blog.  Since then I’ve noticed that I was a bit late in the game in analyzing this.  Folks like Martin Mckeay, AndyITGuy, Dana Epp, and others heard about the service and have similar postings.

I even see that Scott Mitic, CEO of TrustedID, tried to address our concerns at the TrustedID blog.  I’m still not on-board and I believe that many of the objections raised by myself and others are valid. 

Here are a few of my still-lingering concerns:

First, the TrustedID blog posting seems to primarily focus on the initial search offering located at their homepage (http://stolenidsearch.com/).  For instance, the post states that no data is retained from searches conducted at that page.  But, if a user signs up for their monitoring service, the data *must* be kept; therefore, I see this as a red herring.

Secondly, Mr. Mitic states that entering your SSN or CC # in their search tool is safe because it is not accompanied by other identifiable information.  To a certain extent, I can see his point on this—and this view is codified by many of the state breach notification laws which state that notification of a breach must occur only if you lose an identifying number along with the information needed to tie that number to a specific individual (i.e. CA SB 1386; AR SB 1167).  However, Mr. Mitic doesn’t address the fact that, after the initial search, users are encouraged to sign-up for their service (which asks for an email address).  As I stated in my Computerworld post, there are many ways to use an email address to find out the name (or other information) of its owner.

Thirdly, the TrustedID blog posting also mentions that their site is “built using the highest levels of security available on the Internet.”  But then goes on to say that it is “not appropriate to explain details.”  Again, I understand where he is coming from here but this does not address the concern.  Some high level details are most certainly appropriate.  I wouldn’t care about vendor products being used, patch levels, etc…, but it’s difficult to just accept that they use the “highest levels of security” without knowing what they consider as such.

Lastly, the blog posting addresses some concerns related to their site promoting a new style of phishing attack.  I agree with Mr. Mitic’s statement that almost any successful site will generate copycats – but I don’t think that this is the primary concern.  As stated by myself and others, security professionals have been training users for years to not blindly enter this information.  By putting out a “legitimate” site that flies in the face of this advice, StolenID Search may be taking the industry a step back by desensitizing users and making them more susceptible to phishing ploys.

I believe that there are alternative ways for consumers to determine if their information has been compromised.  Here is a short list taken from my initial Computerworld post. 

  • Sign up for a credit monitoring service (or just pull your credit report quarterly)
  • Google it yourself.  Don’t just rely on the standard Google query – use the deeper search methods typically referred to as Google hacking (for more info, check here, here, and here
  • If you bank online, check your account daily

Let me know if you have additional suggestions, comments, or criticisms. 

PS — while writing this, I also noticed that both Martin and Andy have updates (here and here, respectively).

Security professionals deal with the law of unintended consequences every day.  For instance, vendor x creates “cool new widget,” a feature-rich application intended to enrich the otherwise sad and pathetic lives of every man, woman, and child on the Earth.  However, vendor x (being shortsighted, ignorant, stupid, or just plain human) didn’t realize that “cool new widget” could be used to do some type of horrible and irreparable damage to Lithuanian field mice… 

Ok, so that’s a little off the deep-end.  An example that most people can relate to is Microsoft’s implementation of macros within the Office suite.  These little scripts were designed to give users greater control, flexibility, and power by allowing them to script sequences within Word, Excel, PowerPoint, and other apps.  However, MS did not realize (or didn’t care) that this feature set could be misused.  The result: rampant malware which utilizes the embedded Visual Basic engines within these applications.

If I’m involved in a security risk analysis, I always try to determine what unintended consequences may result from the implementation of the project in question.  I also try to take the opportunity to talk about such unintended consequences with those involved in the project.  That being the case, I was happy to stumble across the article, “When Good Cows Go Mad,” on Wired.com.  The article is purely fictional satire (opening with an attempt to bio-engineer cattle which are immune to mad cow disease, and ending with the aliens extinguishing the Sun)– but can be used as a great tool for demonstrating the law of unintended consequences.

New resources section

January 16th, 2007

In my last post, I mentioned that I was thinking about adding a resources section to the site.  Well, I now have the beginnings of this section up.  It is located at:  http://SecurityRenaissance.com/resources and currently contains the following essays:

I’ll be adding several more essays over the next few weeks — and as I have time to convert them to PDF.

Hopefully these will prove beneficial (or at least somewhat interesting).

 

Mobile malware research

January 9th, 2007

I am currently pursuing a Master’s Degree in Information Assurance (MSIA) through Norwich University and would like to share one of the papers that I prepared for last semester.  The paper sums up quite a bit of research on mobile malware, its history, and what the future holds.  In addition, I intend to make this a “living document;” so there should be periodic updates.

Those who have been actively studying mobile malware for awhile will probably not see much new information – but I believe that this paper does a decent job unifying a lot of disparate information.

Here is a link to the PDF copy (mobilemalware.pdf).  Feedback (both positive and negative) is always welcome.  Send any comments to SecurityRenaissance [at] gmail [dot] com.

Also – I’m considering posting a few other papers on my site.  To that end, I will be creating a “resources” section and will post an update when it is available.

– Perry

Expressions of Privacy

January 8th, 2007

I ran across a very interesting article on Economist.com that discusses how rules regarding the sharing of private information can be expressed logically. The article’s title is The logic of privacy: A new way to think about computing and personal information.
Here is an excerpt to wet your appetite:

For example, the Gramm-Leach-Bliley act states that “a financial institution may not disclose personal information, unless such financial institution provides or has provided to the consumer a notice.” This is expressed as:

IF send(financial-institution, third-party, personal-information)
THEN PREVIOUSLY send(financial-institution, consumer, notification)
OR EVENTUALLY send(financial-institution, consumer, notification)