1. “A Gartnergate?” What happened after Mr Pescatore uttered his now famous 12 words: “The best security program is at the business with the happiest customers.” This (complete with Gunnar’s famous “firewalls+SSL” chart), this – will add more as this snowballs.
2. Do you have an “ignorable” security policy? If yours is BOTH “ignorable” and “unfair”, then fuggedaboutit. Cisco survey kinda proves it. A few fun comments are here (“If people can't get their jobs done without having to find a way to circumvent policy then the policy is wrong.”)
3. Risk and clouds – here, here, here and here in poetic form (!). Fun reading, but you know what? For many, many organization, what they have today is LESS secure than any future cloud computing advance…
4. Richard Bejtlich drop-kicks SIEM too, then kicks it in the balls. Then kicks the dead horse (1,2,3)
5. Excellent reminder about why people don’t care about security with a fabled quote from MJR (yes, it is my fave too!) Overall, Rich “reassures” with: “Don’t worry. When things get bad enough, we’ll get the call. If you’ve kept your documentation and communications up, you won’t get shafted with the proverbial short end.”
6. A few essays on risk, from ANSI, from Schneier and from BlogInfoSec (part 1 and part 2, especially read part 2)
7. So, what do CTOs really do every day? Interesting summary here and here.
8. Fun exploration of security x privacy x compliance.
9. Burton Group opines on which security technologies will fare better/worse during "The crisis”
10. A really fun interview with our CEO Philippe Courtot here.
11. More on IT vs IT security, this time from Richard.
12. Do you want people like that doing “security”? A normal call center employee recognizes fraud, but their so-called “outsource security dept” authorizes the scam. Niiice.
13. Finally, “Robots Hunt 'Non-Cooperative Humans' in Army Plan” No comment :-)

Enjoy!

1. Great paper that complements the whole "SIEM is dead?" saga - "Most enterprises are looking for a product that will solve all of their problems in some sort of off-the-shelf miracle, and when they find out that the currently available tools can't do it, they either postpone their deployment or put them on the back burner. "
2. "The Mess: looking for someone to blame?" is an awesome piece on Internet security and its architecture - and so is Gunnar's follow-up ("If a tree falls in someone else's silo...")
3. Mike call to "Rise up against Mediocrity."  - "Dilbert makes the risk of the lowest common denominator approach abundantly clear."; in other words, you say 'best practices', I say 'mediocrity!' Mike also remind us, in vain, to do "Security FIRST!" (and compliance second)
4. A great piece from Burton: "On Response" - I think the world needs another 10-20 million reminders that PREVENTION FAILS. This is definitely a good one for those still in the "we'll just block the threat world" - "we will not win a continuing war of escalation" and "using response can be more cost effective than installing the latest and greatest preventative tool"
5. More on metrics, including the highly-awaited ISO27004.
6. Pretty dumb paper by a person confused by why PCI DSS exists (the guy needs to read this). PCI doesn't "fall short," it helps people who will otherwise not do anything and their systems will "power" those botnets of the future...
7. While we are on this subject: a really good coverage of PCI 1.2. changes, released Oct 1st. More PCI fun here. And more here ("PCI Compliance - dispelling some common myths"). And, more PCI myths. And more good ideas on PCI from Mike R. Sorry, can't stop thinking about PCI :-)  - also this is good.
8. Adrian on behavioral monitoring; mostly in DAM, but also elsewhere in security.
9. "Premature Chasm-Crossing"  - a must-read for all security vendors and especially their marketing (and  their easily-excitable PR teams...) - "Shouldn't vendors be spending more time fighting the problems that security managers are facing today, right this minute?" (Mike R also comments on that). A related - and  just as interesting point is made here: "Security is not a solution"
10. More on compliance and security checklists, good and bad: "I think this is a dangerous trend unless the "checklist" is all inclusive." (how can a checklist include ALL? :-))
11. "SANS Top 7 New IR/Forensic Trends In 2008"
12. Read "The three approaches to computer security!"  Why? Come on, it is from Joanna! :-)
13. A fun discussion about a hot new technology: network IDS. Is IDS absolutely indispensable to ALL companies? No. Can it be incredibly useful? You bet. End of discussion.
14. On an unrelated note, are lasers the future of warfare? Some say no.
15. Finally, some security humor from Gartner (!): "Get Rich Quick With Network Security"

Enjoy!

Previous security reading.

Blogger: Trent Henry

Burton Group’s Catalyst Europe conference is just around the corner. With financial services industry failures at the top of everyone’s mind, now’s a great time to revisit how risk management shortcomings have tremendous impact on organizations of every kind. In a reprise of his insightful Catalyst North America talk, Nick Leeson will once again detail how inadequate controls (and foolish actions on his part) brought about the fall of Barings Bank. In addition, security conversations at Catalyst will include:

- How large enterprises are grappling with governance, risk, and compliance (and why “GRC” is actually a four-letter word)
- What large, distributed organizations are doing to create effective “security embassies”
- The role of metrics in managing protection and communicating with Management
- How information-centric security will unfold over the next five years

Blogger: Randall Gamby

Two weeks ago the PCI Security Standards Council released the preliminary details of the PCI Data Security Standard (DSS) V1.2 that’s due out in October.  While many Analysts and Reporters have already written on the topic (I’ll be releasing an extensive update on Burton Group’s PCI coverage around the October release date), they really haven’t commented on what’s still not been addressed by the standard for enterprises still working on attaining compliance.

While I applaud the PCI Security Standards Council in further clarifying and adjusting the standard, a lot of work still needs to be done.  I receive about one or two PCI questions a week from our clients and they seem to revolve around a couple of topics I’ve yet to see addressed:

• Guidelines for selecting a Qualified Security Assessor (QSA) – while there are a large number of QSA organizations listed on the PCI Security Standards Council web site; they can’t really recommend a particular QSA for an individual organization.  This leads a lot of organizations to struggle with determining what criteria they should use in selecting a QSA for their certification.
• The role of the QSA – organizations are also still trying to understand the role of a QSA.  Should they get a QSA involved in the gap and remediation process in advance of certification?  If so, should it be the same QSA that will do their certification (knowing there’s a risk that the QSA will be pre-disposed to only care about certain vulnerabilities)?
• Industry-specific best practices – while each organization may have different infrastructures, in general, most industries try to be consistent with the major functions they perform.  So are credit card transactions handled differently between say, a major retailer with 10,000 POS systems and an insurance company that has hundreds of independent agents receiving remittances? Probably, so what are best practices around these industry-specific configurations?
• Virtualized environments – while the PCI Security Standards Council recognizes that some organizations have moved to virtual services for consolidation and management, the DSS really doesn’t provide guidelines for QSAs to evaluate and certify these environments.
• Monitoring and audit – while the PCI DSS recommends minimum timeframes for scanning, doing pen tests, etc. what are the real levels of monitoring and audit needed for ensuring security?  With the Hannaford and Okemo breaches that occurred (both where PCI compliant), neither discovered the problem until months after the breaches had happened.  So identifying what should be scanned and tested and if some of this should be on a continuous basis still requires refinement.
• PCI as part of an overall security model – what are the best practices around merging PCI security requirements into an enterprise’s overall security model?  Should it be maintained separately? Should some components be integrated with similar security mechanisms?  Should PCI be at the top of the security model and other configurations be based upon its requirements?  There are really no answers coming forth on this topic and the other question is where will they come from? Surely enterprises won’t expect the PCI Security Standards Council to tell them how to run their security services.

I will be providing Burton Group’s perspective on most of these questions in my upcoming report, but rather than relying on third parties to resolve these, I’d hope that the PCI Security Standards Council will be able to continue to provide answers to the questions they can in future updates, and releases, of the PCI DSS.

Blogger: Randall Gamby

Two weeks ago the PCI Security Standards Council released the preliminary details of the PCI Data Security Standard (DSS) V1.2 that???s due out in October.  While many Analysts and Reporters have already written on the topic (I???ll be releasing an extensive update on Burton Group???s PCI coverage around the October release date), they really haven???t commented on what???s still not been addressed by the standard for enterprises still working on attaining compliance.

While I applaud the PCI Security Standards Council in further clarifying and adjusting the standard, a lot of work still needs to be done.  I receive about one or two PCI questions a week from our clients and they seem to revolve around a couple of topics I???ve yet to see addressed:

• Guidelines for selecting a Qualified Security Assessor (QSA) ??? while there are a large number of QSA organizations listed on the PCI Security Standards Council web site; they can???t really recommend a particular QSA for an individual organization.  This leads a lot of organizations to struggle with determining what criteria they should use in selecting a QSA for their certification.
• The role of the QSA ??? organizations are also still trying to understand the role of a QSA.  Should they get a QSA involved in the gap and remediation process in advance of certification?  If so, should it be the same QSA that will do their certification (knowing there???s a risk that the QSA will be pre-disposed to only care about certain vulnerabilities)?
• Industry-specific best practices ??? while each organization may have different infrastructures, in general, most industries try to be consistent with the major functions they perform.  So are credit card transactions handled differently between say, a major retailer with 10,000 POS systems and an insurance company that has hundreds of independent agents receiving remittances? Probably, so what are best practices around these industry-specific configurations?
• Virtualized environments ??? while the PCI Security Standards Council recognizes that some organizations have moved to virtual services for consolidation and management, the DSS really doesn???t provide guidelines for QSAs to evaluate and certify these environments.
• Monitoring and audit ??? while the PCI DSS recommends minimum timeframes for scanning, doing pen tests, etc. what are the real levels of monitoring and audit needed for ensuring security?  With the Hannaford and Okemo breaches that occurred (both where PCI compliant), neither discovered the problem until months after the breaches had happened.  So identifying what should be scanned and tested and if some of this should be on a continuous basis still requires refinement.
• PCI as part of an overall security model ??? what are the best practices around merging PCI security requirements into an enterprise???s overall security model?  Should it be maintained separately? Should some components be integrated with similar security mechanisms?  Should PCI be at the top of the security model and other configurations be based upon its requirements?  There are really no answers coming forth on this topic and the other question is where will they come from? Surely enterprises won???t expect the PCI Security Standards Council to tell them how to run their security services.

I will be providing Burton Group???s perspective on most of these questions in my upcoming report, but rather than relying on third parties to resolve these, I???d hope that the PCI Security Standards Council will be able to continue to provide answers to the questions they can in future updates, and releases, of the PCI DSS.

But in the end, it seems like Tucci didn’t have faith that Greene had the chops to run the successfully growing company anymore. So she could build it to the stature it has now but just as MS comes out of the gates, all of a sudden she’s no good? Boy, I can’t wait for Greene’s book on this. CEOs, take heed – don’t be too successful or the board will fire you. (Or alternatively don’t let the guy who doesn’t like you stack the board!)

So where does VMware go from here? Rachel Chalmers, Research Director for Infrastructure Management at The 451 Group, places a bet on cloud computing – saying that VMware plans to offer a new suite of cloud computing at the next VMworld Conference. And here’s a nice piece on the Burton Group’s Data Center Strategies Blog that suggests another multi-pronged winning strategy.

Oh no. The virtualization management space, if it didn’t before, is beginning to remind me of the Internet boom time when everyone and their brother (literally, ask me about it sometime) got into the act. Introducing, DynamicOps and their product, Virtual Resource Manager (VRM). The two-week old company and product are spinouts from Credit Suisse, where the original solution was home-grown and in production for more than 2 years, managing thousands of virtual machines. I’m really interested in taking a closer look at it and seeing just what VRM does differently to meet the unique requirements of virtualization management at such a scale.

Forrester Research released a research report on “the Five Essential Metrics for Managing IT.” The study relates the “Operational Health” metric to the measuring of IT failures. Dave will be happy to note that the report uses one of his favorite phrases – talking about the “dial-tone reliability of IT services”.

ShareThis

Blogger: Randall Gamby

As briefly mentioned in a Burton Group IdPS blog and a ZDNet Australia published article on July 3, 2008, HR data from Google was stolen from one of their previous HR outsource partners.  It seems that the partner, Colt Express Outsource Partners, had equipment stolen that contained HR data from some of its clients, including Google.  The data was unencrypted and stored on systems that were apparently portable.

So what does this mean for all of us? 

First, it shows that even large SaaS companies like Google can be bitten by a lack of security at their partners, just like many of us can.  Burton Group has been warning clients for a long time about the dangers of sending confidential information to outsource partners without proper security and audit processes in place. Of course this should also be backed by strong contractual language. 

Second, be prepared to pay.  Even if Google had breach mitigation terms in their contract, Colt Express announced that it was in financial difficulty. So Google has had to pay for financial reporting and other compensation to its own employees, even though Google did nothing wrong. 

Third, a Google representative stated "We take the security of our employees very seriously and require outside vendors to meet appropriate security standards. We review and update these standards on an on-going basis.”  Does this mean that Google doesn’t require encryption of its confidential information since encryption of the data was not deployed at Colt Express?  When working with third parties, whether it’s financial data or confidential personal data, this information needs to be protected from unauthorized access. One of the simplest ways is encrypting the data while at rest, regardless of where it’s located. 

Final, the Colt Express breach brings to mind a question Burton Group is always asking: “What is your exit strategy if the contract is terminated with your outsourcing partner?”  A lot of effort is expended in creating an outsourcing agreement around use and protection of data, but what happens when the contract is ended?  Do you obtain and retain the information the outsource partner maintained?  Do you have the outsource partner destroy the information and any archives of it (and verify this was done)?  Do you create a custodial contract with the outsourcing partner for them to maintain the information and archives on your behalf (ensuring the data is properly protected)?  As was found in this incident, after their contract with Google was terminated the outsourcing partner apparently retained the employee data unencrypted on their servers. This was the fatal mistake that allowed the breach to occur.

So as you work with your outsourcing and SaaS vendors, you should not only consider how day-to-day operations should be secured to maintain the confidentiality of your data. You should also think about how that data is being maintained over time, and what are your procedures should the unthinkable happen if your partner allows your data to be compromised.

Blogger: Randall Gamby

As briefly mentioned in a Burton Group IdPS blog and a ZDNet Australia published article on July 3, 2008, HR data from Google was stolen from one of their previous HR outsource partners.  It seems that the partner, Colt Express Outsource Partners, had equipment stolen that contained HR data from some of its clients, including Google.  The data was unencrypted and stored on systems that were apparently portable.

So what does this mean for all of us? 

First, it shows that even large SaaS companies like Google can be bitten by a lack of security at their partners, just like many of us can.  Burton Group has been warning clients for a long time about the dangers of sending confidential information to outsource partners without proper security and audit processes in place. Of course this should also be backed by strong contractual language. 

Second, be prepared to pay.  Even if Google had breach mitigation terms in their contract, Colt Express announced that it was in financial difficulty. So Google has had to pay for financial reporting and other compensation to its own employees, even though Google did nothing wrong. 

Third, a Google representative stated "We take the security of our employees very seriously and require outside vendors to meet appropriate security standards. We review and update these standards on an on-going basis.???  Does this mean that Google doesn???t require encryption of its confidential information since encryption of the data was not deployed at Colt Express?  When working with third parties, whether it???s financial data or confidential personal data, this information needs to be protected from unauthorized access. One of the simplest ways is encrypting the data while at rest, regardless of where it???s located. 

Final, the Colt Express breach brings to mind a question Burton Group is always asking: ???What is your exit strategy if the contract is terminated with your outsourcing partner????  A lot of effort is expended in creating an outsourcing agreement around use and protection of data, but what happens when the contract is ended?  Do you obtain and retain the information the outsource partner maintained?  Do you have the outsource partner destroy the information and any archives of it (and verify this was done)?  Do you create a custodial contract with the outsourcing partner for them to maintain the information and archives on your behalf (ensuring the data is properly protected)?  As was found in this incident, after their contract with Google was terminated the outsourcing partner apparently retained the employee data unencrypted on their servers. This was the fatal mistake that allowed the breach to occur.

So as you work with your outsourcing and SaaS vendors, you should not only consider how day-to-day operations should be secured to maintain the confidentiality of your data. You should also think about how that data is being maintained over time, and what are your procedures should the unthinkable happen if your partner allows your data to be compromised.