QUESTION NUMBER 45-49
45. What are the various policies based on applications, user identity & Network Activity.
Policies Based on Applications
Most early firewall work involved simply blocking unwanted or suspicious traffic at the network
boundary. Inbound application firewalls or application proxies take a different approach—they let traffic destined for a particular server into the network, but capture that traffic in a server that processes it like a port-based firewall. The application-based approach provides an additional layer of security for incoming traffic by validating some of the traffic before it reaches the desired server. The theory is that the inbound application firewall’s or proxy’s additional security layer can protect the server better than the server can protect itself—and can also remove malicious traffic before it reaches the server to help reduce server load. In some cases, an application firewall or proxy can remove traffic that the server might not be able to remove on its own because it has greater filtering capabilities. An application firewall or proxy also prevents the server from having direct access to the outside network.
If possible, inbound application firewalls and proxies should be used in front of any server that does not have sufficient security features to protect it from application-specific attacks. The main considerations when deciding whether or not to use an inbound application firewall or proxy are:
• Is a suitable application firewall available?
• Or, if appropriate, is a suitable application proxy available?
• Is the server already sufficiently protected by existing firewalls?
• Can the main server remove malicious content as effectively as the application firewall or proxy? ¬ Is the latency caused by an application proxy acceptable for the application? ¬
• How easy it is to update the filtering rules on the main server and the application firewall or proxy to handle newly developed threats?
Application proxies can introduce problems if they are not highly capable. Unless an application proxy is significantly more robust than the server and easy to keep updated, it is usually best to stay with the application server alone. Application firewalls can also introduce problems if they are not fast enough to handle the traffic destined for the server. However, it is also important to consider the server’s resources if the server does not have sufficient resources to withstand attacks, the application firewall or proxy could be used as a shield.
When an inbound application firewall or proxy is behind a perimeter firewall or in the firewall’s DMZ, the perimeter firewall should be blocking based on IP addresses, as described earlier in this section, to reduce the load on the application firewall or proxy. Doing this puts more of the address-specific policy in a single place the main firewall and reduces the amount of traffic seen by the application firewall or proxy, freeing more power to filter content. Of course, if the perimeter firewall is also the application firewall and an internal application proxy is not used, no such rules are needed.
Outbound application proxies are useful for detecting systems that are making inappropriate or dangerous connections from inside the protected network. By far the most common type of outbound proxy is for HTTP. Outbound HTTP proxies allow an organization to filter dangerous content before it reaches the requesting PC. They also help an organization better understand and log web traffic from its users, and to detect activity that is being tunneled over HTTP. When an HTTP proxy filters content, it can alert the web user that the site being visited sent the filtered content. The most prominent non-security benefit of HTTP proxies is caching web pages for increased speed and decreased bandwidth use. Most organizations should employ HTTP proxies.
Policies Based on User Identity
Traditional packet filtering does not see the identities of the users who are communicating in the traffic traversing the firewall, so firewall technologies without more advanced capabilities cannot have policies that allow or deny access based on those identities. However, many other firewall technologies can see these identities and therefore enact policies based on user authentication. One of the most common ways to enforce user identity policy at a firewall is by using a VPN. Both IPsec VPNs and SSL VPNs have many ways to authenticate users, such as with secrets that are provisioned on a user-by-user basis, with multi-factor authentication (e.g., time-based cryptographic tokens protected with PINs), or with digital certificates controlled by each user. NAC has also become a popular method for firewalls to allow or deny users access to particular network resources. In addition, application firewalls and proxies can allow or deny access to users based on the user authentication within the applications themselves.
Firewalls that enforce policies based on user identity should be able to reflect these policies in their logs. That is, it is probably not useful to only log the IP address from which a particular user connected if the user was allowed in by a user-specific policy; it is also important to log the user’s identity as well.
Policies Based on Network Activity
Many firewalls allow the administrator to block established connections after a certain period of inactivity. For example, if a user on the outside of a firewall has logged into a file server but has not made any requests during the past 15 minutes, the policy might be to block any further traffic on that connection. Time-based policies are useful in thwarting attacks caused by a logged-in user walking away from a computer and someone else sitting down and using the established connections (and therefore the logged-in user’s credentials). However, these policies can also be bothersome for users who make connections but do not use them frequently. For instance, a user might connect to a file server to read a file and then spend a long time editing the file. If the user does not save the file back to the file server before the firewall-mandated timeout, the timeout could cause the changes to the file to be lost.
Some organizations have mandates about when firewalls should block connections that are considered to be inactive, when applications should disconnect sessions if there is no activity, etc. A firewall used by such an organization should be able to set policies that match the mandates while being specific enough to match the security objective of the mandates.
A different type of firewall policy based on network activity is one that throttles or redirects traffic if the rate of traffic matching the policy rule is too high. For example, a firewall might redirect the connections made to a particular inside address to a slower route if the rate of connections is above a certain threshold. Another policy might be to drop incoming ICMP packets if the rate is too high. Crafting such policies is quite difficult because throttling and redirecting can cause desired traffic to be lost or have difficult-to-diagnose transient failures.
46. Explain with diagram IT security requirements.
All security solutions should be designed with two focus areas; the functional requirements of the solution, and the assurance requirements that the func-tional solution is working correctly. No solution is complete unless it addresses both of these two areas. For example: a complete "firewall solution" would be having the firewall han-dling traffic and denying or permitting access correctly—the functional requirement—and, the "logging and monitoring" aspect addressing the assurance requirements of the firewall solution by ensuring that the firewall is working properly and providing the expected level of protection in relation to the risks that the firewall was intended to control.
Functional Requirements—
Functional requirements are the things most often thought about when consid-ering security controls. The risk assessment provides the considerations for functional controls. We will talk about thiseTngfeater detail on later slides. • They should be layered and meet a specific security requirement.
• They should not be depend on another control.
• They should fail safe, that is that, in the event of a failure, they maintain the security of the systems.
Assurance Requirements—
Assurance mechanisms confirm that security solutions are selected appropri-ately, performing as intended, and are having the desired effect. Many assurance mechanisms will be reviewed throughout this course within their respec-tive domains i.e., IDS's, Audit logs, BCP Tests, etc. However, some are applicable especially to the area of IT security, such as internal and external audits.
Some criteria are used to evaluate the operation of security solutions:
• Internal/External Audit Reports.
• IIA's Red Book, Yellow Book, etc. (the Institute of Internal Auditors, www.theiia.org).
• Periodic Review by Management.
• Security Reviews (Internal), Checklists, Supervision.
• Third Party Reviews.
• Attack and Penetration Tests .
• Policy Review .
• Threat Risk Assessments.
47. What should be considered in the planning stages of a Web server?
In the planning stages of a Web server, the following items should be considered
¬ Identify the purpose(s) of the Web server.
• What information categories will be stored on the Web server? ƒ
• What information categories will be processed on or transmitted through the Web server?
• What are the security requirements for this information?
ƒ • Will any information be retrieved from or stored on another host (e.g., back-end database, mail server)? ƒ
• What are the security requirements for any other hosts involved (e.g., back-end database, directory server, mail server, proxy server)? ƒ
• What other service(s) will be provided by the Web server (in general, dedicating the host to being only a Web server is the most secure option)? ƒ
• What are the security requirements for these additional services?
ƒ • What are the requirements for continuity of services provided by Web servers, such as those specified in continuity of operations plans and disaster recovery plans?
ƒ • Where on the network will the Web server be located?
¬ Identify the network services that will be provided on the Web server, such as those supplied through the following protocols:
• HTTP
• HTTPS
• Internet Caching Protocol (ICP)
ƒ • Hyper Text Caching Protocol (HTCP)
ƒ • Web Cache Coordination Protocol (WCCP)
ƒ • SOCKS
• Database services (e.g., Open Database Connectivity [ODBC])
¬ Identify any network service software, both client and server, to be installed on the Web server and any other support servers.
¬ Identify the users or categories of users of the Web server and any support hosts.
¬ Determine the privileges that each category of user will have on the Web server and support hosts.
¬ Determine how the Web server will be managed (e.g., locally, remotely from the internal network, remotely from external networks).
¬ Decide if and how users will be authenticated and how authentication data will be protected.
¬ Determine how appropriate access to information resources will be enforced.
¬ Determine which Web server applications meet the organization’s requirements. Consider servers that may offer greater security, albeit with less functionality in some instances. Some issues to consider include—
• ƒ Cost
ƒ • Compatibility with existing infrastructure
• Knowledge of existing employees ƒ
• Existing manufacturer relationship
ƒ • Past vulnerability history ƒ
• Functionality.
¬ Work closely with manufacturer(s) in the planning stage.
48. What are the steps for securely installing web server?
In many respects, the secure installation and configuration of the Web server application mirrors the OS process. The overarching principle, as before, is to install only the services required for the Web server and to eliminate any known vulnerabilities through patches or upgrades. Any unnecessary applications, services, or scripts that are installed should be removed immediately once the installation process is complete. During the installation of the Web server, the following steps should be performed:
• Install the Web server software either on a dedicated host or on a dedicated guest OS if virtualization is being employed.
• Apply any patches or upgrades to correct for known vulnerabilities.
• Create a dedicated physical disk or logical partition (separate from OS and Web server application) for Web content.
• Remove or disable all services installed by the Web server application but not required (e.g., gopher, FTP, remote administration).
• Remove or disable all unneeded default login accounts created by the Web server installation.
• Remove all manufacturers’ documentation from the server.
• Remove all example or test files from the server, including scripts and executable code.
• Apply appropriate security template or hardening script to server.
• Reconfigure HTTP service banner (and others as required) not to report Web server and OS type and version (this may not be possible with all Web servers).
Organizations should consider installing the Web server with non-standard directory names, directory locations, and filenames. Many Web server attack tools and worms targeting Web servers only look for files and directories in their default locations. While this will not stop determined attackers, it will force them to work harder to compromise the server, and it also increases the likelihood of attack detection because of the failed attempts to access the default filenames and directories and the additional time needed to perform an attack.
49. Sate and explain any 4 Wireless Standards.
In 1997, IEEE ratified the 802.11 standard for WLANs. The IEEE 802.11 standard supports three transmission methods, including radio transmission within the 2.4 GHz band. In 1999, IEEE ratified two amendments to the 802.11 standard—802.11a and 802.11b—that define radio transmission methods, and WLAN equipment based on IEEE 802.11b quickly became the dominant wireless technology. IEEE 802.11b equipment transmits in the 2.4 GHz band, offering data rates of up to 11 Mbps. IEEE 802.11b was intended to provide performance, throughput, and security features comparable to wired LANs. In 2003, IEEE released the 802.11g amendment, which specifies a radio transmission method that uses the 2.4 GHz band and can support data rates of up to 54 Mbps. Additionally, IEEE 802.11g-compliant products are backward compatible with IEEE 802.11b-compliant products. Table 2-1 compares the basic characteristics of IEEE 802.11, 802.11a, 802.11b, and 802.11g. 802.11 wireless networking is also known as Wi-Fi ®.
The IEEE 802.11 variants listed in Table 2-1 all include security features known collectively as Wired Equivalent Privacy (WEP) that are supposed to provide a level of security comparable to that of wired LANs.IEEE 802.11 configurations that rely on WEP have several well-documented security problems. The IEEE acknowledged the scope of the problems and developed short-term and long-term strategies for rectifying the situation. In June 2004, the IEEE finalized the 802.11i amendment, which is designed to overcome the shortcomings of WEP. IEEE 802.11i specifies security components that work in conjunction with all the IEEE 802.11 radio standards, such as IEEE 802.11a, 802.11b, and 802.11g; any future 802.11 physical layer will also be compatible with 802.11i.
No comments:
Post a Comment