Massachusetts Backtracking on Data Security Legislation

If you haven't heard of the Massachusetts data security law, you probably don't deal with too many security vendors. My inbox is cluttered with invitations to vendor-sponsored webinars warning of the dire consequences of this law. This "game changing" regulation requires companies to "fundamentally re-assess how you secure your assets"

Of course this isn't true. There was no need to panic before. And now there's really no need to panic, because the Massachussetts legislature may be watering the law down much further. A proposed state senate bill, SB 173, takes almost all the umphhh out of the original legislation:

- it removes the encryption requirement in favor of technological neutrality

- it defers to (much weaker) federal law when relevant

- it basically give a free pass to smaller companies

I don't know what the status of this bill is, although it seems like there is a general consensus that the original law will be watered down one way or the other.

So if you just went out and bought a bunch of fancy encryption gear or log readers or other stuff, you might want to check the return policy. Those might be great things to have, but they are probably totally irrelevant to being in compliance with state and federal laws. There is this bizarre consensus that spending money is more important than re-engineering processes in securing data, when in fact the exact opposite is true.

In case you missed this, let me say it one more time - there is absolutely no need to buy anything as a result of the Massachussetts legislation. Not for big companies. Definitely not for small or medium sized companies. In fact for companies with limited staff buying stuff will probably do more harm than good. You would be much better off locking down the configurations and enabling security features on your existing big vendor stuff (your AD, Exchange Server, Oracle, and the like) than starting to learn how to use new toys.

This isn't supposed to be a rant against security vendors. But there has been a great deal of misinformation (to put it diplomatically) surrounding these regulations. The you-should-buy-productX-because-of-the-new-Massachussetts-data-law argument was absurd to begin with and is even more absurd now that the legislation is on life-support.

The problem in the security space is that there is no real counter voice to the fallacy that you can or should buy compliance. The vendors have an obvious interest in hyping the laws. The analysts stoke the fire. Technical security types can't be bothered to read through a bunch of regulations and so they reluctantly drink the vendor Kool Aid. And everybody else doesn't care because information security legislation - with all due respect to our industry - is among the least important issues being discussed in the United States right now.

Security and the Small Business

There's one part of data security legislation that I find a bit perplexing - the small business exemption. This basically says that any security measures you need to take are only relative to the size and complexity of your business. It is a central part of the Massachussetts legislation as well as most other similar regs I have seen.

Now I get that small businesses require protection from overbearing regulations and legislation. But you can't run a nuclear power plant with a team of 10 people (well, at least I hope there's no out there running a nuclear power plan with just 10 people). Is there a minimum number of people you need to provide adequate data security?

The answer is probably not, as long as you have outsourced both your operations and their security. Really huge famous companies can be shockingly small. In one of the articles about the Craigslist/South Carolina AG feud going on these days there's one detail that really jumped out at me. Craigslist has only 30 employees. To me it's mindblowing that a company with one of the most popular websites in the world and one of the world's leading brands is run by less people than were in my subway car this morning. Yet I haven't heard any one argue that Craigslist is unable to provide sufficient security, or that they should be given a break - or need to be given a break - on their data security.

But not every company is Craigslist. To securely operate a vast complex database with a lot of personal information either requires a lot of money or a minimum number of people. Most small businesses don't have the money and will always be under enormous operational pressure to dedicate staff away from security.

Do Companies Need a CISO?

Is there a future for the security executive? It's hard for me to completely objective about this because I have some skin in the game. No one wants to wake up one day and realize that their job is going the way of the elevator operator.

Chief Information Security Officers (or whatever title they give the executive level security person) started to really take off in the early 2000s. Usually working with a small staff and small budget, the CISO is meant to drive all information security functions within a company and affect change across the enterprise. Especially after 9/11, the creation of a CISO office became de rigeur for companies eager to demonstrate their commitment to security and public safety.

But lately I get the feeling that the role of CISO is in decline. This may seem heretical coming from a security executive, but I believe that the information security risks enterprises face have been exaggerated and misunderstood. The security industry is itself in large part to blame. The industry overhyped threats and demanded too much time and money to mitigate risk. Companies went along by buying expensive security equipment and hiring lots of security staff. But now some companies are starting to wonder -

Do We Really Need A CISO?

A company usually hires a CISO when they believe that two conditions are met - (1) security is a uniquely pressing and urgent need within the organization, and (2) a dedicated office and executive is the best way to adequately address the security issue. 

But does every company actually need a CISO? Are both (1) and (2) true of every company? The sneaky italics in (1) are a hint of my personal take on this - no for (1), and well...no for (2). A minimum level of security is of course always necessary, as are functioning toilets, basic physical security, workplace diversity, and a hundred other issues that do not have their own dedicated teams. But a unique need more important than anything else? Perhaps for a bank or a hospital, but not for a widget maker. 

But wait! What about "the competitive advantage of security" and "the ROI of security"? So at the risk of some bubble bursting, Security does not necessarily have either competitive advantage or ROI to many businesses, even big businesses. And even when it does, a CISO is often unnecessary in an enterprise with low security requirements. Security responsibility can be assigned as just another task to a CIO or other executive.

Which brings me to a phrase I coined a while back (or at least will take the credit for coining) -security narrative. A company's security narrative is the overall story of how it handles security - basically the kind of information you would give the CEO of a potential customer if they asked what your company does for security. A CISO's job is to own the overall security narrative in an organization. 

Whether your company needs a CISO is essentially a question about whether your company needs a full time executive to own and manage its security narrative.  Not every company has a Chief Privacy Officer, a Chief Continuity Officer, a Chief Blogging Officer (yes, that one exists). But if privacy, continuity, or blogging is critical your company, you will have that CPO, CCO or CBO. It works the same with security. So how many companies actually do need a CISO?

500 CISOs at the Fortune 500? Je pense que non...

One of the speakers at RSA last month claimed that all Fortune 500 companies now have a CISO. This seems highly unlikely. But even if it's true, this is probably more a reflection of title inflation than anything else. If we define a CISO as someone who is responsible for managing security but who is not operationally involved, I suspect there are a substantial number of Fortune 500 companies without a CISO. An employee who spends a substantial part of their time configuring firewalls or managing the people who configure them is by definition not a CISO.

Let's take a break from the doom and gloom. Despite everything you've read so far, there are still a large number of companies that need a security narrative and need a CISO to own it. For these companies, the CISO function will become even more prominent in coming years. And these CISOs are as hard as ever to find...

It Ain't Easy Finding a Good CISO...

What makes a good CISO? In descending order of importance - 

1. The ability to affect change.


2. An understanding of how business processes and information interact.


3. An understanding of the technologies used in your organization


4. An understanding of legal and compliance issues.

These skill sets are not in and of themselves so unique - any executive in a technology driven company needs a bit of each one. The tough part is finding someone who has all four skills and is actually interested in information security. 

Oh wait - we're not done whittling down the list of potential candidates. Security to most organizations is and always will be a tax. Being the custodian of this tax function will never be as sexy as selling or building or whatever it is. There's many a qualified potential CISO who ends us getting enticed into more glamorous (and profitable) sides of the business.

Some Other Recent Thoughts On This...

Some people talk about Chief Risk Officer being the next generation of the CISO function. I don't buy this. Everything a company does involves risk, and there's only one person who is ever going to be really responsible for managing all enterprise risk. That's the CEO. 

The Verizon Business Security Blog has an interesting piece about how cloud computing is going to reduce the CISO to a custodian of vendor relationships (or "gracefully lose control"). 

Data Accountability and Trust Act

There's a new bill brewing in the US Congress that could have a major effect on the information security industry. The Data Accountability and Trust Act would pre-empt the patchwork of state data breach notification laws with one federal law. It would also require companies to have a basic security program in place.

I have no idea what the chances are of this bill being passed into law. Following legislation is tough because there are dozens of proposed bills that never make it anywhere near being enacted into law. I guess that's why lobbying is a full time job.

My somewhat uninformed opinion (from a few hundred miles north of DC ) is that this particular piece of legislation probably isn't headed anywhere in a hurry. For one thing, it's been sitting around for a while; apparently the current legislation was already introduced in the previous Congress. It's also being considered with an even less likely candidate for passage - "The Informed P2P User Act" which - regardless of its merits or lack thereof - seems unlikely to pass without some modifications.

So the exact details of the bizarrely named "Data Accountability and Trust Act" are not that important because they will probably change. But this bill is one example of a general trend in regulation that will have profound consequences on the security industry. Let me start with my conclusion - I believe that enterprises are currently spending too much on security products and too little on process. And I believe that the evolving regulatory regime will shine a spotlight on this disparity. Or to put it simply - new regulation will decrease hard dollars spent on security and increase the soft cost in FTEs and organizational capital.

Let's start with the why of security spending. Forget the FUD about hackers and criminals and Russian Business Networks. Compliance is the real driver behind security spending (an assertion recently backed up by the OWASP Security Spending Benchmarks Project). A close second is the desire to actually secure the enterprise; that is, to avoid security breaches and incidence. But this too is really motivated by data breach notification laws on the state level. So directly or indirectly, compliance requirements are the driving force behind security spending.

Both these spending pillars would be undermined by the Data Accountability and Trust Act - the law favors process/policy over technology, and weakens breach notification requirements by preempting stronger state laws.

The Rise and Potential Fall of Breach Notification

A weakened and preemptive federal data breach notification law would be a real game changer for the security industry. There are already federally mandated breach requirements related to HIPAA in the stimulus package, but the effect of a generic breach law would go much farther. By clipping the wings of the much more stringent state laws, they will greatly reduce the "keep us out of the newspaper" motivation for security spending.

The main difference between the proposed weakened federal law and many of the state laws is subtle but critical. As the CDT (Center for Democracy and Technology) pointed out in their testimony to Congress last week, the proposed law leaves it up to an organization to make the determination that there is a low risk of identity theft after a breach. There is obviously a very strong incentive for organizations to come to the conclusion that the risk is indeed low. Because there is little precedent (data breach laws have only been around for a few years) and measuring this kind of risk is inherently subjective, there is a significant risk that real incidents will be swept under the rug. A number of state laws reduce this risk by requiring informing the Attorney General's office of all breaches. But a federal law could preempt this requirement.

Security Narrative vs. Security Product

Why do companies spend so much money and so little time on security? One big reason is a mistaken interpretation of PCI. Some of the PCI requirements clearly require you to buy something or at a minimum enable certain features within deployed systems. Requirement 1 refers to firewalls as a given, and it's hard to maintain your anti-virus software in requirement 5 without, well, buying anti-virus software. Other requirements such as logging can sometimes be done with in house products and sometimes require something to be purchased. But - contrary to popular belief - the vast majority of the hundreds of PCI requirements are actually not about technology.

What about state regulations? The press often erroneously refers to "PCI laws" when talking about recent data security regulations in states like Minnesota and Nevada. The truth is that the only faint similarity between PCI and these laws is a requirement to encrypt data. Other than encryption, I do not know of any state regulation in the United States that mandates a specific information security technology in any meaningful way (and this is a good time to say that I am by no means a lawyer).

The new regulations that are pending in the United States (I haven't sufficiently analyzed this issue internationally) are much more focussed on processes and policy and not technology. They force organizations to have an overall security narrative that defines how they reasonably restrict access to sensitive data to authorized parties. The security narrative is the critical requirement. Security products are one piece of this narrative, but by no means the most important.

What does this mean for vendors? Walking the expo hall at RSA in San Francisco a few weeks back got me thinking that a large number of security vendors are selling products that do not help a business build its security narrative. Most companies today are spending too much money and too few resources and organizational capital in addressing security issues. The current and next generation of regulations are clearly focussed on process, not on technologies. The vendors that will thrive in the future are the ones that support organizational, and not technical, security processes.

And one final negative trend for security budgets is the erosion of the concept that it is an organization, and not law enforcement, that is responsible for preventing cybercrime. Increased prosecution and criminalization of cybercrime will shift the expectations as to what reasonable measures organizations need to take to secure their data. After all, no one expects an armed guard at the entry to every office building.

The European Angle

What about international data security legislation? Although I have heard anecdotally that there are certain technology-specific regs in small international jurisdictions, the vast majority of data security regs are centered around the question of who you can share data with, and not how. And even those few technology specific regs allow sufficient allowance for compensating controls that you are never really forced into buying or deploying a specific technology.

It's worth also debunking another common myth in the security industry, which is that there is any requirement for specific technologies mandated by European directives. In Europe the issue of security regulation is at the center of a very sensitive political debate about ceding sovereignty over security issues to Brussels. While member states of the European Union have ceded very siginificant economic sovereignty to Brussels, there hasn't been any significant movement to give up control over security issues. In the debate between so-called Euroskeptics and EU federalists, cybersecurity has (somewhat oddly) been labelled as a security, not an economic issue. This has stymied European attempts to produce any meaningful cybersecurity legislation at the European level.

When I had the privilege to be one of the founders of the European Network and Information Security Agency (ENISA) in Brussels back in 05, the Agency's remit was very clearly in the area of general cooperation and information sharing. Although the status of the Agency has been slightly expanded over the years, any actual security related regulations will come from the European Commission and not ENISA. There is currently a lot of back and forth about the future role of a European Telecoms Agency that would cover info sec, but these conversations are still in early stages and there is no way there will be any substantial enforceable regulations in this area coming from the EU any time soon. Other EU regulations like the Data Privacy Directive are focussed on the who, and not the how, of sharing sensitive data. So too make a long story short, European regulations also require more people-spend and less technology-spend on information security.

By the way, if you have some serious time to kill, the full testimony before the Congressional Committee on Energy and Commerce can be found here.

Update: The New York Times published an editorial on May 25th that is generally supportive of the Data Accountability and Trust Act but that is critical of the pre-emption of stronger state data protection laws.

Red Flags Rule Delayed Again

The FTC has delayed its "Red Flags Rule" yet again. The Red Flags Rule basically requires companies to keep their eyes open for identify theft. It was supposed to go into effect on May 1st but has now been bumped until August 1st, 2009.

These regulations have caused a stir amongst businesses because they apply to almost any entity that grants credit. For a small business, the maintenance of an identify theft program could prove to be yet another expensive regulatory requirement. But the Reds Flags Rule also emphasizes the fact that a program needs to be "appropriate for your company...size and potential risks of identify theft" (the size exemption is also one of the major stipulations in the similarly delayed Massachusetts data security law). Which is a bit of a strange formulation - why do small businesses get a pass on security? After all, shouldn't a business be required to be have the necessary staff on board to operate securely?

But small or not, in its current formulation the Red Flags Rules affects millions of businesses - basically any company that in some way or another extends credit to consumers. Even with the considerable outreach the FTC has done on this issue, I can't imagine that this rule is on the radar of even a fraction of all these businesses. But those businesses seem to have a while until they really need to pay attention - a panel I attended at the recent RSA conference had a few folks from the FTC who were basically saying that actual enforcement is still a ways off. And undoubtedly it is the largest companies who will be looked at first.

Identity theft (a term which is often misused as a euphemism for companies granting credit too easily) is a much more prevalent problem in the US than in most of continental Europe. In many European countries, there is no way to get any meaningful credit without physically presenting documents like a passport or national identity card. And while those can be forged as well, this significantly raises the criminality bar and the associated penalties. So identity theft is essentially a trade-off; credit is either easily obtainable with a high rate of identity theft, or credit is a hassle to obtain with a low rate of identity theft.

The US has had very easy to obtain credit in recent years, and the ubiquity of e-commerce has only exacerbated this problem. But the pendulum is starting to swing in favor of tightening regulation of credit following last year's financial meltdown. The Red Flags Rule may ultimately prove less effective at reducing identity theft than other regulations that have been implemented to protect consumers. Most notably forty seven states now have security freeze laws. These laws basically allow consumers to set up a password so that any access to their credit report requires them to first "unlock" the report with this password.

Because these laws require people to pro-actively go out and place a freeze, there has not been widespread adoption (I can't find a reference right now but I remember reading a while back that there were only several tens of thousands of credit freezes in all of New York State as of a year ago). Some people have been scared off by stories of delays in lifting freezes and having mortgage applications denied as a result. This inconvenience factor figured very prominently in the business opposition to the original freeze laws - without the ability to quickly approve car financing, a sale might fall through.

The argument against credit freezes reminds me of the Simpsons episode where an excited Homer walks into a gun store to buy a rifle. When he discovers there is a 5 day waiting period he exclaims "But I'm mad now!". Slowing down access to credit is probably the only effective means to actually reduce identity theft, but carries with it other economic costs.

Google Reaches Around the Firewall

Hiding behind the firewall just got a bit tougher as Google announed it's new Security Data Connector that allows Google Apps even more access to your corporate goodies.

A lot of security folks have a what-the-$*%#@ knee-jerk reaction when they hear about stuff like this. But the truth is that when you are using Google Apps you're already in pretty deep with Google. Skirting the firewall isn't going to really change things one way or the other.

Secure Data Connector is another step in what is probably an inevitable move to cloud computing. I hate to use such a nebulous - pun intended - term, so let me put it another way - the old days of companies owning their own firewalled data centers and only working off their own equipment are clearly numbered. Using services like Google Apps has always been first a business decision, then a contractual one, and only lastly a security one.

Cloud computing is really nothing more than outsourcing non-essential IT functions. The reason outsourcing happens is because it is cheaper and more efficient for others to provide a service than to do it in house. Why would running a data center or an operating system be any different?

The main difference, of course, is legal. There are decades of law and precedents that govern what happens when a company has a fire in the building they lease. There is very little law or precedent to govern what happens when a company's Google Apps application is hacked. And because you have very little ability to audit (much less enforce) security measures on a third party vendor, the legalese becomes all the more important.

Moving to the cloud (a.k.a. owning and managing less of your non-workstation infrastructure) also requires a serious change in a company's entire security narrative. Most organizations still have a network-centric way of thinking about security. This is reflected not only in their security spending priorities but also in their strategic approach to security - for example, many companies have relatively open internal systems that rely on the inability of an intruder to get onto certain parts of the network. The prevalence of network-centric vs. host-centric or data-centric security is clearly visible in the prioritization of security requirements that PCI recently published.

Part of this network-centric approach is justified because it reflects the real world legal importance of owning and defending your data. There is also a self-enforcing cycle at play here - as long as network-centric security remains the norm, it is by definition the best practice/commonly used mechansim that is referenced in so many contracts and regulations. You may have some explaining to do to the CEO if your novel Web 2.0/cloud computing/ (insert more buzzwords here) security model was hacked. If a defense-in-depth network with an expensive IDS and lots of pricey Cisco gear gets hacked, well stuff happens. To paraphrase an overused expression, no one ever got fired for installing too many network security products.

Scareware and the Digital Divide

Today Microsoft's Security Intelligence Report came out with the news that "rogue security software" is on the rise. This will come as absolutely no surprise for those of us who have spent a Sunday afternoon trying to rid their friend/grandmother/brother-in-law/neighbor/cousin's PC of the latest AntiSpyware1-ish rogue security software.

For those of you that haven't had the pleasure, these programs infect a PC either by stealth or by inducing a user to click on a pop-up ("You're computer is not running at optimal speed. Click here to fix this issue"). Once installed, scareware basically hold your computer hostage with gazillions of warnings and pop-ups until you buy their "security" product. Depending on your definitions, scareware can be seen as a special case of phishing.

These rogue anti-virus programs have an enormous indirect cost to society by cementing the digital divide. Users who were already wary of computers are tempted to throw in the towel when confronted with persistent security warnings that they neither understand nor can do anything about. Scareware is only a nuisance to advanced users but is a real show stopper for the least technical and disenfranchised users.

The Microsoft report underscores this fact. The results imply that keeping your computer and applications updated and exercising some caution with your surfing and downloading are a fairly strong defense against getting rogue security software. Unfortunately, the less tech-savvy a user is, the less likely they are to be able to do either of these things. Advanced users usually have properly configured System Restore options on their computer, which can address most (though not all) of these programs. Less advanced users either do not have these configured or don't know how to use them.

Going after scareware is tough for all the usual reasons that fraud can thrive on the Internet - the ability for perpetrators to cover their tracks, jurisdiction problems, cost of investigation, and so forth. But to prosecute scareware peddlers you also need to prove that the product is actually a fraud. I haven't seen much case law on this topic, but I can imagine that a lot of it falls more under the FTC-deceptive-practice umbrella than total criminality. After all, any one who has tried to remove some of the older versions of Norton anti-virus from their computer knows that they don't go down without a fight. Where is the line between aggressive market positioning and fraud?

All of this does not bode well for the fight against scareware. Unlike traditional spam, scareware is amazingly effective with response rates in the high single digits. And because it mainly victimizes the end user - unlike say click through fraud which eventually costs everyone money - we are unlikely to see any particular industry move to seriously address this issue.

Back in the Middle Ages of the Internet in the early 2000's, I was a member of the eEurope 2005 Advisory Group that advised the European Commission on Internet policy. The roughly 30 members of this group included a motley crew of former government ministers, professors, subject-matter experts and CEOs. Back then physical access and so-called eInclusion were the primary focus of this group as they were seen as the prime barriers to participation. Today physical access has for the most part been commodotized in the western world. The overall effect of the Internet has been overwhelmingly inclusive for previously disadvantaged groups. But the so-called security tax has fallen disproportionately on people who lack basic Internet skills to begin with.

PCI Hearing in Congress

Last week the Subcommittee on Emerging Threats, Cybersecurity, and Science and Technology held a hearing on the effectiveness of PCI.

You know that PCI has hit primetime when Congress is taking a look at it. But PCI's Washington debut didn't go as smoothly as the Council would have liked. As Anton Chavukin points out, PCI was ripped at by both the government and the merchants for opposite reasons - the feds think it's too little, and the merchants say it's too much.

I don't think that PCI is a perfect standard, but it is wrong to assume that every data breach of a PCI-certified entity signifies the complete failure of the standard. PCI has taken positive steps recently, including laying out a "Prioritized Approach" which should help make the standard more digestible for smaller organizations.

On the whole the problem with PCI is not so much that companies declared compliant are suffering breaches, but that companies are being declared PCI compliant too readily. Oh, and no one seems to know who is liable when this happens.

But the congressional hearing didn't really focus on liability and enforcement issues. The main theme from government was that PCI was broken and that the bar needs to be raised. Chairwoman Yvette Clark's prepared statement also singles out eliminating terrorist financing as a major reason - perhaps the most important reason - to eliminate the hacking of companies housing credit card data.

This is an interesting because there is a big difference between preventing data breaches in general and preventing data breaches that benefit terrorists. Let's assume for the sake of argument that preventing terrorists from committing credit card fraud is a major priority (although somehow I fail to see why credit card fraud - a crime with many digital footprints - would be their first choice). Doesn't that mean that the standard should focus on preventing the specific types of fraud that terrorists are most likely to commit? (For example, war driving is not really a concern if we are worried about people commiting fraud from foreign countries).

In practice I don't think that it makes sense to mix national security into the PCI discussion. I think the real debate about PCI is whether a having a technology-specific standard reduces the number of data breaches. As I have written in the past, most compliance - whether SOX, HIPAA, GLBA, or others - is so non-technical as to really not require companies to do anything specific. On the other hand while government regulation is good for establishing general principles, it has done a poor job when it starts to mandate specific technological solutions. So the government would probably do a worse job at PCI than the PCI Council does.

Industry tends to be wary of government regulation, and often with good reason. The congressional hearing included the statement that the only way to protect networks is by continuously pen testing them. This may or may not be true, but I am not sure that the government is best positioned to mandate one approach over another. A further indication of the entry of opinions being accepted as fact was the repetition by one of the congressmen of the oft-quoted yet ridiculous figure of $1 trillion dollars in cybercrime losses.

PCI is in very early days, and the one thing that wasn't even mentioned at the hearing (unless I missed something...) was the issue of assessor liability. If a PCI-compliant company is breached, shoudn't the finger first be pointed at the assessor to justify why they certified the company in the first place? Until assessors are somehow on the hook for the quality of their assessments (in the same way that an accountant is), one can't really blame the standard itself for failing to enforce itself.

Buying compliance

I have been thinking a lot about the price of compliance lately. Almost every day I get unsolicited emails from a vendor (frickin' provide-your-email-to-get-IT-content websites) pitching their product with the big label SOX COMPLIANT, HIPAA COMPLIANT in big letters (sorry for shouting, but those were direct quotes).

I still can't figure out how such misleading claims can be so prevalent. Take SOX compliance. SOX says precious little about information security, and only concerns itself with security insofar as it touches on financial controls. In other words - SOX requires you to have that security in place that prevents people from cooking your books. SOX says nothing about firewalls, and yet many firewalls are advertised as SOX compliant. 

Now part of this FUD undoubtedly originates with auditors. From my experience audit firms send their heavyweights for the financial part but tend to send some pretty inexperienced folks to do the IT audit. These recent grads sometimes are political science graduates who realized that all the good jobs are gone, did a quick CISA, and *poof* became auditors.

Here's a quick reality check for all of us in the information security industry - the IT audit is just a sideshow in the financial audit, and a pretty minor sideshow at that. And when it comes to being in IT compliance, the lion's share of that is your user access security. I'll say that again in case you missed it - when IT systems are responsible for the inaccuracy of a company's financial statements, it's because of programming errors, broken reporting processes, or someone having access to a system they weren't supposed to. It's almost never (at least not as far as I know) because someone managed to take advantage of the fact that Apache wasn't patched on the web server. When the auditor comes with a cookie-cutter checklist, you will usually be able to provide compensating controls for technical deficiencies but its much harder to fudge the integrity of your business processes.

The main area where you can fail a financial IT audit is in the area of user access to data and applications. If an organization has been sloppy about granting access to network shares or to critical systems, they are in material breach of some basic audit requirements. But there is no product in the world you can buy that will do this for you. Let me repeat that one more time because it contradicts at least 5 sales pitches you have heard in the last month - you cannot buy a product that will magically make sure everyone in your company only has access to the data they are supposed to have. This is because there is no product that can solve your office politics, and (despite the claims of some DLP vendors) there is no product that can really intelligently discern whether data is sensitive or not.

While we're on this can't-buy-me-compliance riff, let's not forget the buttons for "HIPAA Report", "SOX report" etc that some security products come with these days. There's almost a cartoon-like image to a SOX auditor coming in and asking for a report and the compliance manager saying, well, I'm glad you asked, I have this nifty SOX report button I will press here.

The somewhat heretical truth is that compliance requirements are basically the same across regulations, industry contracts, and even jurisdictions - make sure only the people who need access have it, make sure you know what happened when, and make sure you have a properly managed environment. But almost all of this is about process, not technology - and where there is a technological need, in most cases there are pre-existing modules or plugins that provide this functionality (I say in most cases, because there are some systems - most notably administrative credential management systems - that truly fulfill the spirit of compliance requirements yet have not been built into existing user management products).

The trend to built-in security and compliance has been underway for a long time, as the major vendors have integrated regulation-driven customer requests over the years. It will be hard for niche products to survive over time without being integrated into larger product suites for the simple reason that most organizations have a very strong incentive to limit the number of vendor relationships they have. Every new vendor represents a significant overhead in terms of sheer contact, interaction, contracts, etc, and of course the significant risk and complexity that it adds to the environment. 

So to circle back to buying compliance - the real costs of security related compliance are in the time and organizational capital required to bring about real business process change (the second half of that sentence sounds like buzz word drivel, but sometimes buzz words exist for a reason). While there are certain niche products that can assist with compliance requirements in certain industries, for the most part organizations - especially any midsize company - can get compliance by leveraging functionality in their existing infrastructure.

The Prioritized Approach to PCI

A week or two ago the folks at PCI published "The Prioritized Approach to PCI DSS Compliance".

This was a long time in coming. The original PCI list received a lot of criticism for just being a long laundry list. I don't think there's a single company in the world that could honestly claim to be in total compliance. Companies - especially those new to PCI - don't know where to start with the hundreds of new security requirements that have just landed on their lap.

So it's certainly a good thing that the PCI Council folks were kind enough to prioritize the requirements into 6 categories. (Although in the legal fine print the PCI Council insists that the prioritization is for information purposes only and that all requirements are still mandatory for compliance).

Let me start out by saying that I basically like the concept behind PCI. Too many security regulations are just empty fluff. For all its imperfections, PCI puts its money where its mouth is - detailing specific technical measures companies need to take to achieve security. PCI doesn't always get it right (more on that later in this post) and there clearly needs to be some change in the surrounding audit mechanism. But I still think that the standard as a whole kind of works in improving the overall security of the companies subject to it. This is a classical case of security economics at work; the PCI stakeholders (the credit card companies) have a direct financial interest in preventing actual breaches that lead to loss.

The PCI Standard can get away with requirements no state or federal regulation ever could. Legistlators try to avoid mentioning specific technologies in legislation. This is a good thing for limiting the influence of lobbyists and preserving technology neutrality (any one who has had the misfortunte to deal with electronic signature regulations knows how messy it can get when specific technologies find their way into legislation). But PCI is not a regulation and does not depend on a legislative process to be updated. It can specifically mention certain technological concepts and then update them over time. Although you sometimes mistakenly here in the news about "PCI being adopted as law" in certain states, this is almost always a complete misrepresentation (as in the case of Minnesota, whose PCI-inspired law only enacted a few very generalized versions of some of the PCI requirements).

The Prioritized Approach gets some priorities right and some of them can IMHO use improvement. The document says that data is culled form actual breaches, giving the PCI Council data that most of us don't have to determine what is important and what isn't.

The Prioritized Approach hits the nail on the head with priority one - removal of sensitive data and limit data retention. This information security principle seems so obvious and yet I rarely see it stated in such a clear and succint way. The lowest hanging fruit - the bananas practically falling off the branch - is the deletion of customer data you just don't need any more. It's also the easiest thing to get buy-in from the rest of your organization - it requires few resources and has a very high risk-reduction-to-effort ratio. So absolutely no argument on this no-brainer for priority #1.

The relationship between 2 and 3 is likely to generate the most controversy- it is here that the PCI Council prioritizes network security over applicaiton security. But in today's environment, is it better to have hardened applications sitting on open machines or the other way around? The actual threat from web application vulnerabilities is still not well understood, and there are a number of items on OWASP Top 10 type-lists that do not pose a particularly high risk. But something like failure to validate input (priority 3) is in my opinion responsible for more attacks than some of the networking PCI requirements (eg installing a personal firewall on employee laptops, priority 3).

Currently almost all items in PCI Requirement 6 (Develop and maintain secure systems and applications) are assigned priority 3, and almost all items in PCI Requirement 1 (Install and maintain a firewall configuration) are assigned priority 2. I predict this will probably evolve over time, since there are clearly some app security issues which are more important than network issues.

A couple of final thoughts - the Prioritized Approach puts the appropriately low priority on pyhsical security. One of my recurring pet peeves when dealing with vendor security whitepapers is the overemphasis on physical security. Physical security is well understood, is implicit in doing business, and has much stiffer criminal penalties associated with it. When looking to implement an information security program, "restricting physical access to publicly accessible network jacks" (priority 9.1.2) has been justifiably pushed down to priority 5.

All in all the Prioritized Approach is a nice addition to the PCI Standard. For all its troubles, PCI is the closest we have to an industry consensus on what is considered reasonable security.

Security Spending Benchmarks Report

Today the OWASP Security Spending Benchmarks Project published its first quarterly report.

We've been working hard on gathering data over the last few months and it was well worth the effort. I had the privilege of leading this project, with great contributions from our 17 project partners and tremendous help from Jeremiah Grossman at WhiteHat.

We started out with a simple question - how much security spending is enough when developing web apps and software? We all know that there are a lot of web apps out there that are not sufficiently secure. Some of this bad security is a result of sheer ignorance. But most bad security results from lack of effort. Or applying that universal law of business (TIME=MONEY), due to a lack of resources.

In other words, most web apps are insecure because no one bothered spending the time or money to secure them. But since one could theoretically spend 90% of a project budget eliminating every esoteric web app vulnerability known to man, how much spending is enough? Executives want to know what the industry norm is, set aside that budget, and see the security issue disappear so the company can focus on its core business. Although this may not make some security purists happy, in the vast majority of companies security is a tax. And like with most taxes, when the rates are unclear and the tax code is too complicated, people start fudging and figure they'll take their chances.

The security tax is relatively well understood in web security's better funded cousin, network security. When it comes to basic network security there is a conventional wisdom of a security tax of somewhere between roughly 5 and 10%. No such consensus exists for development. It is this vacuum that the OWASP Security Spending Benchmarks Project addresses.

THE FACTS

From the get go we have focussed on making a different kind of survey - a collaborative data collection effort by the community without any added spin. We want the facts to speak for themselves with the goal of better understanding security spending in development. That is why we have kept our own thoughts and analysis limited to blogs like this but out of the actual report. Also in what I believe is a first for a security spending survey, we have also released the raw survey data that can be found on Survey Monkey.

There's a detailed description on the project page of our methodology and repsondents. A bit further down in this post you can read about some factors that may have affected the quality of our data. So if there are any statisticians in the crowd, please keep in mind that we realize that our resulting data is far from perfect. I do however think that our open community approach has led us to results that are at least as good as funded proprietary surveys that until now have been the only source of data on this topic.

So with that grain of salt sitting on the plate, let's take a deep dive into some of the key survey results...

Data breaches loosen the old security purse strings. The survey data validates the unsurprising fact that companies that have suffered security incidents are more likely to invest in security and have security executives on staff. Any one who has spent any time negotiating security budgets knows that security incidents are unfortunately a powerful (and somewhat belated) kick in the behind to get security projects rolling. This also makes sense from an enterprise risk perspective - most customers and even regulators can forgive one data breach (after all, stuff happens as they say). Two data breaches is of course a different ball of wax.

The recession/depression is not negatively affecting app security spending. At first it seems a bit surprising that we found that web application security spending is expected to either stay flat or increase in nearly two thirds of companies. After all, isn't everyone but the government basically broke? But of course the reason we are broke is bad risk management. As I predicted back at New Year's, we got into this big pile of financial $%*#& due to a fundamental inability to assess risk and there is going to be a ton of new risk related regulations in the financial sector. And once legislators get the old regulating pen out, you can betcha that infosec regulation is on the way too. In fact, the bailout , ummm, I mean American Recovery and Reinvestment Act contains a major strengthening of HIPAA data breach notification requirements.

Most companies have specific IT security budgets You don't get very far without a budget, and 67% percent of companies surveyed have specific IT security budgets. For companies that had suffered incidents, this was almost 90%. The interesting thing about having a specific security IT budget is that it pits competing security interests against each other at budget time.

There's very little development headcount dedicated mainly to security. In a whopping 40% of companies, there is less than 2% of developer headcount dedicated to security. This makes sense to me, because the job of developers is basically to build stuff without making really obvious security mistakes. As I have said before for many organizations I don't see a real alternative to some kind of build-then-try-to-break approach to producing secure code.

Most companies do third party security reviews. At least 61% of respondents perform an independent third party security review before deploying a Web application while 17% do not (the remainder do not know or do so when requested by a customer). I find this one of the most surprising statistics, considering the expense of third party reviews and the (probably false) assumption many companies might have that they can do this in house. This statistic seems to indicate that there is widespread acceptance of the breakers model of building secure code.

Security is important when hiring. For most companies it is completely infeasible to do a security review of every line of code a developer writes. That's why developer education and previous security experience are so important in producing secure code. That might explain the surprising fact that half of respondents consider security experience important when hiring developers, and a majority provide their developers with security training.

Competitive advantage is not an important factor in security spending decisions. Competitive advantage ranked last out of five factors that could influence security spending, while compliance ranked first. This reflects a reality that I see everywhere except for certain navel-gazing security conferences and highly sensitive industries - namely that regular ordinary folks do not make purchasing decisions on the basis of security. They expect basic security as part of a product or web application.

Web application security still has a relatively small part of the security spending pie. There are a couple of reasons for this in my opinion. Web app security is still somewhat new, at least compared to the classical network security approaches. Many standards and RFPs still place a very heavy emphasis on network vs. application security. For example, the recently announced Priority Approach for PCI prioritizes virtually all network security requirements ahead of web application security requirements. Another reason that web application security receives relatively little budget in my opinion is that it does not come bundled together with other functionality. Many security products allow new and visible ways of managing and mointoring users. Most web application security spending on the other hand leads to something that is almost completely invisible, namely a locked down application. Locked down applications don't make for very good powerpoint slides. "Total network awareness" products do.

I've got more to say on that but I feel we are digressing a bit. If you are still with me, I'd like to dedicate some ink/pixels to an honest critique of the data quality in the OWASP SSB survey.

LIES, DAMN LIES, AND STATISTICS

I always read survey results with a healthy dose of skepticism. Too often you read stories along the lines of "1 in 3 grandmothers reports losing social security check due to insecure mailbox", with a press release the next day announcing a new mailbox lock.

So having just reviewed our results, its time to analyze the accompanying grain of salt. Openness and collaboration is a big part of the OWASP Security Spending Benchmarks Project. Although we made every effort to maximize the quality of the data and analysis, the data is not perfect. Surveys never are, but of course businesses are constantly forced to make critical decisions on the basis of imperfect data. Ultimately the goal of the project is to capture the best possible picture of the development spending landscape and - equally important - to stimulate a discussion that can lead to further consensus on this issue.

I may have missed something, but here in no particular order are the possible issues that affect the reliability of survey results:

(1) People not answering truthfully.
Well, not much you can do about this. We kept this to a minimum during the OWASP SSB survey by rejecting responses that took less than 2 minutes to fill out and by spreading the survey through a trusted list of contacts.

(2) Intentional skewing of results by subverting the survey process
(eg. responding multiple times). Internet surveys that offer some degree of anonymity will always be vulnerable to this. Again, our survey methodology as described on the project page was designed to keep this phenomena to a minimum.

(3) A non-representative respondent base
I think that this is the most significant potential weakness of our current survey. Although we have a number of non-security partners involved, the current list of partners consists primarily of security consultants and other organizations. Although I don't think that this significantly skewed the results, there is a possibility that the companies we reached out to through our partner network were somewhat more security aware than a randomly selected company. In the next quarter, we plan to expand our partner base to include a greater number of non-security related companies.

(4) Badly formulated or suggestive questions.
This is the "Do you (a) support candidate X or are you (b) a heartless fascist" problem. There is an entire industry built around the proper phrasing of survey data to get accurate results. Although none of the partners is a survey expert to the best of my knowledge, many of us had been involved in similar efforts in the past and we attempted to phrase the survey in a neutral way that would lead to the most accurate results.

(5) Drawing incorrect conclusions from the collected data.
Our project report attempted to avoid this by sticking to the facts and leaving the analysis to the blogs. Also, unlike every commercial survey I have read in the last few years, our project actually releases raw data to the community to evaluate. There are no "proprietary method" or "confidential sources". In fact we welcome competing analysis and others using our data to further discussion around this topic.

(6) Opaque and non-verifiable process.
I think we steered safely clear of this pitfall as well. Our project plan is always available on the project homepage. Any one who is willing to commit some time and energy into promoting the survey and providing strategic input is welcome to participate.

THE NEXT STEPS IN THE OWASP SSB PROJECT

We are planning to build on the momentum of this first survey to get more companies involved and to get new thematic priorities. The current status of the project will always be available at the project homepage.

UPDATED PRESS COVERAGE:

This project generated siginificant press coverage, which is great for our goal of establishing industry wide benchmarks.

Click here for a video interview I gave Search Security on the project

Other coverage includes articles in SC Magazine, Dark Reading, Search Security, PC World, Information Week, and numerous other publications.

There has also been coverage in German and Spanish.