|
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:
-
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.
-
What is the company's dependence on IT in real measurable
terms like financial benefits, better service to clients,
improved image and market share.
-
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
technologyin 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
|