Security Policy Recommendations

Although it is impossible to make a one- size -fits-all security policy for all environments, most environments should have a few types of security policies in common and, at a minimum, should address or contain some specific points. Because this book is about hardening your network infrastructure, I am going to focus on security policies that are particularly relevant to your network infrastructure. These are not exhaustive security policies, but they highlight specific details that each policy should address in some way. For information about applications and operating system security policies, see the counterpart books in this series, Hardening Windows Systems by Roberta Bragg and Hardening Linux by John Terpstra. In addition, SANS maintains a list of sample security policies that you can review for use in your environment at http://www.sans.org/resources/policies/.

Encryption Policy

Your encryption security policy should define not only the supported encryption standards you will use to protect data across your network, but the encryption mechanisms and standards you will use to protect the data on your servers or with your applications (for example, encrypting e-mail messages). Your encryption policy should also define the types of data that require encryption to ensure that everyone knows what must be encrypted regardless of circumstances. Finally, your encryption policy should provide configuration information and examples to ensure compliance.

Analog/ISDN Policy

Your analog/ISDN security policy should define the various analog line devices such as modems, fax machines, and computer connections. It should contain a procedure that defines how this type of access should be requested and how this type of access should be protected from exploit or compromise. Ensure that all analog or ISDN connections have a justified business case for their existence, because analog lines often represent a significant security threat due to them commonly being used for dial-in purposes. Finally, your security policy should require that any network diagrams and documentation be updated prior to any new devices being implemented.

Antivirus Policy

Your antivirus policy should address running virus protection on all your desktops and servers as well as your e-mail servers and gateway systems. In addition to defining where to run virus protection, your antivirus policy should provide specific configuration requirements, including requiring on-demand scanning, regularly scheduled scanning operations, and periodic updates and upgrades. Your antivirus policy should also provide information regarding blocking e-mail attachments as well as a statement preventing disk sharing and downloading of unauthorized files.

Audit, Vulnerability Assessment, and  Risk  Assessment  Policy

Your audit, vulnerability assessment, and risk assessment policy should define the procedures and tools that will be used for auditing and testing your network. It should address questions regarding obtaining the consent to perform testing and the liability from outages and interruptions that may be related to the testing. You should require that client points of contact be established for all systems that will be tested as well as ensure that the scanning period of the testing is well defined prior to testing.

Dial-in Policy

Your dial-in policy should require that all users explicitly request dial-in access and that all requests provide a business justification for the access. The security policy should ensure that no one other than the authorized user connects to the network and assign the responsibility of ensuring this occurs with the user . Your security policy should also require callback or caller ID verification, where possible, and authentication in all cases. Your dial-in policy should define a procedure for disabling dial-in access that has not been used in a certain amount of time. Finally, your security policy should require that any network diagrams and documentation be updated prior to any new devices being implemented.

DMZ Policy

Your DMZ policy should define the configuration requirements of all systems that exist in the DMZ, including disabling services and defining the types of equipment that can be placed in the DMZ. Your DMZ policy should require that systems in the DMZ be patched in a more rapid fashion than other systems, due to their close proximity to external threats, and identify who is responsible for the equipment to ensure this occurs. Your DMZ policy should also define how remote administration will be performed, if it is permitted at all, to ensure that only secure remote administration occurs. All communications between systems on the internal network and the DMZ should also be defined in this policy, requiring secure content updates, and so on. Your DMZ policy should define an exhaustive and extensive logging policy, allowing you to better monitor your DMZ resources. Finally, your security policy should require that any network diagrams and documentation be updated prior to any new devices being implemented.

Extranet Policy

Your extranet policy should define that all extranet connections require a security review and business case to justify them. Your extranet connections should also require a point of contact for all remote connections and should grant access only to the specific resources required for the extranet users to perform their jobs. All traffic traversing the extranet connections should be encrypted to prevent eavesdropping on the data. Finally, your security policy should require that any network diagrams and documentation be updated prior to any new devices being implemented.

Wireless Communications Policy

Your wireless communications policy should define the equipment that will be used and require that all wireless equipment be registered with the information technology (IT) department to allow for easier tracking of these resources. Your wireless communications policy should require not only explicit authorization from IT for all wireless access, but also a business case and justification for granting access. It should also define the encryption and authentication requirements of all wireless connections. Your service set identifier (SSID) should not contain any organizational information because SSIDs are easily read by external users, which would allow them to know that they found an access point on your network. Because wireless networks are so inherently insecure and pose such a substantial threat to your network, your wireless communications policy should clearly state that implementing an unauthorized wireless access point or wireless connection is grounds for employment termination. Finally, your security policy should require that any network diagrams and documentation be updated prior to any new devices being implemented. We will look at hardening wireless access in much more detail in Chapter 8.

VPN Policy

Your VPN policy should specify the permitted hardware, software, technologies, and protocols used to provide VPN access to your network. It should define the encryption and authentication mechanisms that will be used to secure the VPN. In addition, it should clearly state that only authorized users are allowed to use the VPN connection, and it should assign the responsibility of ensuring this occurs with the users. The policy should also define how the VPN connection will be established, identifying whether split tunneling is permitted, what the idle timeouts are, and whether the user can access local resources and VPN resources at the same time. Your VPN policy should also require that all remote systems adhere to any relevant corporate security policies and run virus protection and firewall software in accordance with the appropriate security policies. Finally, your security policy should require that any network diagrams and documentation be updated prior to any new devices being implemented. We will look at hardening VPN connectivity in much more detail in Chapter 5.

Firewall Security Policy

Your firewall security policy should define the network- and software-based firewalls that should be implemented on your network. It should also define the types of firewalls that will be implemented and how they should be configured, including what services and protocols will be run. Details regarding ingress and egress filtering, including configuration examples, should also be defined in the policy. In addition, your policy needs to define how remote administration should be performed and what authentication mechanisms and logon banners should be used. Finally, your security policy should require that any network diagrams and documentation be updated prior to any new devices being implemented. We will look at hardening firewalls in much more detail in Chapter 3.

Router and Switch Security Policy

Your router and switch security policy should define how your routers and switches should be configured and deployed throughout your network. The types of remote administration and authentication mechanisms, including logon banners, should be defined. In addition, permitted protocols and services should be identified with configuration requirements, and disallowed protocols and services should be identified to be disabled. Any access control lists (ACLs) should also be defined. Finally, your security policy should require that any network diagrams and documentation be updated prior to any new devices being implemented. We will look at hardening routers and switches in much more detail in Chapter 6.

Remote Access Policy

Your remote access policy should define the types and methods of remote access that will be permitted on your network. It should not replace your dial-in and VPN policies but rather should complement them by defining the process of requesting remote access and the types of remote access a given scenario requires. It should also define the kind of access that remote users will have on your network. In other words, can remote users access the entire network or only specific segments and resources? Finally, your remote access policy should define who is qualified to connect via a remote access connection.

Password Policy

Your password policy should define the requirements not only of passwords but for SNMP community strings, preshared keys, and any other manual/text-based authentication mechanism that exists on your network. The password policy should define the minimum lengths of passwords, how often passwords must change, whether passwords can be reused, whether a user must log on to change their password, and how many incorrect passwords are required for an account lockout. It should also stipulate what the password requirements are (for example, requiring letters , numbers , and mixed case). The process of notifying a user what their password is should also be clarified (for example, prohibiting the sending of the password via electronic means). The policy should also prohibit using password remember functions of any application as well as prohibit the user from writing down their password or sharing their password with anyone , including IT or their boss.

Intrusion Detection/Prevention System Policy

Your IDS/IPS security policy should define how your IDS/IPS should be deployed as well as where it should be located. It should also define the types of traffic you are going to monitor for and what actions will be taken when a specified traffic pattern has been identified. Your IDS/IPS security policy should also address remote administration and authentication of users authorized to manage the system. In addition, the security policy should define how often the signatures are updated and provide a mechanism for implementing high-risk signatures in a rapid fashion. The policy should also address what type of auditing and reporting will be performed on the system and who is authorized to view the reports and what is done with the data. Finally, your security policy should require that any network diagrams and documentation be updated prior to any new devices being implemented. We will look at hardening IDS/IPS in much more detail in Chapter 4.

Content-Filtering/Internet Policy

Your content-filtering/Internet policy should define who is allowed to access the Internet and what types of access are permitted. In addition, the policy should identify the vendors of any content-filtering software you will be using and define the method for updating the lists of websites being permitted/blocked. Your security policy should also identify the categories of websites that exist and whether those websites are acceptable for a work environment. The policy should define how users can request access and what the policy is for logging and reporting violations. The policy should also define the level of privacy the users can expect while using the Internet. Finally, your security policy should require that any network diagrams and documentation be updated prior to any new devices being implemented. We will look at hardening content filtering in much more detail in Chapter 7.

Enterprise-Monitoring Policy

Your enterprise-monitoring policy should define the monitoring and management protocols and technologies that will be used on your network, including SNMP, RMON, NetFlow, and Syslog. The policy should require that all management occur using secure and authenticated sessions, where possible, and IPsec encapsulation in all other cases. The policy should also define the logging policy for all resources on your network, including who can review the logs and what gets done with the information in the logs. The policy should identify the types of network events that may occur and what to do when an event is triggered. The management stations that are allowed to monitor your network should also be defined in your policy as well as who has access to those management stations and the information collected. Finally, your security policy should require that any network diagrams and documentation be updated prior to any new devices being implemented. We will look at hardening an enterprise-monitoring solution in much more detail in Chapter 10.

Acceptable-Use Policy

The acceptable-use policy (AUP) is one of the most important policies on your network because it defines what the acceptable usage of organizational resources is. The policy should define, among other things, whether users can share passwords; install applications; copy data for archiving or other purposes; use instant messaging clients ; store sensitive data on their laptops, floppy disks, or pen drives ; and read, view, or change data that they did not create or are not common files. Every aspect of what a user can and, more important, cannot do should be addressed in your acceptable-use policy. The acceptable-use policy should also set the levels of privacy the user can expect while using organization resources. This policy should also require the user to sign the AUP as part of their hiring process to ensure the user understands not only the policy but the repercussions of not adhering to the policy.

Network Connection Policy

Your network connection policy should address the connectivity of devices on the network, including what types of devices can be connected to the network, who can connect the devices to the network, and what the process is to request a device be connected to your network. The policy should also define what to do in the event that a network device is down or causing a problem on the network, and what the process is for addressing unauthorized network connections. Finally, your security policy should require that any network diagrams and documentation be updated prior to any new devices being implemented.

Network Documentation Policy

Your network documentation policy should define who is responsible for keeping your network documentation and diagrams up to date. It should also define where and how the diagrams are stored and who has access to the information. It should also define the data classification that all your network documentation and diagrams should be considered as. For example, your network diagrams are as valuable as a map in the hands of a hacker in terms of identifying what and where to attempt to compromise your network. You should classify the data accordingly , with it being considered at least a confidential document.