There is much more to security than
firewalls, authentication schemes and intrusion detection. Security
administrators need to be developing policies to handle a large variety of
issues. As usual, approaches that are effective and simple have far
more potential than approaches that quickly become complicated. It
is important to have places to catch undesirable system and network
interactions all throughout the system, rather than just bolted on at the
end. Can all of these goals actually be fulfilled?
One perspective is that the more security you want the less
convenient it will be. Unfortunately, depending on the approaches
used this can definitely be the case. While a certain amount of
inconvenience is likely to be inevitable, hopefully the underlying designs
will have been implemented and improved and still be in a state of
improvement so that inconvenience is greatly diminished. For
example, a single login to the network with appropriate attributes
set for other resources maximizes security in many ways and greatly
reduces more specialized tracking and logins.
The Right Questions?
What are the main questions you need to be considering when implementing a
successful security policy? At a very general level these are likely
to be the following.
- What are you trying to protect?
- From whom are you trying to protect it?
- What are the risks?
- What is it worth to the organization?
These questions need to be asked and answered very
openly. Their answers must be documented and evolve as the
- Protecting Assets
- information is usually one of the main assets
to be considered in information security
- classifying the information is important to
determining the level of security
- company confidential
- strictly confidential
- Service Availability
- this is particularly important if particular
service availability is important to organization function and/or
- e-commerce site
- sales force access
- Theft of Resources
- this can be just about anything
- credit cards
- computing time
Document the Policies.
Policies are the foundation that a security team must rely on for its
decision making. These policies need to be made by higher levels of
management in conjunction with sys admins, security specialists, the legal
department and all others concerned. For example, sys admins should
not be deciding whether or not to prosecute intruders and what sort of
evidence they should be gathering to best support prosecution. They
should also not be making the decisions about how much to monitor things
like e-mail and particular computer services.
following list, mostly from Limoncelli, represents a pretty reasonable
summary of typical sorts of policies.
Acceptable Use Policy:
This describes who are the legitimate users of the computer and network
systems and how they are permitted to use these resources.
Legitimate users are required to sign a copy of this document.
- It may also include some explicit examples of
- There may also be more than one of these
documents depending on the users and security zone.
Monitoring and Privacy
Policy: This describes the organization's
monitoring of their systems and networks. Some forms of
monitoring may be considered an invasion of privacy so this policy
should explicitly state expectations about privacy. Individual
users must be expected to read and sign a copy of this document.
Remote Access Policy:
This should explain the risks associated with
unauthorized people gaining access to the network. It should
also describe precautions for authenticating valid users.
- pass phrases
- PIN - personal identification numbers
- smart cards
It also needs to provide a way to report lost or stolen
access tokens so they can be disabled quickly through which people can be
identified over the phone. Everyone should read and sign a copy of
this policy before being granted remote access.
Policy: This relates to how the organization sets
up network connections to external entities or shared resources.
This policy should be distributed thoroughly among the
organization's decision makers and they should be forewarned to
involve the security team as early as possible when getting
involved in such third party connectivity.
Log Retention Policy:
This describes what is logged and for how long. These are
essential for tracking security incidents after the event.
Unfortunately, they take up large amounts of space when
accumulated over time. It is also important to know whether
logs for particular dates still exist is subpoenaed for criminal
cases. This policy may also address how to best reduce logs.
It is always very important to make certain the
security team and these policies have high level management
support. These high levels must also be involved in setting
up the policies. The sys admins and technical people on the
security team need to make sure they can clearly explain
possibilities, risks and benefits to these decision makers.
It may be the case that the technical people
disagree with the policies and decisions made about them. It
is important that these technical people try to understand the
business contexts in which these decisions were made.
Ideally, there should be a security officer at a high level of
management who is not part of the IT division of the organization.
This person should have skills both in business decision making
and the more technical aspects of information protection.
It is practically essential that there be some sort
of centralized authority for
decisions that relate to security. This includes
- business decision making
- policy making
- incident response
If the organization feels that certain units should have
greater autonomy then so be it. But the policies for each of these
units should be clearly demarcated and how they interconnect with other
units needs to be clearly specified.
Management and Organizational Issues.
Now we want to address how and where the security team needs management
support. The security team can help with coordinating the technical
expertise and particularly the sys admins. But there need to be a
variety of other infrastructure features in order to really get the
security policy as realistic and functional as possible.
- Resources - People and Things
- a budget
- security architect
- designs the environment and takes an overview
- represents the security team to the rest of
- a member of cross functional teams to keep
her in touch with the needs of the organization and the
- implements the architect's designs
- needs to interact with the architect to
impact reality of designs
- a member of some cross functional teams
- diagnose and examine alternatives
- trains other technical staff
- a level of escalation for interventions
- examines future directions, technology and
- run the system on a day to day
- trained by the implementer and consult
- respond to alerts
- deal with more typical authentication and
- people that the rest of the sys admins
typically interact with
- policy writer
- needs key contacts
- part of cross functional teams with
managers, legal department and human resources
- can/should be a champion for security
- needs awareness of other organization's
- internal or external
- validates security is effective or
how it is ineffective
- incident response team
- acts when security threat is deemed
- have other more typical roles
within the organization
- Incident Response
- establish process for dealing with security
incidents above a particular magnitude
- ensure sufficient advanced preparation
- impact level of incident
- more usual/typical problems should be dealt with
in more standard problem solving modes
- someone who receives reports needs to be able to
determine when incident response team should be called in
- response policy must be developed
- what do you respond to and at what level?
- what should the nature of the response be?
- how public should these efforts be?
- prosecution policy must be developed
- upper management and legal department should
- who should be prosecuted?
- what should be prosecuted?
- disconnection policy
- when do you sever connectivity?
- what types of disconnections should be
- what are the implications of each particular
- communication policy
- what should be communicated within and outside
- External Audits
- often very important to have someone from the
outside with appropriate expertise to audit and challenge efforts
- not involved in actual implementation but should
impact overall implementation through what they assess/expose
- doesn't replace internal auditing
- need to make very insistent challenges to the
security system to test its effectiveness
- Cross Functional Teams
- need to be totally current on
- keep in touch with key players
- need a strong relationship with most sys admins
- need to be aware of working models and how they
should impact security
- need legal people
- intellectual property and its protection
- assist with legal aspects
- need system administrators
- need product developers
- need to stay ahead of security requirements for
- need to know about new projects impacting
- need field office people
- most likely to use remote access
- likely to be doing a lot of the actual customer
- Sell Security Effectively
- make sure to emphasize benefits
- may be able to market benefits
- assess costs if do not implement particular
- demonstrate how security helps organization
- gather data on effectiveness
- ensure the implementations are workable and