Network Security Policy
Network Security Policy
The organization security policy, like the vacation policy or the family leave policy, is an official company document that lays out the expectations of the organization, the processes to be implemented, and the sanctions for those that fail to comply. Without a well-defined and accepted security policy, security becomes an ad hoc process governed by the person in charge at the moment and can (at best) lack any effective usefulness to the organization or (at worse) could lead to significant losses of resources and/or opportunities.
Security policies are covered in detail in the “Site Security Handbook” (RFC 2196). The handbook document defines a security policy as “A formal statement of the rules by which people who are given access to an organization’s technology and information assets must abide.” It goes on to say that “the main purpose of a security policy is to inform users, staff, and managers of their obligatory requirements for protecting technology and information assets. The policy should specify the mechanisms through which these requirements can be met. Another purpose is to provide a baseline from which to acquire, configure, and audit computer systems and networks for compliance with the policy. Therefore, an attempt to use a set of security tools in the absence of at least an implied security policy is meaningless.”
Why Create a Network Security Policy
Any set of policies requires time and effort to produce a useful and effective tool that can be implemented and administered. Some of the benefits and purposes for taking the time to develop a well-structured policy include the following:
-
Provides a blueprint for security purchases and implementations
-
Defines technologies that can and cannot be added to the network
-
Provides the procedures to follow in case of a security incident
-
Defines which practices and behaviors are acceptable and which are not
-
Defines the sanctions for violations of the policies
-
Provides a process and targets to audit existing security
-
Defines responsibility throughout all levels of the organization for implementation, monitoring/auditing, sanctioning, funding, and supporting the policies
-
Creates a basis for an enforceable legal action
-
Provides the baseline for the next step in the evolution of the network security
The Balancing Act
An organization security policy determines how secure or insecure the network and intellectual resources are, what features or functionality is included in the network, and how easy the network resources are to access. A good security policy can only evolve after the organization clearly understands and defines its security goals. Only at that time can intelligent decisions be made about which tools to use, which technologies to allow and/or support, and what restrictions need to be defined and communicated.
Recognizing that the goals of other organizations might not be the same as yours is important. Even competitors within the same industry might have different security needs based on their perceptions, organizational structure, and even whether they are industry leaders or followers. Furthermore, the goals of an organization’s vendors—or would-be vendors—might not necessarily be the best to follow. Many network devices include default settings that allow “wide open” operation to maximize throughput and to facilitate adding new devices with little thought for overall network security. For example, notice how many vendors use the top throughput ratings for wireless systems, knowing full well that when security is incorporated, the numbers drop substantially.
A security policy is always the result of compromises and balancing between the following key tradeoffs:
-
Security versus ease-of-use
-
Security versus services provided
-
Security cost versus risk of loss
In the next sections, you will see each of these compromises and the impact each one has on the resulting security.
Security vs. Ease of Use
On the one extreme, a system with no passwords, unlimited access from anywhere, and few restrictions on user behaviors provides the easiest environment for users to work and create within. This also creates an environment where company resources and intellectual property could be easily damaged, lost, or stolen. On the other extreme, frequently changing passwords, restrictive “need to know” access, and draconian penalties for any mistakes can secure the resources at the expense of users being unable to or unwilling to do their jobs to the fullest.
A natural conflict will always exist between the users and the security requirements of an organization. Users often see any restrictions placed on them as interfering with the company’s capability to compete and be efficient. Security personnel often see users as security risks, instead of the tools of production that ultimately pay the bills. Figure 1-6 represents the balance between ease of use and network security. The same representation could also be applied to balancing services and cost versus security.
Figure 1-6: Balancing security needs with user ease of use
Security vs. Services Provided
Every service and technology provided to users carries some level of security risks. Some services, such as wireless technologies, involve risks that could be somewhat obvious. Others might involve hidden risks that go unexploited for an extended period of time. In some cases, the decision might be made that the risks outweigh the potential benefits and the service should be eliminated rather than efforts made to secure it.
Security Cost vs. Risk of Loss
This might be the most difficult comparison to make. Implementing a form of security seldom involves just the cost of acquisition, such as the purchase price of a firewall or an authentication server like TACACS+. There can be network performance implications if the new technology increases latency through a device. The new technology or policy could reduce user access or increase user effort in using the technology.
Just as identifying costs associated with implementing some security changes might be difficult, many types and levels of risk can also accrue if the service or policy isn’t implemented. The loss could include the following:
-
Loss of company data or intellectual property, such as the accidental or intentional corruption or deletion of files
-
Loss of service, such as the loss of a server from a DoS attack, the loss of data storage space because of the replication of nonbusiness files, or the loss of a web site defaced by a hacker
-
Loss of privacy, such as the copying and/or viewing of company or personnel information by unauthorized users
-
Loss of reputation, such as the company embarrassment and possible loss of business associated with the disclosure that customer files or credit card information has been accessed by outsiders
Note? I once had a client who got a call from a police department several states away informing him that his web site was hosting a porn exchange site. The officer provided the exact address and told the client to “take care of it.” The officer went on to explain that the call was a courtesy because he was convinced this was an unauthorized use of the server, but that they could just as easily have showed up with warrants and turned the whole place upside down. The site was removed. The company developed a security program, but the client was fearful for a long time that the word might somehow get out and damage his reputation within his client community.
Ultimately, each organization must evaluate its network and intellectual resources to determine the appropriate level of security needed to safeguard those resources, while still enabling the organization to meet its primary mission. This evaluation process often takes time to reach equilibrium and can be altered significantly by events such as a network intrusion or loss of a valuable resource. The lucky groups are those that can learn vicariously from the experiences of others and possibly avoid significant losses of their own.
Network Security vs. Network Operations
Many organizations separate their network security and network operations departments because their missions and pressures are somewhat different. While operations strives to make network resources available in as quick and efficient a method as possible, they might not have the time, resources, or training to analyze the security implications of all situations. Security personnel should have the resources and training to evaluate the organization’s needs, without the direct pressures of maintaining a production network. Note, I’m not saying that security personnel can ignore the pressures of running an efficient and reliable production network, only that their main objective is different.
In a perfect world, balance would be struck by having a security staff with previous production experience to better understand their peers in operations, and the operations personnel would have sufficient training and management support for security to perform their jobs effectively, while complying with the security policy.
A Security Policy Is to Be Shared
A security policy must be a formal written statement of company policy that has the full support of management and owners. A security policy must be easily disseminated to and scrutinized by users at all levels, operations staff, and managers as a set of security rules that covers all types of information technology, as well as the information stored and manipulated by that technology. To be effective, a security policy must be communicated to users in a clearly understandable form and acknowledged by them through a signed statement, indicating they have read, understand, and will abide by the policy.
Acceptable Use Policy (AUP)
An acceptable use policy (AUP) might logically be included as part of the final security policy. Because of the convergence of technologies, it’s common for AUPs to include telephone, copier, personal digital assistant (PDA), and pager, as well as fax activities. The AUP should spell out specifically what users can and cannot do on the various components that make up the network, including the type of activities and traffic allowed on the networks. The AUP should be as explicit as possible to avoid ambiguity or misunderstanding, particularly if sanctions are imposed for failure to comply. For example, an AUP might list prohibited activities like “browsing and engaging in transactions on web auction sites.” The AUP could be explained at all employee orientation sessions and signed by each user. This agreement and training should be updated periodically as a refresher and definitely any, time a significant change is made.
Unfortunately, it’s not uncommon for new employees to learn about new limitations on access to resources, such as Internet access for personal use only, to find the same information hasn’t been distributed to the existing employees. It’s particularly dysfunctional when the sanctions involved with a policy are implemented against employees who had no way of knowing they were violating a policy. Handled poorly, this can lead to mistrust, lack of support, and even refusal to use certain resources.
Network Operations and Network Security Training
Networking employees at all levels will require additional training and sign-offs on those portions of the security policy that impact their jobs, but that aren’t covered in the AUP. Again, this should be handled proactively with enough detail that each employee understands their responsibilities and the limits of their authority. No one wants to learn that the configuration file they sent to Cisco TAC for help with a problem might cost them their job as a breach of the company security policy.
Who Should Help Create the Security Policy?
For a security policy to be effective, it must have the acceptance and support of all levels of users within the organization. Especially important is that corporate management and ownership (board of directors) fully support the security policy process; otherwise, little chance exists that it will be successful. Also critical is that the resulting policy will eventually fit within the organization and its culture. In particular, a first security policy or a radical change in policy might require some transition time for people to learn and assimilate the new rules. The following people are representative of those who should typically be involved in the creation and review of security policy for a larger organization:
-
Company security administrator
-
Security incident response team representatives
-
IT technical staff representatives (network operations)
-
Administrators of organization business units
-
Representatives of the user groups
-
Responsible upper management
-
Corporate legal counsel (in some countries)
The wide variety and sizes of businesses make it impossible to define a single list. The nature of the business and the level of and types of employee contracts and bargaining units might dictate some other attendees. Just because a security policy is necessary and reasonable doesn’t set aside a company’s requirements to negotiate changes in work rules. More than one organization has been required to rehire with back pay an employee terminated under a security policy rule because it conflicted with a bargaining agreement.
Another group that should be represented is any internal auditors required by industry standards or governmental regulations. Because some policies dictate production of logs, backups, and documentation, it’s critical that those policies comply with any relevant laws, regulations, industry standards, or court orders.
If the resulting policy statements are to reach the broadest possible acceptance, the group must be an appropriate mix of involved representatives (stakeholders) that can formulate a set of rules that balance the security requirements with the technical expertise available or obtainable. These policies must have an acceptable impact on the company business model, particularly in any areas perceived to create a competitive advantage. Finally, the budget and policy authority must be present to make sure these policies are supported throughout the organization and funded adequately during both good times and bad. If done properly, the policy should yield the highest level of appropriate security in the most cost-effective manner.
Assets and Threats
Developing a security policy, as in any risk analysis, involves determining what needs to be protected, what it needs to be protected from, and how best to protect it. So the first things to do in the process are
-
Identify the assets
-
Identify the threats
The process then involves examining all possible risks, ranking those risks by level of severity, and, finally, making cost-effective decisions on what you want to protect and to what extent. It makes no sense to spend more to protect something than its actual worth.
Identifying the Assets
When identifying the assets that need to be protected, some might be obvious, like valuable proprietary information such as product blueprints or designs, intellectual property, and the many hardware components that make up the network. Others might not be so obvious, though, and are often overlooked, such as the people using the systems. While the company doesn’t own the people, it could have invested in their skills and development over the years. Similarly, the company might rely heavily on those skills to meet its business objectives. Some users might have no readily identifiable replacements within the current workforce.
The point is to list everything that could be impacted in any way by a security problem:
-
Hardware Servers, workstations, laptops, printers, scanners, FAX units, routers, switches, firewalls, intrusion detection devices, wireless access points, IP telephones, palm-sized devices, pagers, projection systems, electronic white boards, and communication lines. Don’t forget devices that might be at telecommuters’ homes, such as DSL routers, printers, and so forth. The move to combine resources like printers and copiers should be acknowledged, even if not yet implemented.
-
Software User software licenses, custom and off-the-shelf enterprise applications, virus protection software, network and workstation OSs, network device OS, network management applications, utilities of all types, diagnostic programs, and communication/FAX programs.
-
Data Financial records, business plans and strategies, customer and employee information, sales records (including credit card information), product designs and parts lists, inventories, production schedules, and customer and vendor contracts. Many of these could be parts of one or more databases, while others might be many individual documents in the system. Each type must be identified by its location during execution, where they’re stored online, where they’re archived offline, any backups, audit logs, and whether they’re ever transmitted over communication links. It isn’t uncommon to discover entire classes of strategic documents stored only on local hard drives.
-
People Users, administrators of all types, help desk people, and hardware maintenance.
-
Documentation and licenses For OSs, applications, hardware, systems, and administrative procedures. Don’t forget service agreements and warranties.
-
Supplies Paper, toner and ink cartridges, and batteries.
-
WAN and Internet services Contracts and service agreements for communications links, web hosting services, and related contracted services of any kind. Because these services could be in negotiation for some time, be sure to include any works in progress.
While not technically a network component and not appropriate for all companies, as previously mentioned, any company doing business over the Internet ought to consider its reputation and the trust relationships it’s developed as an asset. Any attack that damages this reputation could have serious implications for the future well being of that company and its stakeholders.
Identifying the Threats
Once the assets to be protected are identified, it’s necessary to identify and assess the threats to those assets. As you saw earlier in this chapter, different names and levels of detail can be applied to these security threats, but, generally, they break down to the following:
-
Reconnaissance
-
Unauthorized access
-
Data manipulation
-
Denial of service
The basic goal of security for each asset is to ensure availability, confidentiality, and integrity. Each threat should be examined to assess how it could impact the company assets. Each company can have different perceptions and assessments of the threats, which should be identified and addressed.
| STUDY TIP? |
Data manipulation is often included in unauthorized access threats, so keep that in mind if you are asked to identify only three threats. |
Evaluating a Network Security Policy
Just as the preceding section showed that different organizations can have different perceptions of threats and place different values on assets, the security policy reflects those differences. Most security studies agree that some of the key characteristics of a security policy should include the following:
-
It must be implementable through network administration technologies, by publishing rules and acceptable use policies, or other appropriate methods.
-
It must be enforceable with security tools, where appropriate, and with sanctions, where actual prevention isn’t technically or financially feasible.
-
It must clearly define the areas of responsibility for the users, administrators, and management. Maybe as important, it should clearly identify the limits of authority for each group under predictable circumstances.
Any policy that has serious deficiencies in any of these characteristics stands a better- than-good chance of failing to meet the company objectives.
What Belongs in a Network Security Policy
Each organization will develop a policy based on a variety of factors. Even after exhaustive study and development, the policies need to be updated as new technologies develop or become financially feasible. Some common components of a good security policy include the following:
-
Statement of authority and scope Who sponsors and authorizes the policy, as well as who it impacts.
-
Access policy Defines all access privileges and responsibilities to network assets by specifying acceptable use rules for users, network operations staff, and management. These policies should cover adding devices to a network, adding software to systems, modifying software and OS settings, and how and by whom external connections to the network are to be made. The policies should specify any required connect warning messages about “authorized usage and monitoring.” Parts of the access policy might become part of acceptable use policy (next).
-
Acceptable use policy Which user practices and behaviors are acceptable and which are not. This policy often includes technologies, including telephones, cell phones, pagers, copiers, fax machines, computers, access to the Internet, and so forth.
-
Privacy policy Defines what are reasonable privacy expectations regarding monitoring of e-mail and access to users’ files.
-
Remote access policy Defines how remote users and telecommuters will access the organization networks. This policy might be further broken down to cover specific technologies, such as ISDN access policy, DSL access policy, and cable modem access policy.
-
Wireless access policy Defines if and under what circumstances a wireless devices or devices can be used with the company network.
-
Antivirus policy Defines which tools will be used and how they’ll be implemented.
-
Password policy Defines what passwords will look like and how often they must be changed, and it should authorize audits of password files to ensure compliance.
-
Authentication policy A more comprehensive form of the password policy that defines a local access password policy and establishes guidelines for remote authentication processes, which might include OTPs and the devices that generate them.
-
Router and switch security policy Defines minimal security configuration for all routers and switches connecting to a production network.
-
Availability statement Defines what users can expect for resource availability. Known risks, redundancy, and recovery issues should be stated. Hours for routine maintenance downtime should be specified, as well as any notification process used before the system is taken down. Contact information for reporting system and network failures should be included.
-
Accountability policy Defines the responsibilities of users, network operations staff, and management. This should cover guidelines for routine monitoring, scheduled and unscheduled audits, and guidelines for incident handling (what to do, what not to do, and who to contact in case an intrusion is suspected).
-
IT system and network maintenance policy Defines how internal and external maintenance people are allowed to handle and access company technology. This should address if, and under what conditions, remote maintenance is allowed and how such access is controlled. If outsourcing is allowed, how it should be managed and the processes that need to be followed should be defined.
-
Violations reporting policy Defines the types of violations that must be reported and to whom the reports are made. Remember, a low-key atmosphere and even anonymous reporting can result in a greater likelihood that a suspected violation will be reported.The policy should include specific contact information for users, staff, and management for each type of policy violation. Guidelines should include how to handle outside queries about a security incident, detailing who should be responding, and defining the procedures depending on where the contact is from. There may be a different policy or contact person when working with an interested third party, law enforcement, or the media. Defines the procedures if the security incident involves information that might be considered confidential or proprietary. If appropriate, any cross-references to security procedures company policies and/or applicable laws and regulations.
Here’s an example. Recently in our area, a policeman was ordered reinstated with about a year’s full pay and benefits, plus overtime that would have been earned. While the court agreed that viewing pornography on a department laptop in a public place was a violation of the AUP in place, it disagreed with the penalty for a first violation, determining that termination was too severe. The $86,000 is probably less damaging than the harm done to the department’s reputation and credibility.
Make Time for Training and Signing Off
Once the security policy is established, reviewed as needed, and approved by the highest levels in the company, it should be clearly communicated to all users, network staff, and management. Remember, this training of the employees is the only opportunity to express the importance of the effort, the seriousness of the company commitment, and the need for their active participation. Each person should be able to retain for future reference any appropriate sections, including at least the AUP.
Having all personnel sign a statement that indicates they’ve read, understood, and agreed to abide by the policy is common practice and logical. Note, this signing is of questionable value in protecting the company resources if the policies aren’t explained or treated with respect by management. The last security policy I signed was a modified distribution list attached to a stack of papers passed around a conference table. I remember thinking that because virtually nobody read the attached document, it probably wasn’t going to modify much existing behavior.
Keep It Flexible
For a security policy to be viable over the long term, it must be as flexible as possible, allowing for growth and changes within the architecture. As much as possible, the policy should be independent from specific hardware and software because these items can be moved or removed on short notice.
The processes for updating the policies should be defined in detail to include the steps to do, the people to include, and who must sign-off on the resulting changes.
Finally, the policies must be reviewed on a regular basis to make sure they’re successfully meeting the company security needs. The policies should also be reviewed if any new major technology is added to the network to make sure the technology is covered from day one.
Example of a Network Security Policy
A security policy can take many forms and styles, but one that’s easy to get started with is a series of templates produced by the SANS Institute called “The SANS Security Policy Project,” available from their web site at http://www.sans.org/newlook/resources/policies/policies.htm.
The System Administration, Networking, and Security (SANS) Institute was established in 1989 as a cooperative research and education organization to provide a forum for security professionals, auditors, system administrators, and network administrators to share the lessons they have learned and find solutions to the challenges they face. Many SANS resources, such as news digests, research summaries, security alerts, and white papers, are free. For more information, their web site is http://www.sans.org.
One of many useful sites SANS hosts is the “SANS/FBI Top Twenty List” (http://www .sans.org/top20.htm), which summarizes the “Twenty Most Critical Internet Security Vulnerabilities.” This web site also includes step-by-step instructions and pointers to additional information useful for correcting the flaws.
The writers at SANS have produced about two dozen templates for each of the major policies to be included in a security policy. Each policy is a separate document that allows for easy addition and editing, and each follows the same style shown in the example in the upcoming sidebar.
Securing the Network
Once the security policy is approved, it’s time to make sure that any security measures specified or appropriate to the policy are properly installed and configured. The rest of this book focuses on many of those technologies. In the next chapter, beginning in the section on “Improving Network Security,” you start looking at those basic configurations that should be a part of every device configuration.
Monitoring Network Security
The security policy should specify the methods to be implemented in the routine monitoring of the network. The purpose of security monitoring is not only to observe a network attack, but also to point out potential weaknesses that could be exploited. The one thing monitoring should verify is whether the security policy is being followed.
Monitoring could be as simple as an orderly collection and review of the various log files that network devices generate as a normal part of operation. Simply viewing failed login authentications for a server can indicate attempts to break into the system or maybe just some individuals that need additional training. At the other end of the spectrum are sophisticated devices like IDS that can monitor traffic looking for patterns or signatures that would indicate something is amiss. If a potential problem is discovered, the IDS sensor can notify the IDS director management console, which can then start a process to block (shun) the attack. It could involve creating an access control list in a router or firewall specifically to block further contact from that source. IDS technology is covered in Chapter 7, and then again in Chapters 23 to 26.
Auditing Network Security
Whereas monitoring is a routine general process of watching the network for potential problems with the network security, auditing is a more specific test or series of tests on the network to determine the effectiveness of the security measures, as well as compliance with the policy and any relative regulations. Auditing, like monitoring, should be specifically defined, and allowed within the formal security policy.
The random nature of audits as compared to routine monitoring makes them useful in detecting unauthorized internal activity within the system. For this reason, audits shouldn’t become routine or scheduled. Much of their usefulness is diminished if your troublemakers can predict when an audit will occur.
Shareware tools are available on the Internet and even many operator-triggered system tests can be automated by the use of scripts. Checklists of features to audit for many technologies are available on the various security web sites. Some auditing is low tech. It can be as simple as periodically reviewing the tape backups to confirm the backup was run when scheduled, that it covered everything specified, and that the tape has a usable file. Other reasons for audits might include the following:
-
Any addition to or change to systems in the network. Has the new system or the change (upgrade) possibly brought with it some unknown problem? This shouldn’t be an optional audit.
-
Spot checks of policy compliance.
-
Regularly checking password files for compliance with the password policy.
-
Router and switch configuration compliance to make sure all appropriate security requirements are included.
Commercial auditing tools or even network intrusion tools like Cisco Secure Scanner can perform ongoing auditing, including looking for potential security holes. Some of these tools come from a variety of vendors, but might only run on certain management stations. This is one area where UNIX seems to have a clear edge.
