SAN FRANCISCO (01/12/2004) - The first thing to understand about IT security is that technology alone can't save you. It's tempting to think that a fabulous new product, whether hardware or software, will come to the rescue, solving security problems while leaving users happy and productive.
Unfortunately, the best security products can only implement the policies and procedures put into place and enforced by administrators. These policies and procedures provide the greater part of security for any IT resource. Indeed, the greatest amount of security administrators' time and effort goes into developing, implementing, and enforcing policies and procedures.
When securing a government system, policies and procedures must also meet the rigors of rules, regulations, and laws. In many cases, there may be several regulations that have authority over a given set of systems and networks. Federal and state government administrators typically work within established systems of regulations, whereas local and county administrators often must address security concerns within a less explicit regulatory framework.
Newer law enforcement regulations, such as recent Homeland Security requirements, further complicate matters by specifying how systems that connect to government networks and services must be protected. Fortunately, most legal restrictions address common-sense issues that you can and should apply to most systems -- governmental or otherwise.
To improve information security within any organization, you must begin by understanding the systems you're protecting and the risks your systems face. Only then can you form a meaningful plan for securing those systems against those risks. A successful security plan calls for thorough documentation and should include the means for constant reassessment of its effectiveness.
The steps toward a successful plan are outlined below. Working through each of these steps within the parameters of the relevant governmental regulations allows agencies to comply with the letter of the law, while using those laws as the basis of genuine security.
Know the Systems and Threats
The first step in developing any security strategy is defining precisely what it is that you're securing. Although this may sound easy, it means far more than a simple inventory of equipment.
Begin by determining the real limits of the particular system you're looking at. Systems consist of a configuration of physical components, software, data, communications facilities, and business processes that are all under the control of a single direct manager or management function and that all serve the same general function. Defining the components within a given system can be a valuable exercise on its own, because many administrators don't fully understand just how many devices, programs, and processes make up the systems they control.
It's important to note that multiple computers don't have to be connected to one another -- or to anything else -- to be a system. For example, field agents have individual laptop computers; each team member's laptop fulfills the same organizational purpose as every other; and all are under the control of one authority. For security purposes, the group of laptop computers should be considered a system.
A security plan must also consider components of the system that might be shared with other departments or agencies. Multiple departments within a single government facility, for example, may use a single central WAN component. The architecture of the network might or might not allow a given department to have control over the infrastructure of the WAN. If there is no direct infrastructure control, then the security definition of the system would end at the demarcation point between LAN and WAN.
Once you understand the nature of the system you're protecting, you can better assess who and what may threaten the system. First, decide which components of the system you need to protect. This important step forces administrators to look at the value each component adds to the mission of the agency or department. The information stored within the system, the physical infrastructure of the system, the software, and the human resources of the system should all be considered in light of the three basic types of threats: those that deny availability to the system, those that damage the reliability of the system, and those that compromise the secrecy or privacy of the system.
Systems can be rendered unavailable by any number of means, ranging from network DDoS (distributed denial of service) attacks, to physical attacks on the system through bombs or power disruptions, to accidental system trauma caused by storms or floods. System reliability is compromised when data is altered without authorization or when components are damaged in ways that hinder their capability of delivering correct information. And systems are not secure when unauthorized individuals are able to access information that must remain secret for either government or personal privacy reasons.
Each type of threat becomes real through the exploitation of a particular system vulnerability, which may be either physical or logical points at which systems can be damaged. In addition to physical security checks, thorough scans of network, operating system, and application vulnerabilities should be carried out using software such as the open source Nessus.
As vulnerabilities are discovered and cataloged, administrators must analyze the risk of the vulnerability being exploited. The obvious, most secure strategy is to lean on a worst-case analysis. But administrators should balance a worst-case scenario with answers to three pivotal risk-assessment questions: How valuable is the particular asset? What damage would result to the organization if the asset were compromised or destroyed? Realistically, how likely will the vulnerability be exploited?
Decide What You're Going to Do
After your catalog of risks is complete, start taking steps to remedy vulnerabilities and develop countermeasures for attacks. To be successful, such remediation and countermeasure programs must make sure that all software and firmware in the system has been brought up to current version and patch levels. If system components were identified thoroughly, you should already have a baseline system status against which upgrades and patches can be applied. As patches and upgrades are performed, a change-management system should be implemented to log all changes and give administrators a secondary source of notification when an intruder succeeds in getting past existing security.
The National Institute for Standards and Testing (NIST) publishes a number of Special Publications that may be helpful when designing a security procedure, such as the "Guide to Developing Security Plans for Information Technology Systems" (SP 800-18). Another document, "Security Self-Assessment Guide for Information Technology Systems" (SP 800-26), helps administrators assure that their security plans meet federal regulations -- and, therefore, many state and local requirements as well. This document provides templates for assessing current status and developing plans for deployment in 17 key areas, from contingency planning through training and education.
In fact, training and education often get short shrift in security planning and program development. But as the requirements for security grow more critical and specific, the need for effective staff participation grows apace. Staff members must be made aware of their role in security. They must also be trained in the proper, secure use of the system with its new security processes and technology in place; and they must be made aware of the consequences of not adhering to proper security procedures when they use the system.
Document What You're Doing
Documentation is the foundation of a thousand dumb jokes about government bureaucracy, but it's also the foundation of an effective and systematically deployed security plan. The NIST Special Publications contain rules and templates for effective documentation; regardless of the format used, there are key issues that must be addressed.
Most importantly, existing system configuration must be well documented. Many network and server attacks operate by making surreptitious changes to application or operating system configurations. A detailed, comprehensive record of system configuration and a solid procedure for managing documentation changes that accompany authorized changes in configuration are critical tools for detecting and remediating the damage from such attacks.
Many federal government systems require documentation for security accreditation of governmental systems and systems that connect to federal systems. In these cases, documentation must conform to regulatory standards, but the standards tend to require that similar issues be dealt with across regulations. Documentation must define the system; its assets, vulnerabilities, and risks; and the process for establishing vulnerability remediation and attack countermeasures. It must also describe the implementation of the security process, assessment of the security system, and the procedures for ongoing evaluation and security updates. Documentation that includes these items in clear, unambiguous language will be an asset to security, not just a large stack of ignored paper. Documentation that is correctly modified to reflect the actual state of the system as it grows and changes is critical to any realistic security plans.
Implement the Plan
Implementation is the stage at which many people begin to think of best practices. Although we've seen that there are many points in the discovery, planning, and documentation phases where best practices can be usefully applied, certainly, implementation is where best practices become critical. As security is deployed around the system, keep the following issues in mind.
Don't forget physical security. When systems are left unguarded with superuser sessions live, no amount of strong-password policy can stop someone from using the keyboard to inflict damage. Systems with access to root or superuser privileges should be located in secure areas. Superuser sessions should have time-out parameters set as short as possible to avoid unguarded sessions.
Enforce secure passwords. Keep passwords long, strong, and changing. Policies should require that passwords be at least six characters long, use words that can't be found in dictionaries, and use strings that contain both letters and numbers. Force users to change passwords on a regular basis. None of these moves is likely to be popular with users, who love easy-to-remember passwords that never change, but they are necessary for keeping a system secure.
Build solid backup and recovery processes. No matter how good your security plan, it should never be considered foolproof. Make sure that your backup procedures safeguard all crucial data modifications and transactions and that your recovery process minimizes the impact of even the most severe system breakdown.
Know your users. If possible, restrict access to the system to computers with specific, known IP addresses. If users must log in from remote systems, use the strongest restriction and authentication schemes possible. For legitimate users, make sure that accounts are not given more privileges than necessary. Be on guard for "identity creep," the easy habit of giving users additional privileges for new responsibilities while never revoking privileges that have become obsolete.
Train your users. Make sure that each user knows security procedures and understands how to follow secure computing practices. Give each user a solid understanding of consequences, both to the individual and the organization, if security policies are not followed. Make IT security training part of each new employee's orientation as he or she begins work.
Train yourself. Don't allow your knowledge of your systems and their vulnerabilities to become less current than the knowledge of those who would attack your systems. Keep up to date on revisions and patches to your applications, operating systems, and infrastructure firmware, and make sure you know which must be applied to your systems and which can be left until the next comprehensive update.
Evaluate What You Do
Creating and implementing a security plan can be a huge undertaking, leading those involved to treat it as a one-time, "set it and forget it" activity. Unfortunately, security is an ongoing process that requires regular reassessment and a strong set of policies and procedures for managing and documenting changes to the system. Security certification requires a documented set of reassessment procedures, in which newly recognized vulnerabilities are probed and verified. Common sense requires that all changes to the system -- from patches of individual workstations to upgrades of server operating systems -- be fully documented, with notation made of all files changed. It is not easy to keep up with all the changes made to a large and complex system, but it is far easier to create and maintain a secure system than to clean up after a disastrous attack.
Best practices are easily defined and documented, but no security practice, no matter how well designed and implemented, will keep a system secure if the users and administrators do not make security a priority. Technology changes to tools that can be used to compromise a system will always run ahead of products designed to protect systems; only well-trained users who understand the importance of every security procedure will be able to maintain the integrity and security of information and resources in the face of constantly evolving threats.