StillSecure, After All These Years

Not 'who you gonna run to" but "who you gonna call"?

You could try ghostbusters, but don't bother calling the PCI council. So says Mike Fratto and Martin McKeay in response to my earlier article about when you have an obligation to go public. Of course I was responding to Martin's earlier post on the TJX employee getting fired. What all three of us agreed on though is that there is no place or person that an employee or any other person frankly can call to report a company that is not in compliance with the PCI.

Mike Fratto says "PCI has no teeth because VISA/Mastercard doesn't want to bite the hands that feed it." Martin says the PCI council has established a way for people to report violations because "that’d make the Council responsible for acting on those reports. And that’s something they really, really don’t want." So are the PCI regs toothless. I wouldn't exactly go that far. I think we have to draw a distinction about having the power to act versus actually exercising that power. Mike is right, so far the PCI council has to exercised the powers they were granted to impose sanctions and penalties. That doesn't mean they won't in the future though. I think they will have to make some "examples" otherwise people are going to begin to ignore the requirements all together.

Without some process to report violations the credit card companies are inviting the government to step in. This is exactly the reason as Mike Fratto points out that they imposed the PCI regs to begin with, that is to keep the government out. Until they do though, I think going public and the court of public opinion may be the only recourse.

Are current vulnerability and compliance testing tools like answering the phone at 3am?

I was at a meeting for a potentially large customer engagement for vulnerability assessment and compliance testing last week.  The requirements for this customer were not unusual. They wanted to test for conventional CVE type vulnerabilities. Additionally, they also wanted to test for configuration compliance. Hotfixes, patch level, AV, etc.  This direction is where a lot of the traditional vulnerability management solutions have been heading.  Whether adding a separate compliance module or audit and local check capability, most of the traditional vulnerability scanning solutions offer some coverage in this area.  However, in speaking to this potential customer and in thinking about their needs, an inherent problem with this solution is that it is only as good as the devices that are available on the network when the scan takes place.

In traditional vulnerability scanning, when the scan takes place was not as much of an issue.  Usually you are scanning servers and other devices that are on the network 24/7. In fact doing the scans during off hours was usually preferred. Too many of the network based vulnerability scanners took up too much bandwidth and other resources to accomplish during the prime time hours of the day. In compliance scanning though, you need the status of laptops, desktops and other devices that may not be connected to the network 24/7.  Therefore it is important to reach and test these devices when they are on the network.  That is the rub.  How do you really make sure the devices connecting to your network are compliant if you are only testing them at a point in time that usually they would not be on at?

This problem reminded me of the Clinton-Obama flap over who answers the phone at the White House at 3am.  That is an important question for who is president, but for compliance, nswering the phone when someone is there to talk to is more important.  I think this is where NAC provides an advantage.  By utilizing NAC to detect devices coming on the network and than using a low impact NAC/compliance test as well as traditional vulnerability scanning, you get a picture of vulnerability posture and compliance status as of the last time they accessed the network. You can still do follow on tests at any time you desire, but at least when a device is logging on you are sure of a test.

Will NAC supplement vulnerability testing in this manner? I think so.  Many customers we have spoken to about this like the idea of "scan on connect" and we have already enabled our own NAC product Safe Access and vulnerability management platform VAM to do this.  What do you think?

Rich Mogull does his best Stiennon imitation, says GRC is dead

Some of the Stiennon "magic" must have rubbed off on Rich Mogull when they were both at Gartner or maybe in a case of the imitation being the sincerest form of flattery, Rich M secretly admires Richard S. In any event taking a page out of the "xxxx is dead" playbook, Rich writes that GRC is dead. In fact Rich says it was stillborn and never really alive. There are many things that Rich says in his article as well as Gunnar Peterson's article that he references, that I agree completely with. However, overall I think Rich's fatal mistake is one of Titanic proportions. He is mistaking the tip of the iceberg for the entire mountain of ice that is under the water and not as easily seen. The reports and dashboards of GRC products represent the by product of much of the real work and value they bring not just to the "C" level but to the security practitioner who is tasked with ensuring compliance as well. I am seeing the compliance workload fall on the already over worked, underpaid security guy time and time again and they need help with it!

I know people like Mike Rothman say compliance is bull and if you just follow good security practices, compliance takes care of itself. However, lets be real folks, between PCI, SOX, FISMA, etc., compliance is driving budget in the security industry. In an industry where the "security guy" just did not have the tools to push through budget for the resources required, compliance has become the sledgehammer that the CISO and other security types use to crash through the doors into the CFO's office and get the budget required.

Before I delve further into why I disagree with Rich though, let me state where I do agree with him and Gunnar for that matter. I do agree that a by-product of compliance has been a move towards running your business as "audit-driven rather than business-driven". Somewhere along the line we have forgotten that the rules, regulations and statutes that compliance is driven by were put in place to provide a minimum of acceptable security and confidentiality to protect sensitive information. It was supposed to be about protecting the data, not about checking off the compliance box! I agree with Rich that it has become a way into the C-level office. But what is so bad about that? Symantec has been selling their security into the CFO for years. Rich not having worked at a vendor, I don't know if you realize how hard it is for the security folks to get budget approval for the tools they know they need. In order for security to get its fair share of the budget pie, it is imperative that security budget decisions are made at the C-level. If the security team can't get the approval, the security vendor is going to try and help.

While dashboards and reports are the tip of the iceberg and the shiny baubles that are used by the GRC vendors to get the attention at the C-level, I think that the bulk of the work takes place below the water. It is making sure that in fact the enterprise is in compliance. Making sure that everyone has the latest patch level, has AV installed and that data is protected from leakage is the real work. Testing and ensuring this is the real job of GRC, the reports and dashboard is just the way you can show it working. Rich I think you are the one being short sighted if you think these products are just about the reports. Without actually doing the analysis and investigation the reports are meaningless. In my mind is much like SIM reports. Without actionability and correlation, how much value are the SIM reports?

GRC is a needed tool in todays security practitioners tool kit. They are being placed in the position to ensure compliance and they need the ability to do so. They also need help getting the budget approved for the tools they need to do the job. We can rant all we want about compliance for compliance sake being asinine, but the fact is that is the world we live in right now and rather than spitting into the wind, lets figure out how to make it work best for us.

SC Magazine article on clarification of PCI requirements

Martin and a bunch of others have written about the recent clarifications around section 6.6 and 11.3 of the PCI DSS. Jim Carr over at SC Magazine ran an article on it today that he interviewed me for. While I am not the PCI expert Martin is, I was happy to contribute my 2 cents (ain't I always).

Anyway, sounds to me like these new clarifications are going to wind up with a lot of web application firewalls being sold.  Here at StillSecure we are thinking about some ways to take those to the next level as well. Hopefully we can announce something soon on this.  Overall, just another indication that right or wrong, compliance is driving a lot of the spending in security today.

Why did the NAC vendor cross the road?

Because a customer asked him too, of course. The same answer applies to the question Ron Gula asks over on his Tenable Network Security blog, about why there aren't any NAC vendors that are CIS certified or speaking XCCDF.  Frankly, Ron is right, I am not aware of any NAC vendors that are CIS certified. The reason I think is that there are few if any customers who have asked for this.  There are so many features that customers are asking for, that virtually every NAC vendor is up to their ears providing, there is no time to put in what is a nice to have or may make sense, but no one is standing up and asking for or willing to pay for.

From a technical point of view I don't think it would be too hard for our Safe Access NAC to perform this type of test.  I don't know about other NAC products that don't have the deep testing Safe Access does though.  On the other hand, you would think with so many of these NAC products using Nessus and Nessus already having this functionality, they would be able to do it already.  I guess the fact that these same NAC vendors don't like to admit that they use Nessus prevents them from claiming some of the benefits that using Nessus affords them.  But I digress. In some of our DoD engagements I know we are auditing against standards put forth by DoD. I don't think it would be any more intrusive than some of these tests we already perform. I also believe you will see FDCC type audits in Safe Access shortly. I am not as familiar with the XCCDF format but will have a look.

I also agree with Ron that using a tool such as Nessus and a NAC solution like Safe Access to talk to each other and using a standard like XCCDF to communicate a common standard for testing and enforcement would be a good thing.  I will have to talk to Ron off line on that one.

Most of all though, Ron is right again in that if you want your NAC vendor (or any vendor for that matter) to implement a certain feature, you have to speak up.  Our customers input in terms of  what they need to make our products more useful and more valuable to them is the best way we have of improving our products!

Yesterdays argument, tomorrows solution

One of the classic mistakes that armies on the losing side make is fighting the next war with the last wars weapons and tactics.  I am afraid Mr Hoff is guilty as charged in talking about the recent Google/CapGemini deal.  In case you have not heard, CapGemini will offer Google Apps to the one million strong corporate desktops that it services.

Chris does a nice job of explaining how CG will make money on this and some of the advantages of Google Apps. However, Chris seems to side on the camp of those who think that SaaS based, centrally managed applications and the data that goes with it, will present compliance and security concerns that could slow adoption. 

I say poppycock to that.  I heard the same thing about Qualys storing vulnerability data 5 years ago and over the intervening time have seen that argument melt away except for maybe in the federal government space.  In fact Qualys has now become the tester of choice for PCI compliance in many cases.  But beyond that, the whole issue of outsourcing application hosting brings me back to my days at Interliant, an early entrant into the ASP market.  We hosted Lotus Notes, PeopleSoft and other enterprise level applications. As well as managed security (mostly checkpoint firewalls, which was sold to Akiva).

One thing that we learned the hard way at Interliant is that people will not outsource applications which they consider critical and core to the business.  So for instance, if they were an accounting firm, they would probably not outsource the hosting and management of their accounting software.  However, critical, non-core applications are good candidates for outsourcing.  I think for the most part, this is exactly where the Google Apps fall.  I think the success of hosted CRM like Salesforce.com also shows that people are willing to outsource critical, non-core applications.

Now the fact that it is Google after all, raises in my mind anyway, two other issues. One is the privacy of my data from Google.  Is Google going to use that to hone the ad words they serve up to me?  The other is that as Google continues to grow, will it suffer from Microsoft like "evil empire" syndrome, where people attach dark aspirations to everything they do.  I guess we will have to see how this plays out.

Would you pick your restaurant by the security of your credit card data?

Was reading a good article by Jaikumar Vijayan today in ComputerWorld about the steps the Ruby Tuesday restaurant chain is taking to better ensure the security of their customers credit card data.  I applaud what Ruby Tuesdays is doing, upgrading their POS systems to not store any credit data, eliminating middle men who represent another potential hole and using stronger encryption. 

All of this is good and I like their salad bar on top of it.  Then I read this quote, "This, in reality, is not helping us create more sales," Ibrahim said. "This is purely about the privacy and security of our customers".  This is from Nick Ibrahim, senior vice president and CTO at Ruby Tuesday. It seems that the only reason they are doing this is to comply with PCI regulations.  I know I have said in the past that security is good for business and if you run a secure operation, compliance will take care of itself.  However, that does not seem to be the case here.  Ruby Tuesday is flat out saying that putting in better security is not going to help put customers in the seats or increase sales. They are doing it for compliance sake alone. 

Is this logic faulty.  Would you be more likely to frequent Ruby Tuesday over say a Chili's, if you know your data is safer at one over the other?  I don't know if it has come to that yet, but if I were Ruby Tuesdays I think I would try to use my enhanced security as a reason to come here versus the other guy.  What do you think?  Would you consider the safety of your credit data in choosing a restaurant? Are you still shopping at TJX stores?  I wonder, am I being too much of a security freak?

Compliance is a by-product of a Policy Driven Network

Alex Bakman has been really writing some good stuff lately. I was reading an article on his blog the other day and it triggered something in my head.  That is one of the nice things about reading the spliced feed from the Security Bloggers Network.  You are reading the combined output of over 50 blogs in one place.  Sometimes I don't even realize where the feed is from unless I take the time to look.  Anyway, back to the subject. Alex writes about an article by David Greene of BMC in itworld. Both Alex and David point out that rather than running a keystones cops firedrill every time a compliance audit or event takes place, wouldn't it be better to build compliance into your process or automate compliance.  David points out how much more really valuable this.  Rather than practicing good security for compliance sake alone, practice good security for security's sake and get compliance as an afterthought.  Makes perfect sense to me.

This is exactly what we are doing with one of our customers at StillSecure. Our customer is providing network and security services to another organization and the contract is governed by a number of SLAs. These SLAs include both network and security areas. Prior to working with StillSecure, each audit was essentially a fire drill for our customer. They would run around making sure that devices were all patched and shift people from one group to another to make up short falls, etc. Because of the nature of the contract, they became acutely focused on meeting compliance rather than building processes that allowed compliance to become a by-product of their daily operations. Our proposal which they have adopted calls for a "policy driven network". Under this plan, the network managers have at their fingertips a list of every device's status as of the last time they logged onto the network. This is true for managed and unmanaged devices, wireless and wired, remote and local.  Now when they are audited,  they just run reports of those devices and the latest status is right there.  No scrambling around, no keystone cops, no chaos.  Compliance with the audit is built into the policy driven network. Please don't mistake my message here - products are only one piece of the puzzle, albeit it an important if not frankly a large portion - they are just a means to an end. The real pony in here is the architecture / framework / approach to driving compliance. We worked with our customer to embed it into the fabric of their network through our policy driven network approach.

So, how did we help accomplish this?  Good question.  We started by using both our VAM vulnerability management solution and Safe Access, our NAC product.  How it works is that policies are set in Safe Access and VAM as to what profiles and configurations are allowed and not allowed.  VAM does its regular scanning on a scheduled basis.  On top of this, Safe Access detects every device as it comes on the network.  Unlike a normal NAC practice though, Safe Access alerts VAM to the presence of the device and VAM can initiate a full vulnerability scan in the background. Of course the network administrators also have the ability to initiate a NAC test at the time of log in as well.  All of this information, as well as other data such as IDS alerts and syslog are correlated and stored in VAMs on board database.  Of course, you could do this with similar technology to the StillSecure products, assuming they have similar interoperability.

In the future we will take this to the next level by combining the post-connect capability we have built into Safe Access and policing even more of the network activity.  This is a perfect example of providing real security and compliance by building it into the network process and not doing a compliance audit, for compliance sake alone.

FISMA is too hard, lets blame the vendors

A new member of the Security Bloggers Network is Alex Bakman, the founder and CTO of Ecora Software.  I first became aware of Alex's blog when he linked to me on Security Consolidation.  Alex has a good article up today about the call to revamp FISMA and specifically on a report from an RSA panel featuring Alan Paller of SANS and Bruce Brody, currently of CACI, but formerly the CISO (I think) of the Veterans Affairs and Energy departments.  For those not familiar with the federal information security market, FISMA is the  Federal Information Security Act.  Under this act, federal agencies are graded each year on their compliance with the act.  We usually read about them in the news, as this agency and that one receives failing or poor grades. 

It is generally agreed that we need to do something to improve the security posture of the federal government.  However, as Alex points out I think Alan Paller is off base when he blames the security vendors and calls for "products security configured by default".  As Alex points out, one size does not fit all when it comes to IT configurations. It is unrealistic to think you can have a default configuration that will be right for everyone. 

My own experience with the federal government leads me to believe that the issue is more around resources and expertise.  I can't tell you the number of times we have run into issues with our federal customers who due to budget considerations do not have the resources to adequately support the software they purchased.  Then when they do have the budget, the skill set does not match. Linux guys trying to do Windows, Windows guys on Unix, network people on the desktop, etc.  I think if they would put better management and budget around implementation and operation of security tools, FISMA scores would go through the roof.  It is not that the government does not have the right tools or good tools, it is that they are not being used correctly.

Farnum getting fiesty!

Michael Farnum has been really letting loose on his Information Security Place blog lately.  If he doesn't watch out, someone is going to accuse him of being a blog bully or even worse, a Rothman wannabe!  The latest victims of his ire are Cisco and Cybertrust.  It seems Cybertrust has given their rubber stamp of approval to some Cisco set ups that will somehow make the user PCI compliant.

Michael is right on here.  There is no magic wand or correspondence course for PCI compliance  (well maybe Qualys, but I digress).  I don't care what subject matter expertise Cybertrust used to validate the Cisco solutions to make sure they are optimized for PCI compliance. Every merchants situation will be different. 

We went through the same thing getting our solutions certified to help with PCI.  Though I can show how the StillSecure solutions can help and what specific sections of the PCI regs each StillSecure solution can help with, it still does not give you automatic compliance.  Like Michael points to, Michael Crawford on ComputerWorld-Australia calls BS on vendors selling PCI compliance. 

Moral of this story is there are no short cuts to good security.  That sounds pretty pragmatic to me. Michael keep up the good work!

What's a poor security guy to do?

I was talking to a good friend of mine tonight, a security manager, whose company is in the throes of going through a PCI audit.  It appears that just as my friend warned his employer on numerous occasions, they are going to fail their audit miserably.  I am somewhat familiar with this situation, as at StillSecure we have had several companies come to us after failing their audits and purchase all three of our products to help pass the next one.  Lets face it companies don't care as much about being secure, just about passing their audit (that is another story and an ugly truth in security that we can discuss another time).

My question to my friend though was, how will this reflect on him.  My friend said, hey worse comes to worse they can fire me.  I think this would be highly unfair, as he has been warning them for months and they have refused to hire the people they need and buy the products they need to improve their security.  However, my question went beyond his present job.  As the security manager at his company, does the fact that they failed their audit come back to count against him when he goes to look for another job?  How can he prove to another potential employer that he tried to get them to provide the resources they need?  Should a security manager walk off the job when his employer does not provide the minimum for what is necessary?  Security is always a battle for resources and budget, but when does the security guy's reputation demand he walk?  I am not sure myself, but am interested in your opinions.  Please comment!

PCI compliance tools

As Mike Rothman points out, I am a vendor (actually Mike, I just work for a vendor), so I walk a thin line when it comes to competitors products. Make no mistake about it, I am partial to StillSecure products.  However, over the months on this blog I have tried to give credit where credit is due.  On that note, I wanted to talk a little about PCI compliance. Actually we have been doing a lot with all of our products to help our customers to comply with the various PCI standards.  You can read all about it here.  Be sure to check out the matrix that shows how each StillSecure product helps with what specific provisions of the PCI regs. Next week we should be announcing some more news around how we can help with PCI.

To be fair, I want to point out a new service Qualys has come out with aimed at SMB/SME merchants who have to generally perform self-tests for PCI compliance.  Called QualysGuard PCI, it is a pretty slick all-in-one solution for complying with the vulnerability assessment and reporting requirements under PCI for some of the lower volume merchants.  You can see a good flash demo of it here.  Now, while I think there is more to PCI compliance then just vulnerability management, I am happy to see these types of solutions coming to market.  Competition being what it is, it will drive the whole market to go one better and the eventual winner is the end user customer who gets a better product.

Todays Rothman Fable: The Country Bumpkin Security Buyer and the Security Snake Oil Salesman

Ya gotta love Mike Rothman! Even when I agree with him, I disagree with him.  In todays Daily Incite, Mike goes off on New Boundary Technologies for trying to peddle the rubber stamp for PCI compliance. Mike tells us that most vendors trade on FUD and the new PCI standards are just the latest in a long line of examples on this point.  Mike then goes off about, that there is no such thing as a silver bullet on compliance. It is a byproduct (OK, he uses the term happenstance, but I am a plain kind of guy) of good, best practices in security.  Surprise, Mike I agree with you!  When I first started in the security business years ago, FUD was certainly the driving force in selling security.  Certainly, some vendors still resort to FUD as the compelling reason of  last choice.  I do think that there is no silver bullet to compliance.  There are no HIPAA or PCI police to regulate people making wild claims, though there are PCI certified tools you can use to help with PCI compliance. 

Where I disagree with Mike, is on two fronts.  First off vendors who have spent some time on these compliance issues and are in this game for the long run, can do it right.  Not to blow our own horn, but at StillSecure, we are actually in the middle of PCI campaign right now. On our web site we have some great material that talks about the specific PCI security requirements, a matrix showing you how a specific StillSecure solution matches up to the requirement, a good whitepaper on PCI complaince and a whole lot more including some tips on passing an information security audit.  We don't claim to be the be all and end all to PCI compliance and we don't claim that you will fail your audit without using our products.  However, we can help.  This is not FUD, this is not snake oil sales, this is working hard to give customers what they ask us for and solve their everyday problems.  Sorry for the StillSecure commercial, but it was the best example I could find.

I said I disagree with Mike on two fronts, here is the second.  Mike and his friend Rich Mogull (yeah I saw the second post on this about liars and crack) make the point, that it is the greedy, lying, scheming security vendor who is duping the poor, innocent security buyer who just fell off the Turnip Truck.  Hey guys, they  may have fallen off the truck at night, but it wasn't last night!  Let me give you another view on this.  How come no matter what the vendor develops, the customer always wants what is either in the next release or wants some custom feature that they decide is a must have for them.  They push the vendor to get the most features for the least price and put as much hair and strings on the deal they can.  After all they don't want to get taken advantage of. They buy the product knowing that the functionality they say they want may not be fully baked yet, but they want it now and when it does not work as they want, the security vendor fooled them?  Mike was right originally when he said it was about mismatched expectations.  However, those expectations are as often set up by the buyer, as they are the seller.  It takes two to tango boys and one can't always blame the big bad vendor, even if the other guy is paying your salary.

Editors Note: thanks to David Shiflet, In the Turnip Truck - for providing the book I doctored up.

Another view on the NAC/NAP announcement

Jon Oltsik from the Enterprise Strategy Group has an excellent article up on the C/Net Corporate Security Blog, that has another view on this.  Basically, Jon says that both the MS and Cisco approaches are proprietary and that they had to do something to justify them co-opting an industry wide effort.  Jon says that what Cisco and MS are doing under the guise of support for IEEE 802.1x support is vintage behavior from these two.  They are taking legitimate standards and under an "open" smokescreen are hiding their efforts to "embrace and extend" the client code until it is no longer the industry standard it is supposed to be.  Jon calls for both Cisco and MS to work with the TNC/TCG standard (which to be fair MS has said they will support).  He points out Cisco claims they don't work with industry consortiums on standards, but catches them red handed in regard to their participation in SNIA another industry consortium on standards.  These are all dead on and good points by Jon.  I think his best point though is that this whole thing only applies to Cisco only networks and MS only computers.  In todays wired/wireless networked world where everything is logging on the network, you are going to need wider coverage than that.

Cisco NAC/Microsoft NAP- The mountain meets Muhammad

As a Cisco NAC partner and MS NAP partner, I have to admit I was a bit excited to see for myself what the two companies have cooked up in making their products work together.  MS and Cisco are demonstrating the new interoperable architecture today at the Security Standard conference in Boston.  Both companies put out a joint press release announcing the fact along with a white paper that details some of how they will work together. For a long time even though both companies had announced plans to make NAC and NAP work together, i was not sure if we would ever see it so in our lifetimes.  Both companies appeared to be treading into each others traditional bastions and it did not seem like they really wanted to make it work.  But, it would appear at least on its surface, the mountain has come into the middle and met halfway.  However, before we all break out into a rousing chorus of Kumbaya, lets take a closer look at what is really going on here.

What the two have put together is an " ...architecture and ... details on how to integrate the embedded security capabilities of Cisco's network infrastructure with those of Microsoft Windows Vista^TM and the future version of Windows Server®, code-named "Longhorn."." So first thing that jumps out and this is confirmed in the white paper, this will only work together in Vista and in Longhorn when it is rolled out.  Current plans are for the latter half of 2007, so don't rush out and order it just yet.  Further reading of the white paper and press release shows a few other details:

1. Microsoft's NAP agent will be the single agent that works for both NAP and NAC in Vista and Longhorn
2. MS is including as a Windows update a patch to the Vista supplicant which will allow it to work with Cisco's proprietary EAP/802.1x, in addition to the industry standard supplicant that Vista will contain for 802.1x
3. Windows OS other than Vista and Longhorn will still need two separate agents for NAP and NAC
4. MS "will license elements of its NAP client technology to third party software developers" to support non-Windows OS.
5. MS NAP API's will serve as the single programmatic interface used for health reporting for both Cisco NAC and MS NAP
6. The Cisco ACS will receive notification of "health" from the MS server and then based upon that, grant access to the device depending on the users access rights.

In a nutshell, it looks like MS is responsible for the client, testing the end points, determining what policy and what tests the endpoint should be tested against and communicating this to the Cisco NAC solution.  The NAC solution is then in charge of assigning the device to the appropriate VLAN and quarantine and network enforcement. 

So here is my question then.  If I already have NAP, what I am I getting by adding Cisco NAC? Well first of all I have to have a Cisco only, NAC enabled nework, secondly I have to have a MS NAP enabled network.  Assuming the two above, is NAC doing anything that NAP by itself working with standard 802.1x can't do?  I don't see it.  I think this type of functionality will work with any 802.1x capable network and NAP.  I am encouraged to see them working together, I would like them both to support the TCG standard as well (MS has said they will support it), however as it now stands, I just don't see a lot that is special about it.  Maybe we will see more in the next year, before this goes live.

The herd mentality (or safety in numbers)

I received a nice note from a reader to the blog over the weekend named Rob.  Rob pointed me to an article in e-Week by Deborah Rothberg last week that had a survey that showed only 37% of IT professionals believe their company was effective at detecting, let alone preventing data breaches.  Another interesting fact was that in terms of what was the most detrimental factor in a data breach, loss of confidential consumer or customer data was second.  First was loss or theft of IP.  This is in spite of privacy laws and such. 

The biggest thing in my mind though was the fact that the biggest reason cited for not taking greater precautions and measures was cost.  With the cost of data breaches being what they are, I find it hard to believe the cost of protecting against data breaches is not cheap compared to the cost of data breaches.  The only way you can justify it, is that the people responsible for approving the budget for these kinds of tools follow a herd mentality with safety in numbers. They must know that the cost of protection is actually pretty cheap compared to the cost of a breach. However, in spite of the fact that we read and hear about data breaches every day, they still feel that they can hide in the crowd and that this will be someone else's problem.  That is until the day it comes home to roost and they have to pay the piper.  Maybe it is a good idea to keep publicizing these data breaches, so that people become more aware that it can happen to them.

NERC gets some teeth

For a long time now the electric utility industry has been trying to draw up a set of cybersecurity standards to have at least some minimum standard that power generators have to adhere to.  The requirements went into effect last month according to this article.  They are called CIP 002-009 for Critical Infrastructure Protection (CIP) specs.  There is supposedly financial penalties for non-compliance and I imagine between NERC and FERC, they have the power to enforce this.  The bad news is the first compliance deadlines are not until 2009.

Under the regulations power companies will have to have basics like anti-virus, patch management, IDS and yearly vulnerability assessments.  When you realize that some of the plants are nuclear power plants, you might think they should have to do more.  But at least this is a start.

Is good enough security, good enough? (Are we the good enough generation?)

Michael Farnum has a good post today (I will spare you all another picture of Michael, but you can see him on his blog) on the realty of UTM.  The point Michael makes and also credits Chris Hoff for originally making the point, is that many people don't do what may be best in security, they do what is "good enough".  Forget UTM, I am sorry to say that in just about all matters dealing with security (and everything else for that matter), with the exception of sometimes a few key verticals, good enough security is good enough. 

This has been a hard lesson we have learned at StillSecure.  My sales team and SE's constantly are talking to customers about why SNMP is an inferior way to achieve port-level access control versus 802.1x..  You know what, most security admins, especially in the .edu space just don't care.  They can have something without a lot of work and it is good enough.  I have thought for a long time, what is the use of just checking for anti-virus and patch levels, when you can check for so much more.  The answer, its good enough.  On IPS, why would you just turn on a few rules and not do a better job of checking traffic?  Easy, its good enough.  Here is another one, on vulnerability management, with so many vulnerabilities out there, why scan occasionally?   Good enough, you got it. 

My perhaps jaded experience is that our IT culture views security as something that has to be done good enough.  Did I do enough to satisfy the regulatory issue (Farnum makes the point that this can actually hurt security), can I check off the check box by just doing it good enough.  Then we wonder why Choice Point and VA style data losses can happen.  We ohh and ahh about the amount of losses reported due to security breaches every year.  But we wont get off our butts (collectively) to do more than good enough.  We will bitch and moan about big brother government making us do something about security, but face it without them, would we even do the minimal things they ask of us.  I know it is about managing risk, but all to often good enough, is good enough when it comes to security.

PS - the more I think about it, I am not sure this is limited to just information security.  I think "good enough" pretty much sums up a classic view of America lately.  Why don't we have a better alternative energy policy?  Why don't we do a better job about poverty, education, health?  Maybe what we have is good enough.  Is good enough the real mantra of America today?  If the WW II generation was the greatest generation, are we the good enough generation?