Chapter 10. Essential Elements of Security Policy Development

Security policies ensure that effective security measures are implemented correctly and consistently across an organization. Security policies determine which hard, soft, tangible, and intangible assets need to be protected—and how to protect them.

They further ensure that monies invested in equipment and training personnel are properly used and aptly deployed.

Effective security policy formulation provides a comprehensive framework that employees can use to reduce inadvertent errors that could compromise a system. The establishment of rules can aid organizations in their attempt to protect against poor software configuration, weak password formation, careless users, inadequate system monitoring, unapplied patches, and a raft of other similarly harmful conditions. In addition, security policies can be very effective when paired with business continuity, or continuity of operations (CoOP), plans. These policies can be used to address an array of potential issues ranging from security threats to natural disasters.

Effective security should act as a business enabler, allowing a corporation to pursue its mandate in a secure environment. When formulating security policies, it is important to acknowledge that organizations, even those operating in the same field, are rarely alike. Structure, network, risk tolerance, and general approach to commerce always differ markedly, necessitating the construction of unique procedures for every firm.

All policies, whether they govern security or direct an accounting process, need to represent the natural flow of work rather than attempt to direct it. If a policy is overly restrictive, it can become counterintuitive, as users blatantly work around the policy to perform functions as they see fit.

This chapter considers the following topics:

• Determining required policies

• Constructing reliable and sound policies

• Using policy tools and policy implementation considerations

• Performing comprehensive monitoring

• Knowing policy types

• Handling incidents

Determining Required Policies

While the type of business an organization is engaged in can influence its required security posture, the equipment it uses is typically the determining factor that governs policy content. An organization that is solely hard-wired throughout its operation, and does not allow remote access, can find policy formulation to be relatively straightforward. Organizations that are using some form of wireless technology, along with remote access, VPNs, DMZ servers, and a variety of associated equipment, need wider-ranging policies to address each specific technology and major appliance.

When developing policies, efficiency can be gained by incorporating future system expansion into existing procedures. For example, if a company does not currently use VPNs but is considering implementing them within the next 24 months, including a generic policy on VPNs might avoid having to return to the task of policy formulation after new equipment is installed.

Whether policy is developed for existing equipment or the organization has integrated its future expansion plans into current procedures, developing separate policies for major equipment is the most comprehensive way to protect the organization. Every piece of equipment is unique; certain appliances allow users specific access, while others keep users at bay. Regardless of the device or process function, determining procedures for each device or process ensures that parameters are respected and rules enforced.

Constructing Reliable and Sound Policies

Policies should be a logical representation of practices that are inherent in an organization. They should also hold users to a high standard, ensuring that company property and resources are appropriately respected. Policies should consider the following areas:

• Reliability

• Access

• Constancy

• Answerability

Reliability

Policies should provide reliability, ensuring that, as an example, no person or equipment can tamper with a database. Individuals must be able to trust data that is sent or presented and not have to question its reliability. Alternately, when examining a bank balance, the reader must be assured that the data reflected on a ledger is wholly accurate and not be concerned that 0s might have been added or deleted.

Reliability dictates a process whereby users can be assured of content.

Access

Controlling access ensures that only those users specifically authorized for certain functions can access them. It also ensures that data is protected during transmission and that it cannot be read or manipulated while en route.

When data is received at its destination, access ensures that it can only be read or accessed by the authorized recipient.

Constancy

Constancy ensures that data is available when it is needed. Should a system be brought down by a security threat, constancy ensures both backup reliability and data integrity. For example, if a primary server were to fail, a secondary server would step in immediately and resume service, without concern for loss of data or databases.

Answerability

Log analyses must be maintained and checked regularly to uncover irregularities as early as possible. While it can be an enormous task to manually check logs, systems can be programmed to highlight significant events, such as file deletions or modifications, resulting in users being accountable for the actions they take. It also ensures that a system administrator can be quickly directed to examine a potential problem area.

Answerability ensures that a system can do the following:

• Point to the user or PC that accessed a file

• Pinpoint the time of day the target was accessed

• Detail any actions that might have been carried out

Using Policy Tools and Policy Implementation Considerations

Tools are available on the market that can aid in policy formulation. Equally fundamental is proper implementation of new policies. This section considers the following topics:

• Useful policy tools

• Policy implementation

Useful Policy Tools

It is always beneficial to deconstruct an organization to get a thorough understanding of what might be required to protect both its equipment and personnel.

The advent of user-friendly policy development tools can aid organizations in the development of security polices, or the tools can simply serve as a basis for discussion, ensuring that a security committee has not overlooked significant areas. While a number of such tools are available on the market, one example is Information Security Policies Made Easy (http://www.informationshield.com/ispmemain.htm). The tools can prompt the policy formulators to describe the company network in the following terms:

• State the number of users

• State the type of equipment currently residing on the network

• Describe the password process in place

• State whether the company has a DMZ server

• List remote offices or other remote users

• State the type of remote access currently used, such as VPN

• State whether wireless technology is being used

• List external connections to partners

• State whether the company is using IP telephony

• Determine further pertinent questions to ascertain the current situation

After questions are answered, policies appropriate to the organization’s current posture are presented. The policies can be implemented, or a security steering committee could use them as tools to initiate pertinent discussion among committee members.

Policy Implementation

If a policy reflects a new technology, sufficient training must be conducted prior to implementation. For example, if a VPN is being installed, users require effective training prior to installation to avoid unnecessary downtime. Relevant IT staff must be pretrained as well.

Prior to a policy being formalized, offline testing should ensure that it fully addresses the situation for which it was created. White-hat hackers, which are independent auditors trained to look for vulnerabilities, can be used to perform an assessment of the test environment. They create a situation and then record how the process played out, asking the following questions:

• Did IT discover the white-hat hacking?

• How long did it take IT to realize the system was under attack?

• How far into the system did the white-hat hackers get before being noticed?

• Were the security holes plugged?

A report can quickly summarize areas that need to be addressed. For example, if certain staff members were not immediately notified of an attack, the report might highlight a number of potential issues, as follows:

• A file containing pertinent names and phone numbers is not readily available.

• CD-ROMs with OSs and patches are not readily available.

• Pertinent staff are not comfortable with the battle stations they are expected to assume when in crisis mode.

These items can be quickly remedied, but sometimes they need to be highlighted and rectified before wide-scale implementation.

The following additional processes are worth considering when developing policies:

• Maintain checks and balances—For example, the individual responsible for unearthing irregularities in logs should not also have access, or modification rights, to data-sensitive files such as payroll, R&D, or finance.

• Limit access—Users should not be granted any greater system or physical access than necessary to perform their jobs. Access should be granted on an as-needed basis and should be revoked when no longer required.

• Keep users abreast of changes—If a new policy is implemented, but users are not fully informed, issues could result. For example, if a new policy states that passwords must change every 30 days but users are not informed, they will log on the 31st day and be unable to access their accounts without creating a new password. With notice, and an explanation of the policy, users can become active participants in the process, ensuring that they construct secure passwords as scheduled.
As another example, a new policy might dictate that backup tapes are stored by a third party, and through formal negotiation, it has been arranged that the tapes will be collected every morning at 9 a.m. But if reception personnel are not duly informed, they are unlikely to release the tapes to a courier.

Performing Comprehensive Monitoring

Security policies need to reflect the confidential nature of data and databases, along with ensuring protected access to networks and equipment. Security could be as simple as requiring a password for specific database access, or it could require two-factor authentication to use certain equipment, as described in Chapter 3, "Security Technology and Related Equipment.” Regardless of the methods used, a consistent monitoring process must be established and reviewed on a continual basis, to ensure that any new equipment or measure is incorporated into procedures without delay.

The following list represents examples of key areas that can be monitored but is not meant to represent an exhaustive listing:

• Internet access control—Users can visit sites that can spell trouble for an organization. Alternately, the Internet can act as a magnet, diverting users’ attention from their primary work responsibilities. URL filtering, as described in Chapter 3, can be used to restrict Internet access.

• Encryption use for mobile employees—Laptop-equipped users should ensure that stored data is encrypted, to protect the company against data theft.

• Comprehensive virus scans—Virus scans must be performed on all pertinent equipment, including CD-ROMs, DVDs, floppy disks, e-mail, USB keys, and so on.

• Password sanctity—Passwords should not only be highly protected, but they should also be changed regularly, preferably at the forced prompting of a system. They should also contain at least six characters, which can include any combination of numbers and letters. Passwords are expanded upon in the "Password Creation" Tech Tip, later in this chapter.

• Software and hardware installation—Software or hardware installation on workstations, laptops, servers, and other equipment should only be performed by IT staff, by IT-sanctioned employees, or by using fully automated installation tools distributed by the IT department. Because remote offices might require immediate attention, assigning one individual from every department to act as an IT advocate should ensure that users do not try to circumvent this policy.

• Software authorization and licenses—Only authorized and licensed software can be installed on company equipment. This policy ensures that copyrights are respected and unwanted software is not loaded onto networks. Similar to the previous point, software can only be loaded by IT personnel or their sanctioned advocates.

• Physical security—Physical security of equipment should conform to insurance requirements and user common sense. When traveling, equipment should be locked in a hotel room safe, placed in a locked suitcase, secured with a steel cable, stored in the trunk of a vehicle, or when in doubt, be carried.

• Comprehensive backup data handling—To avoid loss of data, systems should be backed up regularly and their tapes stored off-site, preferably in geographically secure locations. Third-party organizations can provide pickup and storage services.

Knowing Policy Types

Every major appliance and process should ideally have a dedicated policy. The following list is provided as an example of the types of policies an organization might have and an abbreviated accounting of what they might contain:

• Physical security policies

• Access-control policies

• Dialup and analog policies

• Remote-access policies

• Remote configuration policies

• VPN and encryption policies

• Network policies

• Data sensitivity, retention, and ethics policies

• Software policies

Physical Security Policies

These policies cover both perimeter and equipment, ensuring that physical access is limited to authorized persons.

While traveling has been discussed in both this chapter and in Chapter 5, "Policy, Personnel, and Equipment as Security Enablers,” it is worthwhile to note that user common sense should ultimately prevail. When a remote user travels to the head office, as an example, equipment such as laptops should not be left unattended unless secured in a locked meeting room. When flying, laptops should always be regarded as carry-on luggage, and when parking an automobile, if the user is unsure about leaving a laptop bag in the vehicle’s trunk, it should be carried with the user.

Perimeter security includes alarms on doors and windows, controlled parking facilities, fenced property, and similar types of physical deterrents. Certain hotels and prominent office towers have instituted preparking authorization. Security personnel stop users on their way into a parking facility and confirm that the driver is a registered guest of the hotel or an expected visitor to an office tower. After the visitor is approved, she can park her vehicle.

Server rooms should be locked at all times, and access to the room must be severely restricted. If a company’s offices are located within an office building, the server room should be established within the office premises. If communications facilities and wiring closets are not housed within the server room, they should be treated in a similar fashion.

Access-Control Policies

Passwords are a fundamental component of access control. Encouraging users to develop passwords that are creative, thoughtful, and difficult to predict can aid in fortifying a network.

System-level passwords are typically found on administrator accounts, such as those required to configure routers. These passwords should be changed at least quarterly, although the ideal situation would be every 30 days.

User-level passwords, such as those found on desktop computers, e-mails, web access, and databases should be changed at least quarterly. But similar to system-level passwords, they are ideally changed every 30 days.

Password distribution is critical to security. It is the responsibility of each user to safely guard his or her password. But before users can be prompted to enter a password, equipment must be delivered and installed, and users must log on for the first time. At times, an initial logon password, assigned by IT when new equipment is issued to remote offices, can represent the weakest link. The initial password might be too easy to deduce: It can often be as basic as a user’s name or even the month a unit was shipped to the remote office. A seemingly simple task can ultimately pose a great challenge, particularly because it is ill-advised to e-mail new passwords or to use other electronic methods for communicating them. It would be similar to leaving house keys and alarm shutoff information in full view for anyone to see; the aim of home security is to safeguard private codes so that they cannot be used for unlawful and unauthorized entry. Ensuring that passwords or password distribution is not compromised can take certain effort, and organizations that can implement an effective process to disseminate passwords can potentially avoid creating one of the weakest links in the security chain.

Dialup and Analog Policies

Remote access for users should be viewed as an exception rather than a rule. While many users require remote logon capabilities, most employees do not need this type of access; it should only be granted on an as-needed basis. Reminding users that remote access can render an organization vulnerable can serve to make users far more diligent when accessing a network.

Organizations should restrict the amount of time and the type of users who are granted remote access. After access is granted, activity should be routinely checked to ensure that continued access is required. Periodic activity monitoring would also ensure that inappropriate third parties do not gain system access.

This section considers the following topics:

• War dialers

• One-time passwords

• Outgoing traffic monitoring

• Fax line use

• Dialup workstations

• Inbound dialing

• Password storing

• Strong authentication

War Dialers

War dialers are hackers who are external to a company. They use analog telephone lines in an attempt to connect to a system that has an attached modem. Automated programs continuously dial numbers until a potential target is found; when the telephone is answered, the modem-handshake signal is heard. It typically takes two to three rings before call display features reveals a caller’s ID, so war dialers preset their systems to disconnect if the target has not picked up by the second ring. By disconnecting early, a hacker hopes to evade a log analysis that would reveal his identity. Alternatively, a hacker might use a caller ID block that would prevent his identity from being revealed.

A plausible protection remedy is to configure a modem so that it does not answer until the fourth ring. But this also requires that users be effectively trained, ensuring that all parties understand that the latency being built into the system is for security purposes.

One-Time Passwords

One-time passwords (OTPs) are covered extensively in Chapter 3. Establishing a rotation of OTPs can help to ensure that access is limited to authorized users.

Outgoing Traffic Monitoring

A system that logs or monitors outgoing traffic can reveal inappropriate activity. It can protect against users who might attempt to send or remove confidential data. For example, a user in an office might choose to connect a laptop to a fax line to surreptitiously send out data. Or the user might connect to the fax line, leave work, and, after being off the premises, dial into the fax line and pull confidential data out of the connected computer.

A policy that prohibits users from seeking an alternative mode to either sending or receiving data and restricts users to assigned network connections can aid in resolving this issue. Consistent log checking can handily reveal a breach of this policy.

Fax Line Use

Further to the policy that regulates monitoring of outgoing calls, a policy stating that fax lines can only be used by fax machines and never be used, for example, by networked workstations, can ensure that users do not use fax lines for dialing out and that administrators will be on the lookout for any such transgressions.

Dialup Workstations

Although less common today, dialup desktop workstations are still used by some organizations. Where they are still in use, policy must address the need to ensure that these workstations are never connected to a network.

Inbound Dialing

While not as common anymore, certain organizations still allow users to dial into the network and retrieve e-mails. When inbound calls are no longer desired, a remote-access server (RAS) can be configured to ignore incoming calls.

Password Storing

Certain systems are programmed to encourage users to store passwords in the automated logon sequence, releasing users from needing to remember the password the next time they log on. Users should refrain from the practice of saving passwords and should be instructed to bypass all prompts that might encourage them to commit passwords to the memory of the equipment. Should a laptop be stolen or an unauthorized person were to sit at a user’s workstation, the unauthorized party would be able to gain immediate access to a company network, replete with all rights and privileges accorded to that user.

Strong Authentication

Two-factor authentication, often referred to as strong authentication, can help to ensure that only rightful users gain entry to a system or facility. A user is prompted to provide a username and then possibly a fob-generated password and PIN, as an example. The process, described in detail in Chapter 3, ensures that a stolen fob or smart card would be rendered useless without an accompanying PIN.

Remote-Access Policies

Users working from a remote office branch office (ROBO) or a small office home office (SOHO) can communicate using dedicated or nondedicated connections from their workplace. Access of this kind must be controlled to ensure that unauthorized persons cannot also gain entry to the company network.

Remote-access policies cover the following equipment:

• T1

• Frame Relay

• VPN access

Dedicated T1 lines and Frame Relay technologies can be used to, as an example, interconnect offices such as branch offices to head offices. Individual users connecting from hotel rooms and homes would typically use xDSL or cable technology to build a VPN tunnel, which is discussed in greater detail in the section "VPN and Encryption Policies,” later in this chapter. A VPN connection builds a secure encrypted tunnel between a user and her corporate network, allowing the same access as if she were in the office.

OTP authentication, or public/private keys, as discussed in Chapter 3, should be used to ensure utmost security.

Remote Configuration Policies

System administrators require a secure environment whenever the need arises to configure or manage remote devices. They typically have the following two options:

• Secure Sockets Layer (SSL)

• Secure Shell (SSH)

Secure Sockets Layer

SSL provides point-to-point security and, as described in Chapter 3, is commonly used in financially based web transactions. SSL encrypts a session. As an example, if a financial transaction is being conducted, everything that is resident on that page is encrypted, regardless of whether it requires encrypting intensive graphics or music. A system administrator can use SSL whenever the need arises to configure devices remotely. While SSL is prudent for many applications, it does inject a certain amount of latency, or slowness, into a transmission.

Secure Shell

SSH also provides encryption, but rather than securing an entire session, it offers greater specificity by operating at the command line, narrowing its focus to specific applications.

In general, communication performed at the command line is typically done in a clear-text session, usually on port 23. SSH allows a particular Telnet stream to be encrypted; Telnet is a protocol that issues instructions at the command-line interface of a system. A secure Telnet done on port 22 allows exchanges to be encrypted, reducing the need to encrypt an entire session.

VPN and Encryption Policies

Virtual Private Networks (VPNs) allow a remote user to create a secure connection to a corporate network by forcing all traffic to and from the user’s PC to go through the dedicated VPN tunnel, as opposed to going through a split tunnel.

When a VPN is in place, organizations must do the following:

• Determine users who require remote access

• Determine encryption requirements

• Determine encryption standards

• Adjust expectation levels and educate users

Determine Users Who Require Remote Access

Limiting remote access to only those users who truly require it always constitutes good policy. Local field salespeople might feel they need access, but depending on a host of variables, including the type of business an organization is engaged in, the physical location of the office, and the speed with which product or services need to be delivered, salespeople might be able to work offline to enter orders without loss of efficiency. They can download pertinent data as soon as they reach the office or e-mail the information from the client’s location. Though often desired by many users, direct access is not required in all remote situations.

Determine the Maximum Time Length of Encrypted Sessions

Ideally, VPN connections should be disconnected after ten minutes of inactivity. In addition, it is prudent to predetermine a maximum amount of minutes or hours a user can be continuously connected. Limiting connections to three hours would require users to log off and reauthenticate to create a new VPN tunnel for an additional three-hour maximum.

Determine Encryption Standards

Specific protocols can be used to build a VPN tunnel, and IPSec is one of the more common ones.

When a systems administrator uses IPSec, he must decide on the strength of encryption that is required. As an example, DES (56-bit key) and 3DES (triple 56-bit key) are various strengths of encryption. 3DES is slower than DES, which results in a latency tradeoff for superior encryption. 3DES has greater encryption capability but a somewhat slower system speed. Advanced Encryption Standard (AES) is an emerging standard that is available in 128-, 192-, or 256-bit encryption.

The strength of the encryption key should be reviewed at least annually, because something better might be available or an organization might decide that it requires stronger encryption over time.

MD5 and SHA are both hash mechanisms. Hash is explained in the sidebar "Example of a Secure Data Exchange" in Chapter 3. The system administrator must also decide whether a strong, or stronger, hash is required. MD5 is strong, and SHA is stronger.

Adjust Expectation Levels and Educate Users

Users should be briefed on appropriate VPN use, ensuring that passwords or sessions are never shared and that secure connections are used only for individual requirements. Ideally, password construction should use the following:

• OTPs stored on a fob, as an example

• Two-factor authentication

Users should understand that split tunneling is not allowed. Split tunneling can occur when a remote user connects through a VPN to the corporate network and, while still connected, initiates a direct Internet session, which would be in clear text. Should a hacker notice the Internet communication, he might be able to access the remote laptop and secure an encrypted direct tunnel to the user’s corporate network. To counter this possibility, organizations typically restrict users from opening another tunnel or deny direct communication to Internet websites when they are already connected on a VPN tunnel.

Network Policies

Establishing rules and procedures for each major appliance and network segment is prudent for an organization. Every piece of equipment is unique, and tailoring individual policies can help to ensure that critical elements are not overlooked.

This section considers the following topics:

• Router policy

• Firewall policy

• DMZ policy

• Extranet policy

• World Wide Web policy

• Wireless policy

• Server policy

Router Policy

Router policies comprise many aspects; two of the more prevalent ones are as follows:

• Access warning

• Traffic efficacy

Access Warning

Routers should post a welcome banner, sometimes referred to as an unwelcome banner, because it advises visitors that unauthorized entry is not allowed and that violators will be pursued and prosecuted. Most security requirements, whether physical or online, clearly state that potential violators need to be forewarned that certain actions might constitute trespassing or violation of private property. After he has been warned, the potential invader is subject to all possible ramifications should he pursue an unauthorized path.

Traffic Efficacy

A router can be used to filter incoming and outgoing traffic. Users leaving a network, for example, exiting a corporate network and going to the Internet, can be prompted to authenticate to ensure that they are allowed to leave. Because the router is usually not the preferred appliance on which to store user account and password information, the router can confirm status with the authentication server, the appliance that typically stores access-control lists, as described in Chapter 3. After authentication has occurred and approval has been granted to the router, the traffic is allowed to exit.

Firewall Policy

By default, a firewall blocks traffic that emanates from outside its network. Should a request be made to change the default behavior on a firewall, those users desiring the change should be required to seek approval from a firewall committee, who should in turn obtain approval from the security steering committee. Any change that requires a hole to be punched in a firewall, a process that allows certain traffic to flow in, can naturally result in the system being exposed to certain vulnerabilities.

Action of that kind should have multiple layers of approval before it can proceed.

DMZ Policy

DMZ servers, as described in Chapter 3, reside outside corporate networks. They typically act as way stations for a company’s public website.

DMZ policies consider the following items:

• Working parameters

• Ownership and evolution

• Security configuration and activity requirements

Working Parameters

DMZ servers must be highly secured, but they should not be so overly protective that users struggle to gain access. Should accessing a company’s public website prove to be an issue, routers or firewalls can be used to strategically control incoming DMZ server traffic.

Ownership and Evolution

Ownership of equipment and processes, as discussed in Chapter 5, plays a key role in effectively managing an organization’s assets. For example, responsibility for the DMZ server must be determined. The sales department is typically the largest user of the DMZ server, and its personnel might consider the server their responsibility. But if they are not actively installing patches and inspecting the server’s logs for abnormal activity, the DMZ server can represent a potential vulnerability for the organization.

All equipment, regardless of where it might reside on a network, must be assigned a rightful, responsible, and responsive owner.

An organization might find that its DMZ server evolves from its early beginnings as a simple lookup tool to one that now includes a database that accepts purchase orders and sends out confirmations. The more an appliance does, in particular a DMZ server, the greater is its exposure and potential vulnerability.

Security Configuration and Activity Requirements

Equipment needs to be configured appropriately to ensure that it achieves its optimal security level. The programming can be done directly on the appliance, or it can be done remotely. Detailed information on DMZ servers must be kept at the ready in case urgent situations arise. DMZ servers face greater exposure, and the ability to act quickly and decisively is of utmost importance.

Certain other information should also be readily available to ensure ease and speed of operability, including host contacts and location, hardware, operating system and its respective version, and any departmental users that might have privileged or department-wide passwords.

A system that either checks for patches or automatically notifies the system administrator and her alternate regarding pertinent equipment patches should be established. Equally important, patches should be applied as soon as they become available.

Extranet Policy

Organizations use extranets to share information with clients, suppliers, and other pertinent parties. This method can permit real-time sharing of data that can aid, for example, in keeping production lines running smoothly on just-in-time programs. While third parties are not allowed direct access to corporate networks, organizations need to address certain vulnerabilities. Trust exploitation, as described in Chapter 2, "Crucial Need for Security: Vulnerabilities and Attacks,” represents an example of a possible infiltration point.

Extranet policy includes the following topics:

• Business justification

• Security approval review

• Extranet connectivity

Business Justification

Users desire any function that can create an environment where it might be easier to do business. From using an extranet that systematically feeds a just-in-time production-line program to using one as a simple tool to effortlessly connect a company with its suppliers and customers, a multitude of programs can be successfully deployed. Using these programs and needing them can represent two distinct arguments, neither of which necessarily constitutes business justification.

Proposals should clearly illustrate cost savings, inventory reduction, and productivity improvements that can be realized by the introduction of a particular extranet. A strong business case must exist for a company to increase its exposure and devote IT resources to creating additional extranets.

Security Approval Review

Security reviews should be conducted prior to an extranet being approved. While an extranet might prove highly productive for a sales department or production facility, the inherent vulnerability in making an extranet available might prove too great for a particular network. Other options might be explored. Passing every proposal before a security review committee ensures that an organization can measure its risk and, where appropriate, offer alternate solutions.

Extranet Connectivity

An extranet security policy needs to address how independent organizations connect with one another. While dedicated links continue to be the preferred mode of connection, VPN tunnels, as discussed in the section "Adjust Expectation Levels and Educate Users,” earlier in this chapter, can help organizations communicate safely. Regardless of the connection mode that might be used by companies, minimum levels of protection must be agreed upon before any connection is initiated. Similar levels of protection can help to ensure that hackers cannot easily use the connection as a springboard to hack any of the participating networks.

World Wide Web Policy

URL filtering, described in detail in Chapter 3, can aid an organization in limiting its users’ access to the Internet, along with limiting its potential for legal liabilities. Whether an organization invests in access-filtering tools or trusts that its users will not visit particular types of sites, users must know, in formal policy, what constitutes unacceptable Internet browsing.

Stock market trading, retail, pornography, gambling, and a variety of other sites might be unacceptable for an organization. Users should be told to use their judgment, and when in doubt, they should not venture onto unknown sites.

With or without URL filtering, user common sense, backed by clear policy, should always prevail.

Wireless Policy

A wireless policy should cover the following points:

• Installation of wireless access points

• Wireless testing

• Encryption between computers and access points

• Preconfigured MAC addresses

• Cryptic SSID usage

• Wireless end user authentication

Installation of Wireless Access Points

Access points (APs), also referred to as wireless hubs, need to be strictly controlled so that users cannot install their own hubs. Wireless APs are widely available, and certain users might be tempted to install a hub so that they can roam the office and maintain a network connection. Completely oblivious to the potential back doors that could be created, users look to install retail-type hubs to increase personal productivity.

Ensuring that unlawful hub installation is strictly forbidden and that the message is widely disseminated to all users by policy can help to ensure that rogue access points cannot be created and penetrated.

Wireless Testing

A policy stipulating the periodic testing of wireless APs is critical to ensure that unauthorized hubs have not been installed on a network or that existing ones have not been unlawfully penetrated.

White-hat hackers can be used to perform these independent tests.

Encryption Between Computers and Access Points

Wireless communication, by default, occurs in clear text. Wired Equivalent Privacy (WEP) is the most common encryption standard for wireless communication. WEP provides wireless point-to-point encryption between access points and computers, or from access point to access point.

Preconfigured MAC Addresses

A concern in wireless environments is that a hacker could station himself outside a window and connect to the corporate network, as described in Chapter 2. Traffic would flow from a hub in the building to the hacker’s laptop, located outside the building.

System administrators can incorporate solutions into the policy to mitigate this type of threat. As an example, by storing directly on the wireless hub the MAC address of each NIC that is allowed to communicate with it, the hub cannot allow an unknown NIC to enter the network, effectively negating the efforts of the wily hacker—notwithstanding the hacker having been able to snoop the MAC address of a valid workstation and impersonate it when it was offline. NIC and MAC addresses are described in detail in Chapter 3.

Cryptic SSID Usage

Wireless hubs operate in assigned areas, and any wireless appliances residing in a hub’s vicinity, typically laptops and wireless accessories, connect to that AP. A hub can be configured to accept wireless connections from equipment or MAC addresses that it recognizes. Service set identifier (SSID) provides a unique name to identify an access point.

Systems administrators typically prefer to configure a wireless hub by geographic location. For example, if the marketing department were located in building 2 on the fourth floor, a hub’s unique name might be 4thFloorB2-XYCorp. All wireless cards that want to connect exclusively on that access point would need to be configured with that SSID information.

The issue with naming such explicit geographic locations is that a hub broadcasts its availability every few seconds. Wanting to avoid any chance of giving a hacker such detailed information, system administrators can name APs using a cryptic mode. The earlier example of 4thFloorB2-XYCorp could follow a policy requiring it to be named in a more explicit fashion that is even less revealing: 4thFloorSBNE. The fourth floor would remain the same; building 2 is (building) site B, with B representing the number 2, and NE represents the northeast corner of the fourth floor of building 2. Its location has been made even more precise, while the company’s name has been excluded from the hub’s SSID.

Wireless End User Authentication

To effectively limit access to a corporate network, a wireless policy should include rules regarding the authentication specifics that are required from users who connect wirelessly. The policy should address the authentication standard, such as Extensible Authentication Protocol (EAP), implementation, and maintenance requirements. The policy should specify the authentication that is required to thoroughly address the following:

• Who is allowed entry

• When they are allowed to enter

• What network resources they should be able to access

Server Policy

Server policy procedures contain the following strict guidelines for use and handling:

• Contact and location

• Operational data

• Patches

• Trust relationship between systems

• Physical access

• Activities and events

Contact and Location

Preparing for unknown and unforeseen circumstances requires an IT department to follow a policy of compiling a comprehensive listing of all equipment under its command, with an emphasis on its various servers. Included on each list should be the following items:

• Server type

• Server location

• Person responsible for the server (its owner)

• Alternate person responsible for the server

Should an issue ever arise, early moments will not be lost trying to determine the best person to call.

Operational Data

All components related to the successful operation of a server should be kept at the ready, ensuring that any upgrades or patches can be implemented easily and that any possible changes in staffing will not have an adverse effect on maintenance and servicing of equipment.

Pertinent information for each server can be documented in its own binder. The information contained can run from the benign (for example, informing a new systems administrator that regular maintenance is performed in the overnight hours) to the more complex, by developing a set of strict guidelines to ensure business continuity, such as a provision for bringing a backup server online. The binder can include the following items:

• Software loaded on the server

• Pertinent appliances attached to the server

• Hardware version

• Operating system version

• Main functions and applications, where applicable

• Configuration restrictions, if applicable

• CD-ROMs of operating system

• CD-ROMs of patches

• CD-ROMs of all applications

Any updates or changes to the corporate enterprise management system should be kept current in the binder.

Patches

Security patches should be installed within a set time frame after the company has been notified of their availability. Notifications can be automatic and are available from a variety of service vendors or organizations, such as CERT and SANS (http://www.sans.org).

It can be difficult to know which patches might be vitally important and which ones can wait. Too often, the most benign-looking patches can be the most important ones. A policy that ensures that all available patches are responded to in a predetermined timely fashion continues to be the most prudent course to follow.

Should demands on a systems administrator’s work load prove too great, numerous third-party services specialize in servicing patches for organizations.

Trust Relationship Between Systems

Trust relationships that exist between various pieces of equipment must be periodically inspected to ensure not only that a trust has not been violated but also that the relationship is still required. For example, an organization might use two servers to handle its sales functions. One server stores customer names, and the other processes new purchase orders, customer returns, and customer rescheduling. A routine check can ensure that a trust that exists between the two servers has not been breached. Just as importantly, it can determine whether some degree of the relationship is still required. In an attempt to improve service levels, the second server might have been preloaded with all pertinent customer information, negating the need for it to retrieve any information from the first server.

A periodic system review, in addition to using host-based IDSs, can serve as a check and balance, ensuring that unneeded vulnerabilities are routinely revealed and that potential security risks are limited to those that are truly required.

Physical Access

Servers should be located in secure environments, preferably locked rooms that guarantee highly restricted access. Should an unauthorized person ever gain entry, the ability to wreak havoc by bringing down a web server, as an example, is quite real.

Server room security is so great for certain organizations that air vents leading to a server room are secured; air is allowed to flow, but a person cannot maneuver undetected in the venting system.

Securing servers and restricting access are prudent points to pursue.

Activities and Events

Server activity should be monitored to ensure that any untoward behavior is summarily uncovered. Logs should be reviewed to examine which files have been deleted and by whom. If an activity appears unusual, it can be quickly investigated, and if a problem exists, it can be remedied early, before even greater damage can be inflicted.

All security-related events should be reported immediately, and depending on the nature of the supposed breach, an escalation path should be predetermined to deal with every type of incident.

Data Sensitivity, Retention, and Ethics Policies

A policy that addresses the inherent responsibilities of employees and considers an organization’s handling of confidential data, e-file retention, and employee conduct would take into account the following items:

• Employee vigilance

• Public and confidential information

• E-mail maintenance

• Employee conduct

Employee Vigilance

Staff members are required to act responsibly at all times, whether they are carrying out their required job functions or ensuring that passwords are always kept private and protected.

Security requires vigilance on the part of users; confidential documents used as part of a presentation, as an example, should never be left unattended in a conference room. Laptops should always be safely secured when not in use, and if a secure place does not exist to store a laptop, the user should carry it with her. Thorough security requires that users employ common sense in their daily activities, affording company assets the same respect as they would their own property.

Public and Confidential Information

Information typically falls into one of two categories: public or confidential. Rules for accessing, distributing, and storing both types should be clearly defined. This policy, typically called data classification, should state how an organization determines the following items:

• Public information

• Confidential information

• Accessing information

• Distributing information

• Storing and disposing of information

• Disclosing confidential information

Public Information

Public information is typically defined as information that can be freely given to anyone, without the giver incurring any possible repercussions. The information might include company literature, pamphlets, sales and marketing tools, public financial reports, and similar widely disseminated offerings.

Confidential Information

Confidential information is usually labeled accordingly, but it also requires users’ common sense to realize when particular information might be considered private. An internal telephone directory might not be labeled confidential, but it is generally understood that it should never be disseminated outside an office.

Persons who are privy to private conversations instinctively know never to reveal information that is integral to a company’s success, such as trade secrets, private financial data, future plans, and similar pertinent data.

While common sense and respect are key elements when maintaining confidences, organizations can include a statement in their policy indicating that any persons who knowingly breach company confidential information can be prosecuted to the full extent of the law in the jurisdiction in which they are employed.

Accessing Information

The ability to access confidential information should be clearly defined. If material is meant for specific individuals, e-mailing it can ensure that a user would require a network password to access, at minimum, his or her e-mail account. A file attached to an e-mail can be secured with an additional password, ensuring that only the rightful owner could open the document. Encryption, another option, is discussed in the section "VPN and Encryption Policies,” earlier in this chapter.

If information is company-wide confidential, meaning that it is company confidential but meant for all users, an organization might post it on its intranet, ensuring that a user would need to sign on with a network password to access the information.

Information that is deemed public could be posted on a company’s public Internet site.

The confidential policy should also stipulate who in the organization has the authority to change security classifications, such as downgrading a document from confidential to public.

Distributing Information

Sensitive documents distributed through interoffice mail can be well served with a process similar to that used by registered mail, ensuring that the recipient, or his or her agent, signs for the envelope and that the sender receives acknowledgment of said acceptance.

Private documents forwarded by e-mail could use encryption, ensuring that only the intended receiver could decipher it, as described in the section "File Encryption" in Chapter 3.

Storing and Disposing of Information

Confidential documents can be stored in a password-protected e-mail account or a password-protected server. Hard-copy documents can be stored in a locked file cabinet that, depending on the nature of the confidential note, can be located in a locked access-controlled room.

Disposal of documents should be handled appropriately. Physical documents need to be shredded by equipment that renders material unreadable, ensuring that it is impossible to reconstruct a document. Hard drives should be sanitized before they are disposed of, ensuring that private information is unrecoverable.

Disclosing Confidential Information

Users should be fully cognizant of the ramifications that could ensue should confidential documents be exposed, regardless of whether it is intentional or inadvertent. Should a corporation identify specific documents to be confidential, the organization must inform its users of the following:

• What are the confidential classifications

• What each classification demands

• What is required of each user

• What consequences might ensue should confidentiality be breached

By recognizing the fundamental importance of company confidentiality, employees can understand the underlying logic that supports the labeling and be in a better position to ensure that confidentiality remains intact.

E-Mail Maintenance

E-mail messages should be assigned classifications, enabling users to prioritize them appropriately. Low, normal, high, private, confidential, and other similar terms connote the sender’s intent, but they should be applied within the strict guidelines of corporate policy to ensure consistency and respect for content.

When confidential information is sent through e-mail, it should be signed and encrypted using a standard such as Signed Multipurpose Internet Mail Extensions (S/MIME), a protocol that was initially developed by a private consortium of vendors. Later versions are available today. S/MIME allows users to send almost any type of file or document in an e-mail message, including text, images, audio, video, and so on.

Many guides are available that suggest the length of time a company should retain e-mails. The Sysadmin, Audit, Network, and Security (SANS) Institute makes the following recommendations:

• Administrative correspondence: 4 years

• Fiscal correspondence: 4 years

• General correspondence: 1 year

• Informational correspondence: Discard after reading

When in doubt, or if dictated by law, policies can span longer periods of time to ensure that comprehensive recordkeeping is maintained.

Employee Conduct

Ethics play a major role in every organization. Policies regarding ethics enable users to know what constitutes acceptable behavior on their part and, just as importantly, how they should expect to be treated.

Most organizations seek to create dynamic cultures that are steeped in the following:

• Respect for others, including fellow employees, management, clients, and stakeholders

• Openness, providing a forum for candid dialogue

• Empowerment, allowing employees to achieve their potentials

• Trust, ensuring that employees share in the most sacred of trusts: respect for company property, both intellectual and physical, and organization-wide focus, knowing that the entire team is pulling in the same direction

• Integrity, in achieving both individual targets and company-wide goals, by acting and excelling within the spirit of company policy

Setting expectations can aid individuals in achieving their best.

Software Policies

Software policy can be further divided into the following three subgroups:

• Operating system policy

• Virus protection policy

• User software policy

Operating System Policy

An organization must strive to have a similar operating system across its entire structure. In an urgent situation, IT must be able to service the network as a whole, and if network segments are radically different from one another, or if IT is not aware of various installations, the ability to combat a given issue can be slowed.

An organization might decide, for example, that all workstations need to be equipped with the same operating system and that all software copies need to be of the same version. Servicing, particularly if performed under any type of duress, would be infinitely more efficient in that type of environment.

Virus Protection Policy

Safe computing requires that every user exercise common sense and thoughtfulness in his daily routine. A presentation outlining particular actions that could potentially compromise a system might help users act more thoughtfully and responsibly.

Virus protection policy could include the following rules for users:

• Never block a virus update that is attempting to run.

• Always follow the preventative procedures set forth by the antivirus provider.

• Never open e-mails from unknown sources.

• Always double-delete suspect e-mails (see the "Double Delete" Tech Tip).

• Never open attachments that are remotely suspect.

• Never respond to junk mail or chain mail.

• Never unsubscribe to an e-mail service that you never subscribed to initially.

• Never download files from suspicious sources.

• Always scan files pulled from floppy disks, CD-ROMs, USB keys, and other similar media.

By thoughtfully using known policy procedures and responsible common sense in their daily routines, users can ensure that unknown and potentially unsafe files and attachments containing hidden viruses are not allowed to inadvertently infiltrate a company network. It would be challenging to list every possible action that could potentially make a system needlessly vulnerable to attack, which is why the term common sense has been used throughout this chapter. Similar to citizens who are required to act within the spirit of a particular law, common sense makes it incumbent upon users to act within the spirit of a company’s security policy, regardless of whether a rule is specifically stated.

User Software Policy

User software policy considers the following items:

• Installation policy

• Database policy

• E-mail policy

Installation Policy

Much has been discussed about rogue equipment being installed on networks. Installing rogue software on operating systems is also not acceptable. A policy that ensures that only IT, or IT-sanctioned, staff are permitted to install software is highly advised.

Database Policy

An organization typically applies certain rules to its processes. For example, a rule might state that databases are stored on separate or dedicated servers and that each server requires multiple authentication processes to be accessed. If one server were ever compromised, a hacker wouldn’t necessarily have access to its information if he didn’t possess all the requisite passwords. If user accounts must be stored on the same server as the database, the user and password file should be either password protected or better encrypted.

Passwords should always conform to corporate policy rather than relying on what might be suggested in a software manual.

E-Mail Policy

E-mail policies should convey acceptable and unacceptable user behavior. They are subdivided into the following categories:

• Access

• Vigilance

• Content

• Confidentiality

Access

A policy that addresses e-mail access from hand-held devices and other remote methods, such as webmail, should be developed. Many organizations consider this type of access to be lacking in security and are loathe to allow it.

Vigilance

E-mail usage has become an issue in many organizations. Users are continually bombarded with spam e-mails that attempt to sell everything from sports equipment to pornography and everything in between. While much of it is a nuisance, and some of it rather objectionable, certain e-mail attachments can contain viruses. The hapless e-mail reader is often so bombarded with e-mails that he just rifles through his inbox, clicking on each one in an effort to get through them quickly. Many network issues could be avoided with a certain amount of vigilant policy enforcement on the part of users. Stopping viruses at the gate and refusing them entry onto a corporate network would go a long way in helping to forge a security posture that is increasingly more secure.

Content

An organization needs to ensure that its users understand its philosophy on e-mail etiquette. Distributing the formal policy to users the moment they join a company can ensure that each user is fully cognizant of the firm’s expectations. A policy should consider addressing the firm’s stance on the following issues:

• Sexual matters, from orientation to pornography

• Religious matters

• Proper use of language, in particular, undesirable slang words

• Political messages

• Gender and race messages

• Disability comments

• Anything that could be construed to be offensive to another individual

While organizations might want to acknowledge that a certain amount of personal e-mail use is acceptable, it should make clear that the system is monitored and that users should have no expectation of privacy. Should privacy be required, users should send and receive e-mails from their homes.

Confidentiality

A confidentiality notice should be included in every e-mail emanating from an organization. It can resemble the following notice:

CONFIDENTIALITY NOTICE: This communication and any attachments and/or enclosures can contain information that is (legally) privileged or confidential and is intended only for the use of the individual or entity to whom it is addressed. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, copying, or disclosure of this communication and any attachments and/or enclosures is strictly prohibited. If you have received this communication in error, please notify us immediately and then permanently destroy this communication without making a copy. Thank you for your cooperation.

Summary of Policy Types

Table 10-1 displays sample content for each of the policy types covered in this section.

Some interesting sources for examples of security policy formation are The SANS Security Policy Project (http://www.sans.org/resources/policies/#template) and the Site Security Handbook (http://www.ietf.org/rfc/rfc2196.txt?number=2196).

Handling Incidents

Planning for difficult situations is highly advisable, and a policy to address security incident handling could prove invaluable. A contact person responsible for every major piece of equipment or network segment should always be at the ready, along with the person’s backup. An enterprise might require certain IT staff to carry pagers, guaranteeing the availability of personnel to contend with issues as they arise. Because of illness, vacation, or termination, alternate personnel should also have alternate resources to ensure the highest degree of business continuity possible, even in times of intense system stress. Equally important, key personnel need to know where to report should an alarm sound, and they should be comfortable with the tasks that are required of them.

Appropriate authorities should be notified, including state, local, and federal law enforcement officials. Organizations such as CERT and other pertinent security awareness groups can provide invaluable support. Fighting computer crimes requires vigilance on the part of users and systems administrators. It also relies on corporations who are victims of computer crimes to create an environment that publicizes said crimes. Creating greater public awareness can serve to evoke vigilance on the part of users and corporations everywhere and can help to curtail the needless spreading of malicious content.

The act of advising law enforcement officials and independent security industry groups can represent a major step forward in helping to thwart the seemingly insatiable appetites of those individuals who want to inflict mindless damage.

Summary

Organizations invest untold amounts to fortify their systems, but equipment alone does not embody a solution. A security system is only as strong as its weakest link, and company internal human error, be it intentional or inadvertent, can represent a system’s greatest vulnerability. A combination of equipment and positive user involvement is the concrete platform organizations can use to build a sound, security-rich environment.

Employees naturally seek direction, and the creation of effective security policies can provide that necessary guidance. Ensuring that policies are enforceable and measurable can result in the development of an environment that proactively works to secure itself.

This chapter discussed the following topics:

• The need to determine appropriate policies

• The process of constructing reliable and sound policies

• Acknowledging tools and implementation considerations

• Establishing a process for comprehensive monitoring

• An array of policy types

• The importance of incident handling