- Introduction
- The Risk of Poor Security Management
- The Role of CIA
- Risk Assessment
- Policies, Procedures, Standards, Baselines, and Guidelines
- Implementation
- Training and Education
- Auditing Your Security Infrastructure
- Exam Prep Questions
- Answers to Exam Prep Questions
- Need to Know More?
This chapter is from the book
This chapter is from the book
This chapter is from the book
Policies, Procedures, Standards, Baselines, and Guidelines
Security is truly a multilayered process. After an assessment is completed, policies will fall quickly in place because it will be much easier for the organization to determine security policies based on what has been deemed most important from the risk assessments. The assessment should help drive policy creation on items such as these:
Passwords
Patch management
Employee hiring and termination practices
Backup practices and storage requirements
Security awareness training
Antivirus
System setup and configuration
For security to be effective, it must start at the top of an organization. It must permeate every level of the hierarchy. Senior management must make decisions on what should be protected, how it should be protected, and to what extent it should be protected. These findings should be crafted into written documents.
Before these documents are locked in as policies, they must be researched to verify that they will be compliant with all federal, state, and local laws. These documents should also clearly state what is expected from employees and what the result of noncompliance will be.
Security Policy
Policies are the top tier of formalized security documents. These high-level documents offer a general statement about the organization’s assets and what level of protection they should have. Well-written policies should spell out who’s responsible for security, what needs to be protected, and what is an acceptable level of risk. They are much like a strategic plan because they outline what should be done but don’t specifically dictate how to accomplish the stated goals. Those decisions are left for standards, baselines, and procedures. Security policies can be written to meet advisory, informative, and regulatory needs. Each has a unique role or function.
Advisory Policy
The job of an advisory policy is to ensure that all employees know the consequences of certain behavior and actions. Here’s an example advisory policy:
Illegal copying: Employees should never download or install any commercial software, shareware, or freeware onto any network drives or disks unless they have written permission from the network administrator. Be prepared to be held accountable for your actions, including the loss of network privileges, written reprimand, probation, or employment termination if the Rules of Appropriate Use are violated.
Informative Policy
This type of policy isn’t designed with enforcement in mind; it is developed for education. Its goal is to inform and enlighten employees. The following is an example informative policy:
In partnership with Human Resources, the employee ombudsman's job is to serve as an advocate for all employees, providing mediation between employees and management. This job is to help investigate complaints and mediate fair settlements when a third party is requested.
Regulatory Policy
These policies are used to make certain that the organization complies with local, state, and federal laws. An example regulatory policy might state:
Because of recent changes to Texas State law, The Company will now retain records of employee inventions and patents for 10 years; all email messages and any backup of such email associated with patents and inventions will be stored for one year.
Standards
Standards are much more specific than policies. Standards are tactical documents because they lay out specific steps or processes required to meet a certain requirement. As an example, a standard might set a mandatory requirement that all email communication be encrypted. So although it does specify a certain standard, it doesn’t spell out how it is to be done. That is left for the procedure.
Baselines
A baseline is a minimum level of security that a system, network, or device must adhere to. Baselines are usually mapped to industry standards. As an example, an organization might specify that all computer systems comply with a minimum Trusted Computer System Evaluation Criteria (TCSEC) C2 standard. TCSEC standards are discussed in detail in Chapter 5, "System Architecture and Models."
Guidelines
A guideline points to a statement in a policy or procedure by which to determine a course of action. It’s a recommendation or suggestion of how things should be done. It is meant to be flexible so it can be customized for individual situations.
Procedures
A procedure is the most specific of security documents. A procedure is a detailed, in-depth, step-by-step document that details exactly what is to be done. As an analogy, when my mom sent my wife the secret recipe for a three-layer cake, it described step by step what needed to be done and how. It even specified a convection oven, which my mom stated was an absolute requirement.
Procedures are detailed documents, they are tied to specific technologies and devices (see Figure 3.4). You should expect to see procedures change as equipment changes. As an example, imagine that your company has replaced its CheckPoint firewall with a Cisco PIX. Although the policies and standards dictating the firewalls role in your organization probably will not change, the procedure for configuration of the firewall will.
It’s unfortunate that sometimes instead of the donkey leading the cart, the cart leads the donkey. By this, I mean that sometimes policies and procedures are developed as a result of a negative event or an audit. The audit or policy shouldn’t be driving the process; the assessment should be. The assessment’s purpose is to give management the tools needed to examine all currently identified concerns. From this, management can prioritize the level of exposure they are comfortable with and select an appropriate level of control. This level of control should then be locked into policy.
)
Figure 3.4 Policy structure.