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 organization evolves.

• 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
    • public
    • company confidential
    • strictly confidential
• Service Availability
  • this is particularly important if particular service availability is important to organization function and/or competitiveness
    • e-commerce site
    • sales force access
• Theft of Resources
  • this can be just about anything
    • credit cards
    • information
    • 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.

The 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 unacceptable use. 
• There may also be more than one of these documents depending on the users and security zone.

 

Termination Policy:  It is very important to explicitly address computer network related issues associated with the termination of employment of users, particularly technically related users.

• All organization property must be accounted for
• Accounts need to be disabled
• Access to sensitive data and/or storage media needs to be recouped

 

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.

 

Network Connectivity 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
• architecture
• implementation
• incident response
• auditing

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
  • benchmarking
  • security architect
    • designs the environment and takes an overview
    • represents the security team to the rest of the company
    • a member of cross functional teams to keep her in touch with the  needs of the organization and the security team
  • implementer
    • 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 products
  • operations
    • run the  system on a day to day basis
    • trained by the implementer and consult with implementer
    • respond to alerts
    • deal with more typical authentication and authorization issues
    • 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 policies
    • needs awareness of other organization's approaches
  • auditor
    • internal or external
    • validates security is effective or how it is ineffective
  • incident response team
    • acts when security threat is deemed sufficient
    • 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 determine this
    • who should be prosecuted?
    • what should be prosecuted?
  • disconnection policy
    • when do you sever connectivity?
    • what types of disconnections should be implemented?
    • what are the implications of each particular disconnection?
  • communication policy
    • what should be communicated within and outside the organization?
• 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 business/organization developments
  • 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 new developments
    • need to know about new projects impacting security
  • need field office people
    • most likely to use remote access
    • likely to be doing a lot of the actual customer contact
• Sell Security Effectively
  • make sure to emphasize benefits
  • may be able to market benefits
  • assess costs if do not implement particular security mechanisms
  • demonstrate how security helps organization perform
  • benchmark
  • gather data on effectiveness
  • ensure the implementations are workable and practicable