In memory on this day

In memory of those who died on September 11, 2001, and to those who have and are currently serving, we'll never forget. Thank you.

In memory of September 11, 2001

Posted by Marcin on Tuesday, September 11, 2007 in Other.

Buying best of breed versus bundled services

We try and secure our data, our systems, and people as best we can. We spend months evaluating and deploying firewalls, IDS, IPS, NAC, A/V, A/S, anti-spam, proxies, VPN, etc. Hopefully, you create matrices of each product you consider purchasing based on a selection of criteria that your business deems most important. In the end though, management usually considers the $ column as most important when purchasing a product. It may not be the best, not do all the things you need, but it's the cheapest. What then? You start hearing pitches for a product and ways of making the cheapest product outperform the others.

Then there are vendors that have an exceptional product in one arena, but another is inferior to another vendor's product. Vendor A bundles three services such as Anti-Virus, Anti-Spyware, and Personal Firewall, but it only excels in A/V. Vendor B dominates the market with their Anti-Spyware solution and Vendor C has an exceptional firewall. Let's look at an example pricing structure (in $ per client):

****	A/V	A/S	PF	Total	Bundled	*50,000 licenses
Vendor A	$2.50	$2.25	$3.00	$7.75	$6.00	$300000.00
Vendor B	$2.75	$3.00	$2.50	$8.25	$6.65	$332500.00
Vendor C	$2.00	$2.75	$3.50	$8.25	$6.75	$337500.00

Let's say your business needs 50,000 licenses -- Vendor A would amount to $300,000; Vendor B $332,500; and Vendor C $337,500.00 for each of their bundled offerings. If we were to pick and choose best of breed from all three vendors, we would use Vendor A for A/V, Vendor B for A/S, and Vendor C for PF. For 50,000 licenses, the total would amount to $450,000 (or $9 per client) -- over $100k more than the most expensive bundle, but is the most "secure."

Going with one vendor may make system administration tasks easier, because it's likely the products have been integrated with each other. But then again this benefit has a downside, creating a single-point-of-failure scenario in case of a vulnerability in a vendor's management software. Save the risk equations and values you come up with for some other time. Which of the solutions would you choose and why?

Posted by Marcin on Monday, September 10, 2007 in Security.

Hit and run pentesters -- the cycle repeats

I just read an excellent post by Mark Curphey on "The types of testing," part 2 in his 5 part series on "The Art of Scoping Application Security Reviews." Dre responded with some good commentary almost as long as the original post. One quote towards the end got to me:

It ceases to amaze me that people want to do review after review, quarter after quarter, year over year - for the same clients. Why allow these [helpless?] organizations to continue to make the same mistakes? In your first part of this series, you mentioned the business aspect about submitting defects into an issue tracking system instead of providing a report that is likely to sit on a desk and collect dust. I say go even further!

If your company contracts out, over and over again to the same vendor for security reviews, and each report comes back looking almost exactly the same with a different date or site, you need help! Have a couple lead developers and security guys sit down with the testing team and go over some methodologies and standards for reducing those flaws. If a vendor is really worth their salt, they will want to help you. This is a win-win situation, because your developers won't put out so many of the same flaws, and two, the vendor will be able to concentrate more on less common/perhaps more critical vulnerabilities.

Posted by Marcin on Tuesday, September 4, 2007 in Security.

HBR case study on data breaches

Boss, I Think Someone Stole Our Customer Data

The way Hoff puts it, sounds all too familiar. I can't count the number of times I've heard people talk about their systems and believe they're as secure as can be because they did one, some, or all of the following:

SSL
Encrypted data
X compliance/HackerSafe
Disable unused services and close ports
Penetration test
Vulnerability scan (No, a vulnerability scan is not the same as a pen test, and an Nmap scan is not a vulnerability scan)
Code Review

And then you say, "a determined hacker given enough time could break into it anyways." Ah! Should "good enough" be allowed in a security professionals' vocabulary?

Where was the Flayton's computer security incident response team (CSIRT)? The Secret Service was conducting surveillance to try and catch the perpetrator red handed. A competent CSIRT (not affiliated with any of the employees with access to the system) should have been on task right away to realize whether the affected cards was a result of a data breach at Flayton's. I agree with Jay Foley of the Identity Theft Resource Center in San Diego and think the CIO didn't have a grasp of the situation at all, before and after the incident.

CEO: "Are you saying, Sergei, that we're not actually PCI compliant?"

CIO: "We meet about 75% or so of the PCI requirements. That's better than average for retailers of our size."

CEO: "How have we been able to get away with that?"

CIO: "They don't scan us every day," Sergei demurred. "Compliance really is up to us, to me, in the end."

Yah, I think we really need to stop using compliance for needing security and doing security for compliance, and actually start doing security to be secure. A survey conducted recently of 250 CIO's and CISO's states 99% feel more secure this year than last. What??!

Posted by Marcin on Thursday, August 30, 2007 in Security.

Articles in my "toread" list

I've been backlogged lately, mostly due to taking a trip up to Lake Winnipesaukee, NH, getting a BlackBerry 8800, and my birthday. I've added a whole bunch of articles to my "toread" list, which I hope to get to soon and comment on.

Posted by Marcin on Wednesday, August 29, 2007 in Security.