What good does a firewall, IPS sensor, encryption device, and your favorite security product and tool do if you do not have guidelines, policies, and best practices on how to effectively configure and use them?
Building strong security policies is crucial for any organization. These policies should be strong, yet realistically flexible to accommodate ever-changing requirements. Policies communicate not only a standard but also an agreement on what should be the best practice for a specific situation (in this case, related to security). Policies must be detailed, yet easy to understand, and must also balance enforcement and productivity. A security policy is useless if it impedes productivity. During the security policy design stages, you should define the reasons why such a policy is needed. Also define the stakeholders, contacts, and their responsibilities. In addition, you should discuss how to handle violations to such a policy. Depending on the size and goals of your organization, you may document the security policies in one large document or several small ones.
Note: In most cases, smaller documents are easier to maintain and update, rather than having bibles for security policies that no one can read or keep up-to-date.
Occasionally, certain policies are appropriate for every site within your organization; others may be specific to certain environments. In addition to policies being strong and flexible, they must be enforceable. An organization can have many different policies depending on its applications and systems. Some policies are implemented because of regulatory compliance to standards like Sarbanes-Oxley and the Health Insurance Portability and Accountability Act (HIPAA) of 1996. The following are some of the most common policies in every organization:
Acceptable use of specific applications and systems
Data center security
Extranets and demilitarized zones (DMZ)
The following are examples of other policies:
Acceptable encryption protocols
Network admission control
Trust is the main subject in many policies. Many say that policies will not be written if you trust everyone to do the right thing. Ideally, you want to trust all resources, but that is unrealistic. Even defects in software and hardware are risks that you do not want to take by trusting everything that is not human. Different types of people (like your staff, guests, and contractors) should be trusted at different levels. Ensure that the level of access commensurate with the level of trust.
SANS has several security policy templates that you can download at:
Some people think of security policies as long documents that merely define what level of access systems and people have. However, policies include all of the previously mentioned items and topics, such as:
Baseline router configuration parameters
Guidelines for forwarding e-mails to external addresses
Configuration management procedures and change control
Configuration management procedures and change control is a hot topic when planning incident response procedures. Security changes are defined as changes to network equipment that might impact the overall security of the network. Remember that these policies have to be flexible enough to accommodate the changes that staff members make to respond to security incidents and outbreaks. All security teams (such as InfoSec, CSIRTs, and so on) should review the list of business and technical requirements in order to identify specific network configuration or design issues and meet security needs. Patch management is also a hot topic today. Always ensure that the current software revision levels of network equipment, desktop machines, and servers are up-to-date with security patches and hotfixes. Update security policies regularly or on an as-needed basis. At a minimum, schedule an annual review to ensure that security policies do not become obsolete because of technological changes and demands. Also, include a provision for ad-hoc updates when higher-priority changes are needed. It is recommended that you engage subject matter experts (SME) when reviewing existing policies because you should consider several factors in addition to those included during the initial development. SMEs can provide valuable input into changes in technology and best practices that may need to be incorporated into the specific policy. Security violations, deviations, and relevant audit information should also be reviewed when considering an existing policy. You can use various techniques when planning, developing, and updating security policies. Always take the following basic idea into consideration: the policy must primarily reflect what is good for the security of the organization as a whole without limiting productivity.
I'm having an odd issue on one users workstation. I recently upgraded our ASA to version 9.13. I have two VPN images in flash with 4.7.02.036 being the primary image. When the user connects to Anyconnect it starts an upgrade process which includes removin...
Hi All, I am working on Cisco 2.6 (Without Patch) version and want to test Laptop posture with Any connect module manually installed on Laptop. I have installed the module and created .xml configuration with Profile editor. Now, it does not...
Hi guys,I have an issue with a Firepower 1010 (running 6.5) and the FDM.I have a long list with public IP addresses (one address per line) and need to create a Blacklist in the FDM (FMC cannot be used there).When I go in FDM under Policies > Security I...
Hello ISE experts, since several weeks I'm struggling now with the new Cisco licensing model on ISE instead of focusing on the real importanttechnology stuff, wich i did before using Cisco ACS.Here is the real Cisco customer story that I ca...