Showing posts with label Best Practice. Show all posts
Showing posts with label Best Practice. Show all posts

Tuesday, June 5, 2007

Responsibility is Everyone's Job

The software developers constantly talk about responsible disclosure.

Responsible disclosure is basically defined as informing the software developer of a vulnerability so that the vulnerability can be researched and fixed. This is compared to full disclosure where the vulnerability is announced to everyone without giving the software developer a chance to fix the vulnerability. Contrast this with the economic pressure for a software developer to reveal a vulnerability, which is none.

The spectrum consists of Full Disclosure (tell everyone), Responsible Disclosure (tell the developer), and Non-Disclosure (tell no one). Without going into details suffice it to say the responsible disclosure is currently mainstream.

The question is how the developers handle fixing the vulnerability. The general thought is that a responsible company would put resources into fixing these as soon as possible, but these comercial developers are, for the most part are in business to make a profit. I am not including open source developers in this post.

Now for two examples of how Microsoft has handeled responsible disclosures.

The ANI exploit, which I wrote about in Vista Smista& ANI Exploit. The vulnerability was disclosed in December of 2006 and not fixed until exploits where released in March. An quote from my previous blog is below and more details are in my other post mentioned above:
In short this was disclosed to Microsoft in December of 2006. Apparently the first report of this vulnerability was used as an exploit was March 28th. Due to the wide spread use of the exploit several third parties released interim patches... Microsoft
reacted, as it tends to do when third party patches are released, and the news
media starts to publish... Microsoft released the official patch out-of-cycle on
Tuesday the 3rd of April (instead of today the 10th of April).

Just recently, the end of May 2007, a vulnerability in Microsoft Web Server IIS 5.X where authentication can be bypassed, was announced. However this vulnerability was discovered December 15th 2005 (no this is not a typo) and was subsiquently responsibly disclosed to Microsoft. Apparently Microsoft finally decide to publically disclose the vulnerability, but without a fix. Unless you consider paying for an upgrade to Windows Server 2003 and IIS 6.0 a patch.

Keeping in mind thath these are just two examples where:
  1. Microsoft failed to fix a known vulnerability for several months until an exploit was released.
  2. Kept a vulnerability secret for over a year and then releases the information and requires a paid upgrade to the latest code for a fix.

I think Microsoft should re-evaluate their responsibilities as a good citizen or netizen.

Thursday, May 31, 2007

When Google isn't Google: Google-analytics Compromised

It has been reported the the popular Google Analytics has been compromised. The details are in the ISC Diary Entry titled Google Counter ... isn't.

What this means to the average user is that any web site that uses Google Analytics, and there are more than a few that use this free service, will attempt to infect your computer.

Wat is the average user to do? Disable javascript and break most web sites? Which is almost like putting bars on your windows and refusing to leave the house.

Well it isn't a secret what I do I use Firefox and the noscript extension as my main defense against this. I normally leave anything not required for accessing a site, including Google Analytics, disabled. I was initially surprised by the number of javascripts attempting to run from sites I had not directly connected to. I would describe this as checking who a visitor is bringing with them when they want to visit my house.

sites that where used to See "Drive by What?" for my latest blog entry on the subject, or check here for all my references to noscript.

Sunday, May 20, 2007

Videos

Who knows you better than your peers?

It seems that there was a contest for university students to create videos to increase awareness of computer security among university students.

The contest was conducted by the EDUCAUSE/Internet2 Computer and Network Security Task Force, the National Cyber Security Alliance, and ResearchChannel.

Even though the intended audience is college and university students the videods are entertaining and educational for other audiences. I suggest you check the out the videos here.

Monday, March 26, 2007

Credit vs. Debit

Is a credit card better than a debit card, or vise-versa.

In the US the credit card wins hands down, by federal law the credit card is responsible for fraudulent charges to your account. No such protection for debit cards exist, even if they are used as a "credit card."

A short, and unfortunately true, story to illustrate the issues with a debit card.

A man goes through a fast-food drive through and pays with his debit card. The cashier hands back his debit card, which is put back into his wallet for safe keeping.

The next day the man receives a call from his bank. His account is over drawn by several hundred dollars. After a brief discussion it becomes apparent that there where multiple purchases made with his debit card after the man nused his card at the fast food drive through window.

The bank explains that the card was stolen, the man disagrees, but finally takes his card out of his wallet. Right bank debit card, but not his name or number. It is a card reported stolen. The cashier at the fast food place switched the cards...

An expensive way to learn that debit cards are not protected by law.

Best Practices:

  • Only use your debit card at your banks ATM.
  • Use your credit card for purchases.
  • Your spouse or significant other should use a credit card with a different account/card number* on it.

* Most banks will issue a different card number for each card issued for an account. This allows tracking who spent what, and replacing one lost or stolen card while still being able to use the other card(s).