Once you've completed your security policy document, it's time to translate it from human readable form into the various configurations that will actually implement the policy.
Implementation varies from one system to the next. A policy of 'Strip e-mail attachments on all mail servers' is implemented far differently in UNIX Sendmail, Microsoft Exchange, or Lotus Notes. Your policies should not be written specifically to certain systems; they should be general statements that apply to any system that performs the specified function.
Implementation occurs when a security policy is applied to a specific system. But nothing in your policy will help you select which systems to use to implement the policy. A requirement that 'Permissions can be used to block access to certain documents' does not stipulate
Windows 2000, UNIX, or the Mac OS X systems-they can all perform this function. It does eliminate the choice of Windows 98, MS-DOS, or the original Mac OS, because they have no true permissions infrastructure. In order to select systems that match your security policy requirements, make a complete list of possible systems and eliminate those systems that cannot implement your security requirements. Select the systems that can implement your security requirements most easily from the remaining candidates.
Of course, this only works in the theoretical world where security requirements are defined before systems are built, rather than after hackers exploit systems in a major way and reveal the lack of security. When you are retrofitting security policy, be prepared for the fact that some of your systems and software may have to be replaced in order to achieve real security.
Applying Automated Policy
The method you'll use to apply automated policy differs for each system in your network. On firewalls, you'll use a web browser or an 'enterprise manager' application. In Windows 2000, you'll modify group policy objects in the Active Directory. In Linux, you'll directly edit text files in the /etc directory. You may change the startup type of a service or remove operating system components that provide unnecessary services. You may block certain port ranges on your firewall, or allow only approved outbound connections.
There is no standardized way to apply an automated policy. A few attempts have been made at automating policy by various vendors, but the lack of consensus and protocol keeps that from happening.
So what is a security administrator to do? That's the hard part. You have to individually learn and understand the security interface for each type of system in your network. Typically, this will mean understanding the interface for every operating system in use in your network and each security-related device. This is the major reason why consolidating on a single operating system is a good idea.
Most modern operating systems have graphical user interfaces that combine security
configuration management into some sort of unified view. In Windows 2000, this is called the group policy manager. In most firewalls, it's either a web-based user interface or a program that runs on an administrator's computer. The remainder of this book contains details for applying automated policy, but for the most part, the technical manuals for your various systems will teach you how to apply their specific security policies.
Human Security
After everything that can be automated has been automated, humans must implement any parts of the security policy that are left over. They are therefore an integral and necessary component of computer security.
People are the most likely breach in any security environment, including secure networks. Most breaches are completely accidental; few people actually set out to sabotage network security. In fact, most people never find out that they've compromised the network's security. Hackers routinely exploit weaknesses in network security caused by this lack of awareness among users.
For example, humans select memorable passwords by nature, and then write them down on post-it notes so they don't forget them. Employees are sometimes enticed to provide
information for favors, money, or higher paying jobs. Traveling sales people can leave your office and head for the office of your competition with interesting tidbits of information to trade.
Of course it is not the intent of this chapter to leave you feeling that your co-workers and business associates cannot be trusted. The vast majority of them can, but it takes only one individual in your entire organization with access to your network to compromise its security. Unfortunately, this means that security restrictions must be applied to everyone because you don't know who is going to slip up in the future.
People cause security problems because they:
Don't understand security. Security is not an instinct-it must be taught. You cannot simply tell people to choose strong passwords and expect to have an impenetrable fortress. You must teach security to every person who participates in a secure environment.
Underestimate the threat. Many people simply don't believe that much of a problem really exists. They've never met or known anyone affected by a hacker, and they've never seen a disgruntled worker cause serious problems. For them, security is an abstraction that simply isn't all that important. As a security manager, your job is to explain the threat clearly. This is getting easier, as most people have been affected by a computer virus at least once.
Fail to make security a work habit. Many people simply don't change easily. They have old habits-and old passwords. Habitual security is hard to force, so make it as simple for users as possible by implementing automated policies that don't rely on people to remember security; have the policies be enforced by the network and by the work environment.
Forget about security outside the work environment. Many people leave their work at work-and their security habits too. They may take an employee list home and throw it in their trash. They may brag to a recent acquaintance about the importance of their job. They may write down their password on a sticky note and leave it in their daytimer. These sorts of problems can only be dealt with by reminding people to leave work completely at work-don't talk about it except in vague references and don't transfer company materials between work and home. Remind them never to re-use their work password or account name on other systems, like membership websites.
Passively resist security measures. Many people see security as an abridgement of their personal liberty and freedoms or as an indication that they are not trusted. Remind them that they are free to live their lives as they please when they are not at work, but that as an employee they have a responsibility to safeguard the company's proprietary information. Explain that security policies by nature must deal with the lowest common denominator of trust, and that security should not be viewed as an insult to any single individual.
Human security is problematic because it is the only aspect of total network security not directly controlled by the information system staff. Unlike computers, your co-workers cannot simply be programmed with a strong security policy and let run. They must be taught,
reminded, and encouraged.
Security managers are often given the responsibility to enforce security policy without being given the authority to enforce security on end users. You probably won't be able to fire anyone for a major security breach, you can't dock his or her pay, and you may not even be able to write an administrative letter of reprimand. Without some form of force, the concept enforcement is meaningless.
Fortunately, humans are gregarious creatures and respond well to group opinion. This means that for serious security breaches, you can use publicity both to embarrass the people at fault and to teach everyone else what not to do. Publicize security failures within the company as part of a lessons learned document, usually in the form of an e-mail message to everyone in the company. Whether or not you identify people by name is up to you and probably depends largely on company policy and the severity of the breach (and even if you don't name them, the buzz around the water cooler will). Each lesson learned should be appended to your security policy for further analysis so these breaches can be prevented in the future. lessons learned
A documented failure analysis that is disseminated to system users in order to prevent the same failure from recurring.