Security Policies

Consequently, a firewall is only as effective as the firewall security policy (as opposed to the enterprise security policy) that dictates how the firewall will be used
Nội dung trích xuất từ tài liệu:
Security PoliciesSecurity PoliciesAs mentioned previously, firewalls are nothing more than access control policyenforcement points. Consequently, a firewall is only as effective as the firewall securitypolicy (as opposed to the enterprise security policy) that dictates how the firewall will beused. Firewall security policies are discussed in great detail in Chapter 10, FirewallSecurity Policies, but we can look at the fundamentals of what kinds of firewall securitypolicies exist and how to build an effective security policy now.The first step to a good security policy is to perform a risk analysis to determine what thethreats to the protected system are. After doing this, you can develop a strategy andpolicy for protecting the system from those threats with your firewalls. A key thing tounderstand when you develop this strategy is that you may not be able to protect againstor prevent everything. The reasons for this range from technological limitations(technically the recommendation cannot be done) to practical limitations (it would not bepractical to undertake the recommendation) to financial limitations (you do not have themoney in the budget to undertake the recommendation). As a result, you need toapproach the subject from the perspective of seeking to minimize the risk associated withthe threat. In some cases, that means you can reduce the risk to zero (for example, if youuse a firewall to prevent all access to a system). In other cases, you can only reduce therisk to a level that is acceptable by management. For example, management may notdecide that they can afford to spend the money required to implement the securitysolution recommended. In this instance, it is absolutely critical to convey in an honest andaccurate manner what the level of risk will be. The reason for this is that after an incidentoccurs, it becomes real convenient for people to suddenly forget that they agreed to thatlevel of risk in the first place. This is the time that it comes in handy to be able to producea signed document that proves everyone agreed that the level of risk that was settled onwas appropriate.Examples of Security PoliciesYou have two primary security policies to use as a baseline in designing your securitypolicy. The first is the closed security policy, also known as the minimalist securitypolicy. The other is an open security policy, also known as generally a bad idea.The closed security policy is based on the premise that by default all access is denied, andonly access that is explicitly required will be permitted. The benefit of this approach isthat the security policy will be designed only to allow access that has been explicitlygranted. This security policy is frequently implemented when dealing with grantingaccess from an untrusted source to a protected system (sometimes referred to as ingressfiltering). The drawback of this system is the same as its strength, however. Because thedefault action is to deny traffic, it can be a time-consuming process to identify, configure,and maintain the list of exceptions that must be permitted.At the other end of the spectrum is the open security policy. It takes the exact oppositeapproach, by default granting all access and denying only the traffic that is explicitlyconfigured to be denied. This type of security policy is frequently implemented forgranting access from a trusted network to external systems (sometimes referred to asegress filtering). The benefit of this system is that it generally takes little to noconfiguration to allow systems to traverse the firewall and access resources. As a result,many firewalls by default apply this methodology to traffic that is sourced from theinternal network to external networks such as the Internet. Although convenient, it isincredibly insecure because the firewall will allow legitimate and malicious traffic outwith equal ease. Consequently, it is not recommended that you implement a firewall thatis configured in this manner. Although more convenient, the risk is simply too great formost environments.Firewalls and TrustAfter the decision has been made to allow some traffic through the firewall, theadministrator has effectively made the decision (intentional or not) to trust the traffic thatwill be permitted. This decision is part of defining an acceptable level of risk. A firewalltypically does not exist to stop all traffic. If it did, you would be better served just todisconnect the system from the network entirely. Instead, the firewall exists to allowsome traffic while stopping other traffic.In these situations, you have to realize and accept that by permitting certain traffic, youare trusting that the traffic is safe and acceptable. However, this does not mean that bydeciding to permit traffic you are effectively removing any security a firewall canprovide. Simply put, just because you trust certain types of traffic does not mean youhave to trust the traffic in its entirety and in every way.In the continued pursuit of mitigating and minimizing risk, you can configure the firewallto authenticate connections that will access the trusted resource, adding an additionallevel of security and risk management to the access that is being granted. Doing soensures that before access to the protected resource will be granted, the requesting systemmust be authenticated as a legitimate user of the resource.Another option is to use the firewall as an application proxy, serving as an intermediaryfor providing access to the protected resource. As discussed previously in this chapter,this can help mitigate and minimize risk by ensuring that all access to the protectedresource must go through the proxy, allowing the proxy to ensure that the data beingtransmitted is not malicious or harmful.The biggest thing to remember about firewalls and trust is that no matter how much youtrust the access being gra ...