« Version 4.1 - 7.0 Security Policies and Procedures, Best Practices and Standards 8% | Main | Version 4.1 - 7.2 Information Security Standards »

Version 4.1 - 7.1 Security Policy Elements

Everything starts with the Security Policy. Good security policies should simply state what you want secured and to what degree. They should not include the specifics on how to do this. [Those are procedures.]

The Security Policy should be written in the form of directives. It should also have the authority and approval of Executive Management. Now think about that - if you want Executive Management to endorse (and give you the authority to implement) this policy, you better make it "management friendly."

That means:
1) keep it short (succinct)
2) use command statements (shall/ shall not)
3) don't use technical terms and concepts
4) focus on desired outcomes (meeting compliance, preventing business disruption)

According to one Study Guide, there are seven security policy elements:

1 - Security accountability. (Roles and responsibilities)
2 - Network service policies. (Who can access what data in which ways)
3 - System policies. (Host/endpoint/server security)
4 - Physical security (Data center and access to building - to become an endpoint)
5 - Incident handling and response (Roles and responsibilities for incident management)
6 - Behavior and acceptable use policies (General expectations and consequences)
7 - Security training (Frequency, type and mandatory participation)

Note that these elements are very general. This should be an executive summary and should point to other policies and procedures. There should be a separate Acceptable Use Policy which outlines exactly what behaviors are allowed and consequences for non-compliance. All users should read and acknowledge the AUP. The Security Policy should reference this AUP, but not include all the details. The Security policy should state that all users should read and adhere to the AUP. It should also focus on roles (Incident Manager) and responsibilities (responsible for directing the resolution of system outages and the creation of Corrective Action Reports of Severity 1 incidents to Executive Management). Further policies, such as the Incident Management policy, would detail exactly how this would unfold. That policy may direct the use of specific incident management software, incident resolution bridge lines and the call-out of relevant personnel. And then in the Procedures documents, you would get into the specifics of how you would actually carry out these policies. So know the difference between policies and procedures. Policies are in management-speak and procedures are in techie-babble.


Powered by
Movable Type 3.2