1.7 Develop, document, and implement security policy, standards, procedures, and guidelines

1.7 Develop, document, and implement security policy, standards, procedures, and guidelines

A security policy tells us what we need to protect and to what extent. 

• What is valuable to our organization and how much is it worth?
  
  
• Who is responsible for security?
  
  
• How can we verify that the security processes are implemented correctly?

We might have an organizational security policy that covers the entire business and issue-specific security policies that cover specific aspects of our operation (such as data storage, document retention, user onboarding, etc.).  We might also have system-specific security policies that cover specific computer systems or types of computer systems (for example, a database server).

When we create an effective policy, we must assign specific tasks to people.  But we don’t say that “Bob is responsible for configuring the firewall”.  Bob might quit and be replaced.  Instead we create roles.  For example, we might have a role called the firewall administrator.  Then we would assign the task of configuring the firewall to the firewall administrator.  When Bob is hired, he is given the role of firewall administrator.  If he is replaced, the new employee assumes the role.

These policies are divided into three categories

• Regulatory Policy – a regulatory policy is required by law.  For example, a policy might be implemented because of Sarbanes-Oxley (law that covers document storage for public companies) or HIPPA (law that covers health care record storage).  If we fail to follow this policy, the management and/or individual employees could be punished.
  
  
• Advisory Policy – an advisory policy is one that is required by management.  Management tells employees what things they can and cannot do.
  
  
• Informative Policy – an informative policy provides knowledge only.

A standard is a mandatory requirement.  For example, our organization might have a standard that requires us to buy Cisco firewalls.  The use of a Fortigate (a different brand of firewall), for example, would not be permitted under this standard.  We need standards because otherwise administrators would purchase equipment from different vendors, configure them their own way, and we would not be able to maintain or keep track of them effectively.

A baseline is the minimum-security standard that our infrastructure should meet.  For example, we might have a baseline that says “all communications must be encrypted with a minimum of 256 bit encryption”.  A device that is using 128-bit encryption would not comply.  A device that is using 256-bit encryption or 512-bit encryption would comply.

A guideline tells us how to implement the security standards and baselines.  For example, a guideline might provide details on the encryption software that could be used to meet the 256-bit encryption baseline, and how to install it.  We might have many different sets of guidelines for different systems, locations, or departments.  A guideline is not mandatory.

A security procedure or Standard Operating Procedure (SOP) or Standard Operating Protocol (SOP) tells us in great detail, the method of implementing a security system.  We create a procedure for each task that we perform that complies with the standards, baselines, and guidelines.  If we follow the procedure as it was written, then we know that our system will also be compliant with the standards, baselines, and guidelines.  The policies must be updated from time to time, as standards, baselines, guidelines, and technology change.

If you look at the different types of security documents, you can see that they form a hierarchy.  At the top of the hierarchy, we have few documents and at the bottom, we have many.  We should not try to fit all of our security policies into one document.  That would be bad because

• The document would need to be updated frequently.  Imagine that you had only one document that provided thousands of different procedures.  It would probably get updated multiple times per day.
  
  
• Not every user should have access to every policy.  A user should only have access to the documents that he needs in order to perform his job.
  
  
• The document would require many authors from many different specialties
  
  

At the top of the hierarchy are Policies, then Standards, and then Baselines, and then Guidelines, and then Procedures.  Sometimes Standards and Baselines are grouped together.