- Defining "Security Policy"
- Building a Security Policy
- The Blueprint for Happiness?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Building a Security Policy
The down and dirty details involved in building a security policy require far more coverage than I can provide here, so I'll give you a high-level review of what's involved. In addition, I'll point you to numerous resources that explain the process further and provide some great examples that you can use as go-bys for building your own security policy.
As mentioned earlier, a security policy is a living document so it requires regular, scheduled review and maintenance. Thus, it should also be obvious that creating a security policy for the first time is bound to involve more work that subsequent reviews and updates will require.
For the first go-round, your process will probably follow a path similar to this:
Phase 1: Asset inventory and elaboration: This is the phase during which you take stock of what information and physical assets you wish to secure, and what those assets are worth. This will help establish where access controls are most needed, and how much you should be willing to spend to secure such assets.
Phase 2: IT Security Audit/Inventory: In this phase, you perform a formal security audit on your IT infrastructure and take stock of various security components, settings, configurations, controls, and so forth that are already in place. Without a security policy to guide their application, expect some inconsistencies and possible errors to show up, along with possible vulnerabilities and exposures.
Phase 3: Employee Policy Inventory: Here, you'll examine your current employee handbook, plus any other published security policies, practices, and procedures that might be in place. Be sure to note what's been stated, and to check if infractions come with accompanying consequences.
Phase 4: Physical Security Audit: This is the phase wherein you monitor and document how access to your premises in general are controlled, how access to sensitive areas is managed, and how keys, off-hours entry, identity cards, and so forth are issued, managed, and monitored.
Phase 5: Risk assessment and protection requirements: At last, you're past documenting what's currently in place. This is the phase wherein you document what needs to be secured, and how much protection such assets require. This information will serve as the foundation for your security policy.
Phase 6: Set protection levels, policies, and procedures: Here's where you implement controls, policies, procedures, and employee training to begin deploying your security policy.
Phase 7: Test protection levels, polices, and procedures: At this point, you'll conduct internal tests and may even hire outside contractors who specialize in attacking defenses to discover weaknesses and suggest ways to remediate them. You'll cycle between this phase and the previous one until no new sources of weakness, or causes for further remediation are uncovered.
Phase 8: Establish backup, recovery, and business continuity plans: In the event that systems, networks, or entire sites become inaccessible or unusable, you should be prepared to switch to some kind of backup. Although not all experts agree that backup, recovery, and disaster recovery plans are part of a well-designed security infrastructure, since security is ultimately supposed to protect assets from loss or harm, you're better off including such plans than leaving them out.
Phase 9: Document security policy: Now, you can collect your revised and updated inventories, revised protection levels, policies, and procedures, document your risk assessments, asset valuations, protection requirements, and backup, recovery, and business continuity plans in a single document. Add a prescribed schedule for regular testing, monitoring, and auditing, with a description of how to update the security policy document itself, and you're finished with the first round. Congratulations!
From here on out, you're in maintenance mode. To some extent, this means repeating all the steps described above, but only as much as is necessary to reflect changes in assets, additions of new technologies and systems, changes to physical security, and so on and so forth.
The real work during the maintenance phase consists of scheduling and performing the following activities (all of which should be part of what you record as the last phase of the first version of your security policy document):
Monitor security alerts, services, and related news: Apply relevant patches, fixes, and updates as needed (that is, whenever they're relevant to your circumstances or needs).
Perform periodic penetration testing and security scans: Despite your best efforts to keep up with changes, patches, and fixes, items can occasionally slip through the net. Regular testing and scanning will help detect and give you an opportunity to correct such omissions. The usual period for such testing is anywhere from monthly to quarterly to yearly (this too, will depend on the value of the assets you seek to protect and how worried you must be about their potential compromise).
Perform regular security audits: Just as financial policies, practices, procedures, and related data and systems must be inspected and evaluated on a regular basis in most public corporations, so also should your security infrastructure be subjected to the same kind of hard, uncompromising, and objective outside review. Yearly frequency is normal; organizations with highly sensitive assets or information may want to do this even more often.