Considerations for a IT Security Policy
- Why do you need to have a security policy?
Geeks vs goons
In my tenure as a system admin I have encountered a good number of users, who will refuse to comply with IT policies and advice. The computers allotted to them are soon regarded as personal computers.
Such users will often install software not required for business, install an antivirus of their preference regardless of what the organisation has invested in.
Above is a win-win situation for the goons, unless you have a policy.
Without a documented policy there will be many slips and employees will use their positions and influence as they see convenient.
-How to begin
Depending on the size of your organization, you must put together a team of people who would act as a committee to jointly plan out the policy and make sure its conventional. Its best if this committee includes people of different levels of the hierarchy.
With the help of this team determine the following
- Key business infrastructure
- Identify threats to the infrastructure, identify level of risks
- Identify the access level required by departments and team members
- Identify key infrastructure to build the anatomy of your policy
- Identify privileged users
Anatomy of the Security Policy
This is the real part of your policy which will highlight the risk and mitigation plan. Which makes it the less fancy part of the document, the fancy sections would consist of -
- Overview
- Purpose
- Scope
- Policy (you are here)
- Enforcement (the hardest part)
- Version history ( be sure to mention what was revised, why and by whom)
Anywho, in the policy section you will address risks/ threats to your infrastructure and business. Mention each item against its guidelines, training, config / support details-
I’ll break the ice with few key points you need to work upon
Risk /Threat definition
You must identify what vulnerabilities exist, and which of them are actual threats.
Infrastructure /config details
Specific recommendations and configuration detail of your running infrastructure. And references to any relevant manufacturer /support documents.
Trainings and awareness
Its best if users are given basic training to know their systems better. Some basic trainings to familiarize users with antivirus software. Risks of p2p and other shareware.
Notification / escalation
Key people must be identified who would be alerted on the occurrence of a security violation. This would ideally include members of the business and tech side.
Business continuity plan / Disaster recovery plan
Altho this doesn’t entirely fit under a security document, but security procedures must leave some room for a parallel BCP /DRP effort.
