All Your Base Are Belong To Us
Once upon a time (many many years ago), I was staying with a French family, and they asked me what I ate for breakfast. For the life of me, I could not remember how to say “honey” in French. I ended up saying “the stuff made by bees”, and they eventually got the point, “Ah, oui, miel!” So, we reached an understanding by talking about what we knew. Well, at least kind of an understanding. I was, after all, in France for two weeks, and didn’t really want any miel for breakfast. I was thinking more along the lines of fresh croissant and café au lait.
When you talk about security with colleagues do you ever wonder if you are speaking the same language? I can’t even say how many times I have heard people talk about “Audit” like it could guarantee security or prove compliance. I can’t say how many times I have heard someone talk about how they are secure because they have so many controls in place, but they could not actually validate any controls or had no ability to prove their level of security/compliance to an auditor.
A short while back, I was involved in a conversation in which two managers were talking about their objectives for the next year. One of them said “to be secure”, while the other one said “to be compliant.” They kept talking about these goals like they meant the same thing. They do, but they don’t. You can be secure without being compliant, and it may be harder to do so, but, yes, you can be compliant without being secure. The functional result may be the same, but not necessarily.
Security and compliance are the same in the context that you have to define some goal, and plan a series of controls. You need to plan and execute controls around the trinity of security: hardware, software, and wetware. Hardware gets physical and environmental controls designed to protect the equipment from physical harm, as well as to block unauthorized access to the systems. Software gets testing and validation, hardened systems, and other protections. Add other technology for anti-malware, firewalls, and encryption. For wetware (people) you are limited to good, sound policies, effective training and awareness, along with the diligence of good people. But in any case, how do you get people to talk the same language?
I worked with a system that would score your security program on a 0-5 scale. “0” was essentially “Badges, we don’ need no stinkin’ badges”, and “5” was the strongest security you could implement for a given control. The system has good elements and bad elements, but the single most useful thing it does is give people a common language to use when they refer to security. For clients who really use the system effectively, for them to say “we are at a 3.0” means something to other people in the room. This works when they all have the same context, and makes these conversations easier, but everyone needs that context.
Part of this is asking the right questions. If you cannot answer these questions it is probably only because you never really asked them. Your security program should absolutely be starting here.
1. What is your business? Do you have a defined mission or business objective?
2. What and where are your cool data? What are the exact data sets that are critical to my company, whether they are organizational data or customer data?
3. What is important for the security of your organizational and customer information? Are there specific regulations that cover the protection of the information you create and consume?
Pretty much everything else you do in your information security program will be derived by the answers to these basic questions. These are not necessarily easy questions to answer, but they are also not incredibly hard. You pretty much have to answer numbers 1 and 2 just to be able to run your business with any level of effectiveness, and you better be answering #3 if you actually want to be able to stay in business without being fined or sanctioned out of business.
What is the air speed velocity of an unladen swallow?
These are not trick questions. And there are plenty of right answer, as well as, unfortunately, plenty of wrong answers. You should have a mission statement for your organization that is well enough defined that every employee should be able to paraphrase it. I would like to say “quote it”, but I don’t expect every organization to have a crowd of zombie followers.
As far as your “cool data”? Anyone who knows me has heard me belabor the point many times. This is one of my personal little soapboxes – have you done a BIA (Business Impact Analysis), or a data asset inventory, or whatever it is you end up calling it?
You will see and hear different arguments from different people, but I have been doing this work for 27 years, and my rule is “follow the data”. Your data will tell you what you need to do. If you have generic manufacturing data like run quantity and supplier information for material that is non-specialized and non-proprietary, what is your need for security? If you have detailed financial information including credit card numbers and full billing addresses, along with medical records for clearly identifiable people, what is your need for security? Follow the data.
By evaluating the type and content of your data, you can determine which regulations cover you as an organization. Obviously, you can also determine the controls you put in place to protect the data itself. By evaluating the volume and quantity of data, you can determine storage and transmission requirements. By evaluating the criticality of the data we can determine the availability requirements. In each case, if we look at just the data, we can determine everything we need to know about the security control we should plan on putting in place, thereby defining our entire security program, compliance requirements and all.
XYZZY
Neither Security nor Compliance are magic words. You cannot express the need for them and they just happen. Both are admirable goals, but both carry with them a level of focus and effort. Where do you start? Follow the data – sound familiar?
I once did some work for a hospital in New England that had a well-defined security program. While they made some compromises for exigent circumstances relating to clinical care, they primarily built their security program around the data, considering privacy requirements for the exact data they were consuming.
Any security program needs basic controls in the vein of the classical CIA (Confidentiality, Integrity, and Availability). But how much of each can be defined by evaluating the requirements of the data being used within the organization. Compliance requirements are effectively additional controls placed on top of the specific security requirements in the program. This seems kind of contrary to the premise that compliance is a proper subset of security, but it is. The data merely helps you identify the compliance requirements, and you “adapt” the security controls to meet the requirements for compliance, but they are still ultimately security requirements.
And this is why it is harder to be secure, but not compliant, than it is to be compliant, but not secure. If you are protecting your data with appropriate security controls, you likely have many of the compliance controls already in place, or at least a foundation laid for them. If you look at compliance first, you run the risk of designing a customized control that does not maximize the implementation of a given control, and thereby inheriting risk.
The hospital had a clinical system that did not support application passwords, and the antique operating system that supported the application didn’t support multiple users. So, they left the system un-passworded, a clear violation of HIPAA. Adding a shared system level password to the computer would technically have met HIPAA requirements, while adding minimal extra security.
Instead, they took a more secure stance of placing the computer that held this particular application behind an access controlled door that only limited hospital staff could open with their badges. Additionally, they placed the system in office space that was manned by an authorized user 24 hours a day, so effectively eliminated the chance that the active system would be viewed by any unauthorized person. Overall, this made unauthorized access highly unlikely, and was probably a more secure solution. Technically this would have been a compensating control under HIPAA, but if they had evaluated the system with only compliance in mind, they may have never arrived at that answer.
In this case, better security was the better answer.
