Archives ||  About Us ||  Advertise ||  Feedback ||  Subscribe-
-
Issue of October 2002 
-
  -  
 
 Home > Secure View: Security Policy
 Print Friendly Page ||  Email this story

Writing an Information Security Policy

The importance of having an Information Security policy is now being acknowledged even by top management. But how do you go about writing an Information Security policy? by Avinash Kadam

In the corporate world, we are used to the presence of Corporate Policy, Human Resources Policy, Financial Policy and so on. We assume that legal luminaries, HR wizards and finance gurus must have sculpted these polices to protect and increase the company's assets. Only a few people are aware that information is as valuable an asset as the financial assets of a company and needs suitable protection. However, in this Internet era, awareness is now spreading to the upper echelons and suddenly we, the IT professionals, find ourselves facing the challenge of defining an information security policy to protect information assets. Where do we begin? How do we write the security policy statement which is binding? How do we convince people to really accept the security policy and implement it in their routine work? This article tries to lay down the guidelines for this difficult task. Needless to say that the implementation of the guidelines will be slightly different to fit each company's profile.

COMMITMENT
The right place to start the formulation of the IS (Information Security) policy is by meeting the managing director of the company. The MD may have only a hazy idea about the threats inherent in the 'open' nature of the Internet/intranet. However, he/she may not be aware of the magnitude of losses in case of a security breach of the company network. We have to spend some time in educating top management about IS. Next, we need to understand the corporate vision and business objectives and how IT fits in with corporate plans. We also need to analyze the following:

  1. What are the information assets of a company in terms of hardware and software, including network as well as the future investment plan in IT/IS.
  2. What is the company's dependence on IT in real measurable terms like financial benefits, better service to clients, improved image and market share.
  3. How much the company will suffer due to any loss, leakage or distortion of information.

This analysis should be very dispassionate and realistic. If possible, we should quantify the gains due to contribution of IT and get them ratified. We will need these figures later. Writing an IS policy is just the tip of the proverbial iceberg. The main task is implementation, where we need to spend lots of effort, time and money.

Once this data is gathered, writing the security policy is easy. First, we should prepare a security policy statement stating the real need for information security. This statement should demonstrate the strong belief that if information is not made secure, the company will suffer. The statement should have the top management's commitment and strong support for all measures that will be implemented to achieve IS objectives. In fact, the statement should become 'Orders from the top' in the long run. The security policy statement should be used as a public document to inform employees, customers and business associates, and should be treated on the same level as that of the corporate quality policy.

RISK ASSESSMENT
The next step is a risk assessment exercise. Once we understand the business' expectations from IT, we need to understand what hurdles might come in our way to fulfill those expectations. There could be a number of risks.

Business risks, physical risks, environmental risks, technological risks, human risks and so on. This exercise should be taken very seriously, though realistically. There will be a tendency to cry wolf for every assumed risk. On the other hand, we may brush aside even major risks with an optimistic assumption that this cannot happen to us. A balanced approach is needed. We should document every risk which a company may have encountered in the past, by companies in similar business, companies in the same geographical area, companies using the same technology—in short, anything that can help us identify what are the potential risks that could affect the information systems, thereby impacting the company's business.

Wherever possible, the risk assessment should be quantitative, because figures speak louder than words. We should be able to predict the actual loss the company may suffer due to non-implementation of an IS policy. Of course, everything cannot be quantified. But even the intangible, qualitative losses, could be business threatening and as such should be documented.

If we tabulate the risks and identify the probabilities and consequences of these risks, product of the probability and consequence will give us the priority level of the risk. For example, if the probability of a website getting hacked is high, and the consequences of such an event are also high, this is a high-high probability item.

To quantify this I would put it as: Probability of a website getting hacked is an annual frequency of 0.5 i.e. once in 2 years, and the business loss for each event is Rs 100 lakh. So the product of probability and consequences gives us an Annual Loss Expectancy of Rs 50 lakh (0.5 X 100).

So the end result of the risk assessment exercise will be a prioritized list of all the risks we need to face boldly.

RISK MITIGATION
Security policy is not the last and final word. It is a master plan, which identifies a company's security concerns and is the first step towards building a secure infrastructure.

Security can never be achieved through a single tier of defense. We need to have multiple layers to protect our assets. For each security risk that we have tabulated, we should identify the preventive measures that could be used to reduce the risk. The measures for risk mitigations could be:

  • Administrative measures
  • Physical Measures
  • Technical Measures

Administrative measures consists of policies, procedures, standards and guidelines; personnel screening, security awareness training.

Physical measures could be perimeter control measures, physical access control, intruder detection, fire protection, environmental monitoring.

Technical measures will include logical access control, network access controls, identification and authentication devices; data encryption.

Designing, documenting, implementing and monitoring security policies is a lot of administrative work. In fact, security is 75 percent administrative grind and only 25 percent technical efforts. Not a very glamorous affair, but essential. Policies are the preventive controls.

An ounce of prevention is better than a pound of detection and correction.

Natural and Environmental Threats:

  • Disaster recovery
  • Backup and recovery
  • WAN recovery

Database Security:

  • Network & Telecommunication Security

Human Threats:

  • Password Security & Controls
  • Internet access and security

Operating Systems Security:

  • Firewall Security
  • Data Classification
  • Web server Security
  • Intranet Security
  • Virus-Protection
  • E-commerce Security
  • Data encryption

Email security:

  • Technical controls
  • Logical Access Controls
  • Program Change Controls
  • Version Controls
  • Application Software Security

Administrative Controls:

  • Physical Security
  • Incidence Response management
  • Punitive actions

ANATOMY OF A POLICY DOCUMENT
Essentially, the objective of the policy is to convey the risk concerning information security and what preventive measures a company has adapted. The security policy has to be understood and followed by the employees. It should be brief and mater-of-fact but should cover all aspects.

Following is the suggested outline of a security policy document:
Policy Statement: Outline the objective of the policy. Emphasize the actual risks that will be addressed by this policy. Make it as near to the company's business as possible so that the reader is convinced about the necessity of the policy.

Policy Scope: Specify the areas of concern which the policy will address. This will list the organizational units, individuals and technical system covered by the policy.

Validity: Define the life-span for the policy and when it will be reviewed next. The review must be done at least once a year to keep the policy current.

Owner: Author of the policy should be a respected IS professional. This will ensure responsibility and accountability. This is even more important while drafting policies of a technical nature.

Review-details: Record of previous review and the changes therein.

Compliance requirements: Punitive actions that should be taken if the policy is not adhered to. This of course needs clearance from HR, but absence of this will make the polices 'best ignored practices' instead of 'best practices'.
Names of the appointed persons who will enforce these policies.

Policy details: After the above preamble, here is the real policy.

Specific issues that the policy is addressing: Give the background, describe the risks that have been identified, state the security expectations that the policy will fulfill.

Best practices: Give a detailed list of recommended best practices.

Mandatory practices: This is the minimum standard which has to be implemented.

Procedure for implementation: A step-by-step procedure which will be followed for implementation of the policy. There will be references to forms, templates, standards, guidelines etc. which could be given as annexure.

Monitoring and reporting mechanism to ensure proper implementation.

How the compliance will be monitored. How non-compliance will be reported and what actions would be taken.

Annexure: Forms, Templates Standards, Technical guidelines

Essential Policies: List the essential policies under various and applicable controls. (Ref to Box: Policies)

Example of a Security Policy
Let us take e-mail security policy as an example. The Policy Details section should cover the following:

  • Confidentiality of information:
  • E-mail should not be used for confidential information exchange
  • Sender will be totally responsible for the content of the information
  • No sensitive information like password, PIN, credit card details should ever be sent by e-mail

Appropriate Use:

  • Use of e-mail will be restricted for business use only
  • No obscene or profane message should be sent
  • E-mail should not be used for sending spam mail
  • E-mail should not be used to transmit chain mails, greetings, graphics etc.
  • E-mails should not be automatically forwarded to addresses outside the company
  • Size of the e-mail should be restricted within approved limits

Management Authority:

  • Management could use its right to monitor the e-mails
  • Management could store the e-mails for retrieval at a later date for any legal purpose
  • Any encryption done to e-mail attachments should be with the company's approval and the encryption key should be stored for retrieval when necessary

Disclaimer Notice: Since e-mail is not a secure medium and it is very easy to read, copy or alter an e-mail, put a disclaimer similar to the one given below. The company can at least protect itself from any misuse.

"The information in this mail is confidential and is intended solely for the addressee. Access to this mail by anyone else is unauthorized. Any copying or further distribution beyond the original recipient is not intended and may be unlawful. The opinion expressed in this mail is that of the sender and does not necessarily reflect that of the XXX company."

Implementation of Security Policies
Writing and issuing the Security Policy document is really the first step. Training the users and implementing the policy is a bigger task. You have to do this with missionary zeal. You may do one or all of the following:

  • Conduct Security Awareness Seminars, workshops, quizzes
  • Have Security Week for the organization
  • Prepare Do's & Don'ts of Security Policy, distribute and display them
  • Create posters, stickers, t-shirts, mugs, mouse pads, all with security messages
  • Run slogan competitions
  • Give wide publicity to any security breaches in (other) companies
  • And of course, perform security audits

Avinash Kadam is Chief Executive - Assurance and Training at Miel e-Security, Pvt. Ltd. He can be reached at awkadam@mielesecurity.com

 
     
- <Back to Top>-  

Copyright 2001: Indian Express Group (Mumbai, India). All rights reserved throughout the world. This entire site is compiled in Mumbai by The Business Publications Division of the Indian Express Group of Newspapers. Site managed by BPD