The Red Herring of Cybersecurity Legislation

On Capitol Hill, Congress is loosely debating the merits of nearly three dozen different pieces of cybersecurity legislation. These bills would impose new requirements for disclosing security breaches, guaranteeing the privacy of individual citizens and giving the government new powers in defending critical infrastructure and prosecuting a cyberwar.

To date, the federal government has about a dozen or more cybersecurity laws on the books and scores more that address cybercrime and hacking. All but six states have laws that require companies to disclose when they’ve been breached and user data has been compromised. Several states are considering new laws that would either reinforce or be redundant with existing state and federal law. And industry groups are looking to strengthen or impose their own security requirements in ways similar to the credit card industry’s PCI-DSS standard.

To say that the cybersecurity statutory landscape is a mess would be an understatement. Some people argue that this legal maze needs plowing under in favor of a cleaner, more consistent and generally uniform legislative standard that the public and private sector can follow. Perhaps, but that’s a bit of a pipedream. The best that anyone can hope for is a superseding law that either makes obsolete or fills in the gaps of the existing state and federal laws.

I will tell you that all this talk about cybersecurity laws is a red herring. It’s a fruitless pursuit that results in very little improvement of the security posture of any company, government agency, the general economy or the critical infrastructure.

Before I get into my argument, let me first define the two basic types of cybersecurity legislation. First, there’s privacy and identity protection; this is basically any law that requires the safeguarding of personal identification records such as financial and health from unauthorized disclosure. Second, there’s infrastructure protection, which impose standards for keeping malware and hackers out of critical systems such as defense, financial services, power grid, water supply and transportation networks.

It’s important to understand the difference between the two, since privacy laws are essentially designed to punish the victims, meaning that they impose requirements for investment and disclosure on companies that have suffered a security breach. The infrastructure protection laws require companies to spend money on security systems whether they are threatened or have suffered a breach. Many people will argue that laws such as these are necessary since businesses and government agencies may not make the necessary security investments if they’re not required by law. Perhaps, but that’s not my objection to security legislation.

There’s nothing wrong with security legislation until it imposes more requirements than will be either realized in a return on investment or counter to any reasonable improvement in security posture. Consider this: For much of the last decade, federal agencies have been required by the Federal Information Security Management Act to steadily improve their IT security posture. Despite a Congressional mandate, government agencies have scored failing marks for their security posture and have equally failed to improve their security despite billions of dollars in security investments.

Security legislation is a red herring because it imposes security spending and management requirements regardless of the actual or perceived risk. Not every enterprise or government agency is exposed to the same level of risk or the same types of technology vulnerabilities. Nevertheless, security legislation would impose near uniform requirements for how they should address the general threats.

Many chief information security officers and managers in the private sector say they would not get the budget allocations they need if it weren’t for laws such as Sarbanes-Oxley, the Massachusetts Data Protection Law or the Payment Card Industry Data Security Standard (PCI-DSS). Perhaps that’s true. But let’s be honest: do these laws keep organizations from doing bad things or really keep the bad guys from stealing? TJX, for instance, was governed by PCI-DSS, but its management willfully chose against upgrading its wireless encryption. As a result, the company suffered the single worst private sector data security breach in 2006. Hannaford, a New York-based supermarket chain, was compliant with PCI-DSS standards, and yet it suffered a massive security breach in 2008. These two incidents prove one thing: security breaches are inevitable. And that’s the problem with cybersecurity legislation: The imposition of a security requirement will create a point in time of compliance; and the dynamic nature of IT means that compliance is fleeting.

The CompTIA IT Security Special Interest Group is working to define the various security legislative initiatives and lobby for a federal standard that would make sense of the security regulatory requirements. Again, it’s not a bad idea, but one that is static. I argue that what’s needed is for solution providers to create practices and processes that help their customers develop and sustain security lifecycle management. This is far different from the static requirements of security legislation, since lifecycle management would require the continual reassessment of operating environments, threats, incidences and responses to continually improve security posture. Through such processes, solution providers will find richer opportunities for building and supporting lifecycle management systems that are dynamic and responsive to changing conditions.

How does a solution provider build such practices around security lifecycle management? Ah, that’s the stuff of secret sauce. Well, sort of. Plenty of best practices exist for establishing solid security practices and assessment measures. Those best practices can provide the foundation for building systems and services that result in a lifecycle management system. And, here’s the best part, organizations that practice well-oiled security lifecycle management are probably more resilient to attack and incidents and compliant with any number of security laws.

Again, I’m not opposed to cybersecurity legislation, and believe the channel needs to be involved with the legislative process to protect the industry and users from technology-ignorant lawmakers’ overzealous response to the latest headlines. And I believe that cybersecurity legislation is necessary to compel some organizations to take action and make investments that they would otherwise ignore. However, I do not believe the security legislation alone will improve resilience to attacks. It’s incumbent upon the channel community of security professionals to bring common sense and best practices to the user community for their ultimate security benefit.

This is my two cents. Where do you stand?