Security standards — sorting through the alphabet soup

Early in my career, I worked as a systems programmer for IBM in South Florida. As everyone no doubt knows, IBM invented the acronym. There was always rumored to be an acronym dictionary available, although I was never ever to lay my hands on a copy — if in fact it really existed. 

Understanding acronyms has become a critical part of information technology practice today, with specialized subsets for difference disciplines. This is true in particular for information security, which has more than its share, including HIPAA, PCI DSS, SOX, etc. Information security is a complex discipline in itself, complicated by the alphabet soup of standards and regulations. This just adds to the intimidation no doubt felt by folks on the business side who are forced to put together an information security program that protects the business and the customer, and prevents a knock on the door by dark suits representing some regulatory body. 

So, why does this security standard jargon even matter?  A recent case in point involved the Federal Trade Commission (FTC) and a small dental software company, Henry Schein Practice Solutions Inc. This company marketed dental office software, which its literature claimed used “industry standard encryption” to protect patient data. The FTC investigated the company, and found that it used encryption technology it had developed itself. There is of course no formal definition for “industry standard encryption,” but I suspect that the company’s techniques were based on some formal, published approach.

That did not matter, however, to the FTC. Since it has no published security standards of its own, it picked one to apply in this case, namely, the National Institute of Standards and Technology (NIST) publications on encryption, and deemed that since the company advertised a standard approach to encryption and did not follow NIST, it was in violation, costing it $250,000. Ouch. 

The purpose of this article is not to comment on the FTC’s actions in this or any case, but rather to to point out that what you don’t know about security standards CAN hurt you. I hope to cut through the clutter of acronyms, and help you to know which ones you need to pay attention to. 

I generally break down security standards into two groups: 

Industry standards. This group encompasses the guidelines and regulations proffered by a regulatory agency or industry group. These are often broad, and focus on protecting customer/consumer data within a given industry. They rarely comprise a complete security framework, but rather are a subset of a broader standard. They include: 

• HIPAA
• PCI DSS
• SOX
• FFIEC 

General security standards. These are generally complete security standards published by a governmental agency or recognized independent group. They include: 

• NIST Security
• ISO 27000
• SSAE 16 

Just to ensure that everyone’s sanity is maintained, I will omit for this discussion the niche standards, as well as the operational frameworks such as COBIT and ITIL. 

Now, before you run off and join a support group for the acronym challenged, let’s try to demystify the whole idea of standards a bit with the following key points:

You need to follow the standards in place for your industry

There is a good chance that some set of regulations has been published for your industry. If not, you will likely see some emerge. Depending in the industry, they may be mandatory (such as HIPAA), or technically voluntary (like PCI). Regardless of the teeth your industry set has, your compliance reflects on your professionalism within your industry, with compliance increasingly becoming a competitive factor.

Industry standards are usually a subset of a complete security program

With the above statement, the PCI folks are likely throwing darts at my picture, but I stand by the statement. You can be fully compliant with an industry standard like PCI or HIPAA, and still not be secure. This is important because while you are usually mandated to comply with your industry standards, your true goal is sufficient security to protect your customers and your business.

You need to choose an overall security standard

None of us can claim to know everything, particularly in a complex field such as information security. We need to be able to measure ourselves by some standard, and there are plenty of general standards from which to choose. Since most of us are not required to adhere to one or the other, we will ultimately be judged legally and professionally against the one(s) we claim to follow. As I said in my article “Why your cyber insurance investment may not pay off,” while insurance companies generally do not specify a standard to be followed, they expect you to select one, and to follow it.

You need an information security policy document that reflects your chosen standard

Once you decide which standard you want to follow, your information security policy needs to reflect the elements of that standard. If you ultimately have a security incident, someone (regulator, insurance company, customer, etc.) will judge your performance by how well your policy reflects the stated standard, and how well you follow it. Your legal liability will be directly influenced by this.

Not to decide is to decide

If you ignore the whole idea of selecting a standard, it is likely that you will ultimately be measured by one anyway. If you doubt this, I refer you the the dental software case mentioned above. 

As for picking a standard, it really depends on your industry and your goals. ISO is popular, because it is a standard for which independent compliance certification can be achieved. That being said, government agencies seem to be falling behind NIST as their source of authority. 

Bottom line: Pick a standard and live by it. The business you save by doing so may be yours.