Focus is over-rated when you’re starting out. The original idea for my presentation at The Privacy & Security Forum in Washington, D.C. was to talk exclusively on how security controls relate to the frameworks that sweep them up and organize them. It was to be “how controls become a framework” in the spirit of the grammar school lesson ”how a bill becomes a law.”
It ended up rather differently.
Dr. Daniel Solove, who along with Dr. Paul Schwartz organized the event, asked me to introduce a specific control as a case in point: authentication. What I ended up with was a presentation that demonstrated how controls and frameworks differ. I had expected to just illustrate that there was a one to many relationship between a framework and the controls in it.
Not surprisingly, I arrived at the conclusion that controls are in certain ways more specific than frameworks. I found some interesting things In the details that led to that conclusion and I tried to demonstrate that this was more than just a straightforward exercise in taxonomy.
Who Cares About Frameworks and Controls?
Before defining the two, it seemed important to discuss who the stakeholders are when it comes to controls and governance frameworks. I believe there is agreement that some kind of governance is required. Someone should be “minding the store” but…
On the other hand, everyone cares about controls. I quoted the following from a recent breach notification [emphasis mine]:
“…the hackers’ method of entry has been closed off and the malware has been eliminated from the company’s systems. [Our] investigation, cooperation with law enforcement and efforts to further enhance [our] security measures are ongoing.”
Almost every breach notification press release or article you read will have the spokesperson for the breached entity explaining that they have controls and are evaluating them to see if either they need to make them stronger or if they need to add additional controls. Information security is no different than any area where protection is an objective: safeguards matter.
Definitions
It was easy to find an adequate definition for security controls. NIST IR 7298 Revision 2, Glossary of Key Information Security Terms is the one I used in the presentation:
“The management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for an information system to protect the confidentiality, integrity, and availability of the system and its information.”
A good working definition for a framework was harder to come by and that was my first clue that the difference between frameworks and controls was more than just the one to many relationship I had first assumed. So I defined what a framework was not:
While everything on the list could be important in creating a framework and all are inputs to a robust security program, with the exception of comprehensive security regulations perhaps, none are actually the same as a framework.
The Glossary of Key Information Security Terms did not define “framework.” This made some sense as it came out before NIST issued its Cybersecurity Framework 1.0. Even in that framework, however, the term framework is not clearly defined. Instead, I found a useful list of the functions of a framework in the NIST document:
- provides a common language for understanding, managing, and expressing cybersecurity
- can be used to help identify and prioritize actions for reducing cybersecurity risk
- is a tool for aligning policy, business, and technological approaches to managing that risk
This functional definition would have to do as a start.
Frameworks do provide a common language for the management of a security program. They have maturity models and categories, expectations and some way of classifying controls.
In terms of using them to prioritize actions and aligning risk management approaches, that comes down to the idea that they are an efficient way to conduct and arrange risk assessments and gap analyses.
And they seem to be a “closed system”. But only when represented as a static snapshot. Everything, even exceptions can be in relationship to a governance framework if it allows for exceptions.
The Forest and the Trees
Can a framework be seen as the “forest” and controls as the “trees”? Here’s where authentication as a case in point came in.
First, I cited a couple of frameworks. NIST:
- Access Control (PR.AC): Access to assets and associated facilities is limited to authorized users, processes, or devices, and to authorized activities and transactions
- PR.AC-1: Identities and credentials are managed for authorized devices and users
And the HIPAA Security Rule:
- 164.308(a)(4)(i): Information Access Management. Implement policies and procedures for authorizing access to electronic protected health information that are consistent with the applicable requirements of subpart E of this part.
- 164.312(d): Person or Entity Authentication. Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.
While the HIPAA Security Rule may not have been written as a framework, if I work backwards from the functional definition of a framework above, I think it is fair to treat it as one.
Then I went to back to NIST (Electronic Authentication Guideline, NIST Special Publication 800-63-2) for the description of the trees, a control:
E-authentication begins with registration. The usual sequence for registration proceeds as follows. An Applicant applies to a Registration Authority (RA) to become a Subscriber of a Credential Service Provider (CSP). If approved, the Subscriber is issued a credential by the CSP which binds a token to an identifier (and possibly one or more attributes that the RA has verified). The token may be issued by the CSP, generated directly by the Subscriber, or provided by a third party. The CSP registers the token by creating a credential that binds the token to an identifier and possibly other attributes that the RA has verified. The token and credential may be used in subsequent authentication events.
As an automated procedure for verifying that someone seeking access is the person they claim to be, this seems straight forward. Frameworks say what the goal is. Controls provide the detail for achieving it. But I began to see how the whole is bigger than the sum of its parts, that the forest is bigger than the collection of trees. To illustrate that, I went after two four letter words: “math” and “data.”
Math
Controls, it seems to me, should be measurable and auditable. But they should not always be quantitative, they should not always be appropriately recorded as data and I gave an example of each.
For “math” as a four letter word, I started with the AES encryption algorithm which can be expressed formulaically:
(All byte values in the AES algorithm will be presented as the concatenation of its individual bit values (0 or 1) between braces in the order {b7, b6, b5, b4, b3, b2, b1, b0}. These bytes are interpreted as finite field elements using a polynomial representation.)
I pointed out that there is a similarly formulaic expression for “entropy” with regard to password construction:
(Entropy in an information system is the measure of the disorder or randomness in the system. Passwords that do not have sufficient entropy are more likely to be recovered through brute force attacks. NIST Special Publication 800-118 (Draft))
The HIPAA Privacy rule as amended specifies that Electronic Protected Health Information that is encrypted using “Any encryption algorithm identified by the National Institute of Standards and Technology (NIST) as an approved security function in Annex A of the Federal Information Processing Standards (FIPS) Publication 140-2” is not considered breached if such data are compromised. Hence, encryption can be measured against an algorithm, such as the one above.
However, the HIPAA Security rule does not specify what level of entropy a password must achieve to be HIPAA Compliant. As an overall measure of the strength of the authentication component of a Framework, it would not be appropriate. Just because you have math does not mean you should use math.
Both encryption and authentication have a human side to them. Encryption can be seriously weakened by badly trained personnel managing the keys. But key , management is largely a back-end function. The end user committing sensitive health information to a storage device should not have control over the encryption deployed.
On the other hand, the human side to authentication is omnipresent. A strong password matters, but a user choose it. For the set of authentication controls to meet the criteria defined at the level of the framework, there are a lot of procedures (provisioning, modification, de-provisioning, awareness, etc.) involved and some of them are just not always fully automated. And evaluating them as part of a framework certainly should not be.
I think I was able to make an even stronger case for this when it came to data.
Data
To illustrate how one can go too far with defining data points to determine the adequacy of a control, I relied on an illustration I had used before. In a blog post from June 2014 entitled “Best…Practices..Ever,” I ranted about a floor mat that was referred to as “HIPAA Compliant.” Covered Entities and their Business Associates must comply with HIPAA, floor mats are under no such regulatory obligation. The idea of the floor mat was that one places the mat where the patient stands to talk to the receptionist in a doctor’s office. Provided no one else is on the mat and the conversation is conducted in civil tones, the conversation is considered to be compliant with the HIPAA Privacy rule.
We could certainly turn those requirements into measurable data points:
Using a decibel meter that is time synchronized to a camera looking down on the registration area, you could even create data records of the interactions between the receptionist and the patients they are registering. Those data records could be summarized and alerts could be issued when the values of x and y are not in line with the standard.
And to do so would be all wrong. Creating data points for human interactions in this case diminishes the overall objective of controlling waiting room interactions. It’ll make for a great graph but won’t tell you about the experience patients have checking in, or how confidentially they feel their information is treated.
Conclusion: controls can be automated sometime but frameworks never should
My conclusion pointed out that anytime you fully automate something, you leave it vulnerable to being hijacked. With authentication, we’ve seen this recently with how tokens are being exploited. Frameworks, I argue, help prevent that by insisting that security, privacy and data control objectives are larger than discreet control specific objectives.
So, I concluded with the following:
- We can use frameworks to keep controls from becoming isolated and fully automated
- Frameworks cannot be closed systems. Once they do, they become merely a list of controls kept whole by an exception process
- Frameworks themselves cannot/should not be fully automated
Frameworks must be dynamic and not fully automated because technology, threats and business cases often evolve more quickly than document/program revision allows. Because of this, frameworks are more than just a list of controls.
The Presentation
My presentation seemed to be well received. I think I raised more questions than I answered but I achieved my ultimate goal of discussing controls and frameworks together and trying to describe the relationship between them.
The Privacy and Security Forum offered professionals from many varied backgrounds the opportunity to hear from speakers that were in fields that impact theirs. Hearing from people who are not your peers but whose work sometimes has dramatic impact on your own is a fairly unique experience in our fields. More times than not, you are listening to someone who is directly in your filed (for me: other security professionals) or service your field (vendors). This event was broader than that and so extremely valuable in preparing professionals for the changing landscape of Privacy and Security. It was great to be a part of it.