25. January 2011 · Comments Off on SaaS Compliance solution from Navajo Systems · Categories: blog · Tags: , , , , , , ,

While there are many compelling benefits to Software-as-a-Service solutions like Salesforce, SuccessFactors, and Gmail, there are also privacy, security and compliance inhibitors which arise from the fact that SaaS application data is stored in clear text.

For many organizations, encrypting the communication between users and SaaS applications is simply not enough. Some large organizations have resorted to installing SaaS applications in their datacenters to meet privacy, security and compliance requirements. This way they get some of the SaaS application benefits but still must endure the real estate, power, hardware, communications, and associated administrative expenses themselves.

Some organizations have restricted the use of SaaS applications to those where clear-text data does not run afoul of regulatory issues.

The ideal solution would  be to encrypt data on the way into and back out of the SaaS applications. SaaS backup solutions, for example, have been doing this for years. The file metadata stays in clear text but the files themselves are encrypted. However, for data-oriented applications like Salesforce, SuccessFactors, and Gmail, standard data encryption does not work because once the data is encrypted, you cannot search or sort on it.

Finally, a solution has come to market – Navajo Systems – which allows you to meet regulatory compliance requirements for storing, for example, Personally Identifiable Information (PII) and Protected Health Information (PHI) in SaaS applications. Navajo’s breakthrough is an encryption algorithm which allows searching and sorting. In other words, data is encrypted before it leaves your organization and is stored in the SaaS application in that same encrypted form, yet can be searched and sorted in a way that is both transparent to the SaaS application and to the users!!

Only you have the encryption keys. No one at the SaaS vendor can read your data. Full disclosure, Cymbel is partnering with Navajo. We would be glad to show you exactly how this works.

Here are links to more information about SaaS Compliance and Navajo Systems.

28. December 2009 · Comments Off on Verizon Business 2009 DBIR Supplemental Report provides empirical guidance for unifying security and compliance priorities · Categories: Breaches, Compliance, Risk Management, Security Management, Theory vs. Practice · Tags: , , ,

The Verizon Business security forensics group's recently released 2009 Data Breach Investigations Supplemental Report provides common ground between those in the enterprise who are compliance oriented and those who are security oriented. While in theory, there should be no difference between these groups, in practice there is.   

Table 8 on page 28 evaluates the breach data set from the perspective of data types breached. Number one by far is Payment Card Data at 84%. Second is Personal Information at 31%. (Obviously each case in their data set can be categorized in multiple data breach categories.) These are exactly the types of breaches regulatory compliance standards like PCI and breach disclosure laws like Mass 201 CMR 17 are focused on.

Therefore there is high value in using the report's "threat action types" analysis to prioritize risk reduction as well as compliance programs, processes, and technologies.

While the original 2009 DBIR did provide similar information in Figure 29 on page 33, it's the Supplemental report which provides the threat action type analysis that can drive a common set of risk reduction and compliance priorities.

Controversy around the PCI DSS compliance program increased recently when Robert Carr, the CEO of Heartland Payment Systems, in an article in CSO Online, attacked his QSAs saying, "The audits done by our QSAs (Qualified Security Assessors) were of no value whatsoever. To the extent that they were telling us we were secure beforehand, that we were PCI compliant, was a major problem."

Mike Rothman, Senior VP of eIQNetworks responded to Mr. Carr's comments not so much to defend PCI but to place PCI in perspective, i.e. compliance does not equal security. I discussed this myself in my post about the 8 Dirty Secrets of IT Security, specifically in my comments on Dirty Secret #6 – Compliance Threatens Security

Eric Ogren, a security industry analyst, continued the attack on PCI in his article in SearchSecurity last week where he said, "The federal indictment this week of three men for their roles in the
largest data security breach in U.S. history also serves as an
indictment of sorts against the fraud conducted by PCI – placing the
burden of security costs onto retailers and card processors when what
is really needed is the payment card industry investing in a secure
business process."

The federal indictment to which Eric Ogren referred was that of Albert Gonzalez and others for the breaches at Heartland Payment Services, 7-Eleven, Hannaford, and two national retailers referred to as Company A and Company B. Actually this is the second federal indictment of Albert Gonzalez that I am aware of. The first, filed in Massachusetts in August 2008, was for the breaches at BJ's Wholesale Club, DSW, OfficeMax, Boston Market, Barnes & Noble, Sport Authority, and TJX.

Bob Russo, the general manager of the PCI Security Standards Council disagreed with Eric Ogren's characterizations of PCI, saying that retailers and credit card processors must take responsibility for protecting cardholder information.

Rich Mogull, CEO and Analyst at Securosis, responded to Bob Russo's article with recommendations to improve the PCI compliance program which he characterized as an "overall positive development for the state of security." He went on to say, "In other words, as much as PCI is painful, flawed, and ineffective, it
has also done more to improve security than any other regulation or
industry initiative in the past 10 years. Yes, it's sometimes a
distraction; and the checklist mentality reduces security in some environments, but overall I see it as a net positive."

Rich Mogull seems to agree with Eric Ogren that the credit card companies have the responsibility and the power to improve the technical foundations of credit card transactions. In addition, he calls the PCI Council to task for such issues as:

  • incomplete and/or weak compliance requirements
  • QSA shopping
  • the conflict of interest they created by allowing QSA's to perform audits and then sell security services based on the findings of the audits.

Clearly organizations have no choice but to comply with mandatory regulations. But the compliance process must be part of an overall risk management process. In other words, the compliance process is not equal to the risk management process but a component of it.

Finally, and most importantly, the enterprise risk management process must be more agile and responsive to new security threats than a bureaucratic regulatory body can be. For example, it may be some time before the PCI standards are updated to specify that firewalls must be able to work at the application level so all the the Web 2.0 applications traversing the enterprise network can be controlled. This is an important issue today as this has been a major vector for compromising systems that are then used for funds transfer fraud.

The Department of Health and Human Services this week published the regulations for the "breach notification" provision of the Health Information Technology for Economic and Clinical Health (HITECH) Act, of the American Recovery and Reinvestment Act of 2009 (ARRA). In effect, this is an extension of HIPAA and further strengthens HIPAA's Privacy Rule and Security Rule.

The new breach notification regulations are in a 121 page document. HHS also issued a press release that summarizes the new regulations.

This type of breach notification regulation started in California with SB 1386 which went into effect on July 1, 2003. Since then about 40 other states passed a similar law.

In 2008, California went on to pass a specific health care information protection law, SB 541, which requires notification of breaches and financial penalties up to $250,000 per incident. Here is a Los Angeles law firm's presentation on it.  Since SB 541 went into effect on January 1, 2009, there have been over 800 incidents reported.

20. August 2009 · Comments Off on 8 Dirty Secrets of the IT Security Industry – Provocative headline; content not so much · Categories: Application Security, Compliance, Innovation, Risk Management, Security Management · Tags: , , , , ,

CSO Online Magazine has an article about IBM ISS Security Strategist Joshua Corman's concerns with the security industry. While I agree with much of what he says, I disagree with his core premise, expressed in Dirty Secret 1. Here are my comments on each of Josh's eight dirty secrets.

"Dirty Secret 1: Vendors don't need to be ahead of the threat, just the buyer – This is the problem that leads to the seven "dirty secrets" that
follow. In essence, Corman said, the goal of the security market is to
make money, not to ensure the customer's security.
"

I find it surprising that a representative of one the largest and most profitable enterprises in the world attacks other vendors for wanting to make money, as if making money is bad. Is he serious about attacking capitalism? Is security some special market where profits are bad? From my perspective, making money is the result of solving client problems and helping them meet their objectives.

"Dirty Secret 2: AV certification omissions – While AV tools detect replicating malware like worms, they fail to identify such as [sic] non-replicating malware as Trojans."

Aside from the grammar issue, I agree that some vendors are having difficulty keeping up with the constantly evolving threat landscape. However, this creates opportunities for new vendors. Joseph Schumpeter called this "creative destruction."

"Dirty Secret 3: There is no perimeter – Corman said those who truly believe there's still a network "Perimeter" may as well believe in Santa Claus."

There has never been a perimeter in the sense that if you just protect the edge of your network, you are safe. I do agree that it can be difficult to know where that edge is. However, there is still an important role to be played by a perimeter firewall that understands applications, users, and content. Beyond that, good security has always been about "defense-in-depth."

"Dirty Secret 4: Risk management threatens vendorsRisk
management really helps an organization understand its business and its
highest level of risk, Corman said. But a company's priorities don't
always map to what the vendors are selling."

Again, this allusion to disreputable vendors. At any point in time, there surely are disreputable vendors. But they don't last long. Of course any IT Security control being deployed should be in the context of how risk is being reduced.

"Dirty Secret 5: There is more to risk than weak software – Corman
said the lion's share of the security market is focused on software
vulnerabilities. But software represents only one of the three ways to
be compromised, the other two being weak configurations and people."

No argument here, but not really new. The issues around security awareness training, for example, are much deeper than lack of money being spent on it. Regarding configuration management, has the issue been lack of attention or lack of good products to deal with the issues? It's a hard problem.

"Dirty Secret 6: Compliance threatens security – Compliance with such laws and industry standards as Sarbanes-Oxley and PCI DSS
drives companies to spend far more on security than they might
otherwise. Security vendors have obviously seized upon this fact,
offering products that do everything from offer PCI compliance out of
the box to ultimate cure-alls for healthcare entities coping with the
demands of HIPAA. Of course, this too leads to companies buying security tools that fail to properly address the particular risks they face."

I surely agree that compliance threatens security and there surely are cases where vendors have been successful by focusing on compliance rather than on reducing risk. When an organization "only" focuses on compliance requirements it falls short of what it can and should be doing to protect its assets. In fact, compliance represents a floor or bare minimum level of security.

Put another way, if you only focus on compliance, you will surely not be maximizing the value of your security investment. At the very least, there is no way that regulatory bureaucracies can keep up with the changing threat landscape. 

"Dirty Secret 7: Vendor blind spots allowed for Storm – The Storm botnet, as an archetype, is being copied and improved. The Storm era of botnets is alive and well, nearly two years from when it first appeared, Corman said."

As I said in my comment on Dirty Secret 2, some vendors may not be responding to the changing threat landscape, but there are others who are. If you feel your vendors are not responding, look for new ones. There is a lot of innovation in the IT Security industry.

"Dirty Secret 8: Security has grown well past "do it yourself" – Technology
without strategy is chaos, Corman said. The sheer volume of security
products and the rate of change has super-saturated most organizations
and exceeded their ability to keep up."

Any actions or tactics that are not part of a strategy is obviously chaos. First Corman says that vendors are not keeping up and now he is saying that enterprises cannot keep up (without his help). With all due respect, let's remember that Corman is part of IBM's consulting organization. On the other hand, there is no harm in repeating that technology by itself is not the answer. It's people, process, and technology, as it has always been.