If you missed the first part in this article series please go to Writing an Effective Security Policy (Part 1).
To: From:
Make sure it is clear who has issued the policy and who the policy applies to. As described in the previous article (Writing an effective security policy part 1), if it does not apply to the user make it part of the appendix, this way there can be no misunderstandings. If the policy is issued by senior management there is less likelihood that it will be contested.
Human resources and their involvement
HR will need to be involved; HR will know of the legal elements that need to be provisioned and will ratify the policy with the legal department or a legal consultant. Keep the agenda clear and do not let HR run away with an IT/IS/Sec policy. HR will also be able to advise on legal disciplinary action, once they have reviewed the security policy.
If the policy is being written to fill the audit gap, (compliance) then caution should be taken not to write ambiguous terms and controls into the policy without real cause. These loose terms can go into the appendix after legal advice has been sought.
If the policy is written in words that the user can understand, if a dispute arises it can not be construed that the meanings were ambiguous or difficult to understand.
Uses of security policy
The policy can also be used to prove in a court of law that due diligence by the company has been taken to prevent loss and reduce risk. It also proves that the organisation has ethical and legal intentions. For example part of the policy can, as part of the mandatory elements, enforce that users only use licensed software.
One of the elements ISO 17799/27000
The ISO 27000 series consists of is an international document series that can help in policy creation. This is a vast and open document so it is recommended that professional guidance is sought.
Other policy elements, a summary
-
Get senior management to buy in
-
Be reasonable
-
Do not forget the people; make sure the policy encompasses the people element and where the people came from; you do not want to be employing the wrong robbers if you run a bank…
-
Keep a consistent clear approach based on fact
-
Make the policy enforceable
-
Base the policy on an international framework like ISO 27000 series
-
Achieve business goals whilst complying with laws and regulations
-
All exclusions and detail are appendix not part of the body of the document
-
Update the policy at least once a year to keep the document current
-
Be clear, direct specific and concise
-
Do not use legal terms and difficult to understand jargon
-
Involve HR and legal and get senior management signoff
-
Get senior management to issue the policy
-
Ensure that users have read and signed the policy
-
Involve all the companies departments
-
Ensure that if you merge the new entity is using the same policy
-
Apply the policy to users of company facilities, remote or local
-
Ensure that the policy is available in all spoken languages
-
Adapt the policy to the companies culture
-
Define everything, you can put this in the appendix so that it does not look like a contract
-
Remember that the policy will also apply to company assets
-
Keep the policy independent of software and hardware solutions
-
Other policies may form part of the security policy like AUC (Acceptable Usage Policy)
-
Cover all the elements from layer one to layer sever of the OSI model
-
Cover the TCB (trusted Computing Base) and user behaviour
Include other policy elements like
-
Availability of resources and schedule of available
-
Accountability framework
-
Authentication policy for both remote and local access to logical and physical company assets
-
Access control list defining access to company resources
-
AUC policy
-
System maintenance policy
-
Incident policy
-
Backup policy
-
Antivirus policy
-
Antimalware policy
-
Anti piracy policy
-
Disaster recovery policy (plan)
-
Business continuity policy
-
Segregation of duties
-
Vulnerability assessment policy
-
Software update policy
-
Least privilege policy
-
Password policy
-
Employment background check policy
-
Data confidentiality policy
-
Hardware and software inventory policy
-
Asset location policy
-
Internet usage policy
-
Email usage policy
-
Information flow policy
-
Desktop security policy
-
User monitoring policy
-
Guest user policy
-
Physical security policy
-
Mobile computing policy
-
Wireless access policy
Even though the above policies look complex they can be brief concise and can form part of the same document, as long as the clear understanding has been conveyed. The above list of policy elements can be gathered into one document and the respective technical controls build around the subjects and objects in order to achieve the business goal.
Any agreements with external parties should also include such elements as this ensures that the service provider also abides by good practice and in turn is not exposing the organisation. Changes to the security policy should be published and the third parties notified and a response should be requested in writing ensuring that the service provider is complying with the policy. A trend in the UK is now proliferating where by this is becoming more of the norm when dealing with governmental institutions.
Where do security policies go to die?
Emailed policies that are only signed when the user starts at a new position and never again are not good news. In the HR cupboard, when a user has to phone to get a copy of the policy then you know the policy is dead. If it was not, the user would have no need to resurrect the policy out the depths of HR.
Policies that are not maintained are unclear, do not apply to most users, and are written in difficult to understand language are not only dangerous but will not be read and adhered to. The policy needs to be in full view of the people that it pertains to. Enforcement must be possible and thus, the rules should be read before the start of the game. This (or elements of the policy) can be reinforced every time a new event or action is performed.
What now?
The next step is to make a start if you have not already done so, if you unsure of where to go next seek professional assistance, there are qualified CISSP that can assist and many resources on the internet that will help you along the way. Remember your HR department can help and they most probably already have a basic policy that you can extend. As long as you are aiming at achieving the business goals and you are being clear about how the organisation want the user to behave, then you should be well on your way to writing an effective security policy.
Ref: http://www.faqs.org/rfcs/rfc2196.html
Summary
In the second article we focused on policy elements and the reasons that HR and legal are involved when formulating the security policy. We also covered security policy summary this can be printed out as a guide when reviewing and writing your policy. I hope that this series was useful and that you are closer to extending your organisations security policy.
If you missed the first part in this article series please go to Writing an Effective Security Policy (Part 1).
