Authority documents tell us what we need to do to comply. Some of them try to be very prescriptive and tell us how to comply, but for the most part, authority documents stay with the what.
The Main Thing you need to understand about authority documents falls into three categories:
1. You need to understand how to properly identify authority documents and the version of the authority document you are working with. While this sounds overly simple at first glance (and if you were just reading them, it would be), it isn’t. Primarily because your organization is under multipleauthority documents’ purview and you are going to need to track them, differentiate them, and decide which has hierarchical governance over the other.
For instance, at first read, the FACTA privacy document would seem to be at odds with the PCI-DSS credit card protection document. Both state to mask the credit card number on any output (display, electronic documents, or printed records). However, FACTA states to cover one set of numbers while PCI-DSS states to cover another. If you didn’t understand the hierarchical relationship of the two documents, you wouldn’t understand that FACTA deals with output for end users while PCI-DSS was dealing with output for merchant authorizations – two separate document types and uses.
2. Authority documents tend to have their own language. Therefore, you will want to begin the maintenance of a glossary to provide a guideline to the way each authority document uses verbiage.
For instance, PCI-DSS uses the term cardholder data when talking about privacy issues. HIPAA uses the term Electronic Private Health Information. The various state and European laws speak of Personally Identifiable Information. All of the above instances, while dealing with individual fields in a record, deal with a record’s confidentiality, integrity, and availability the same way. If you were to swap the specific words each authority document uses with the generic term “confidential data” then all would pretty much read the same.
3. Authority documents each have their own perspective on how to write a control, and the hierarchical status of one control to another. Some authority documents will write “clean” control paragraphs, meaning that each control paragraph creates a measurable action. Others will lump multiple measurable actions into a single paragraph – which will then need to be broken out into multiple paragraphs. And others will repeat the same control (turn off FTP for instance) multiple times throughout the same document (turn off FTP on the <insert asset names here>) because the authority document’s focus is on assets (or processes, or whatever) rather than on controls per se.
For instance, § 8.2 of the PCI-DSS states that the organization must employ some type of access authentication methodology. The effect is to authenticate uniquely identified users in general. Then in § 8.5.16, it calls for the organization to authenticate access to any database holding cardholder data. The target is now very specific – while the effect (authenticate uniquely identified users) is the same.
When examining the hierarchy of controls, many authority documents don’t begin at the natural rootcontrol that they should.
For instance, § 5125(b2) of the Clinger Cohen Act states that the organization must establish and maintain sustainable technological infrastructure planning. However, what they fail to mention is that this control is dependent upon the organization first that they have a program to analyze the organizational objectives, functions, and activities so that sustainable infrastructure planning can take place.
Within the UCF we track all of this for you, if you are building out your own compliance framework, these are things you are going to need to add for yourself.