Determine necessary information including
• Who needs access to what services, applications and data.
• From where must the access come, outside or inside?
• When does the access need to be available? Business hours? After hours?
• What information are you trying to protect? You need to know what you're trying to protect before you can put policies into place. This should be a detailed analysis. If you have multiple business partners and customers, you'll need to ensure customer separation so customer X can't access information confidential to customer Y.
There are plenty of models you can use to create these policies, including the Biba Integrity Model and the Clark-Wilson Integrity Model. Even if you don't subscribe to a particular methodology, however, be sure the policy is documented and accessible to the technologists in your organization who will need to reference it during implementation and deployment.
Once the policy is in place, schedule regular reviews of the policy and the tools that assist in securing your infrastructure. At a minimum, review your policies and your effectiveness in enforcing those policies once a quarter.
|
Glossary
• APS (Application Protection System): Software that works with firewalls and intrusion-detection systems, analyzing HTML and HTTP traffic for signs of malicious intent.
• HSM (Hardware Security Module): Peripheral within a smartcard infrastructure that provides a secure site for encrypting and transmitting data.
|
SSL To the Rescue?
Some companies mistakenly believe that SSL (Secure Sockets Layer) will mitigate all security risks. Although SSL is great for ensuring that no one eavesdrops on your business transactions, unless you're using client certificates as a part of your SSL strategy, you aren't gaining much except a security blanket for your transactions while they're in transit. Client-side certificates provide a more credible authentication scheme than user-name and password combinations do. Requiring client certificates for access makes it more difficult for someone to impersonate an authorized user, providing a higher level of security by ensuring that you know who is attempting to access your data (for more on SSL connections, see Featue "The Anatomy of an SSL Handshake").
SSL-based communication can inhibit other parts of your security strategy. Most IDS (intrusion-detection system) and virus-scanning services can't interact with SSL, so encrypted traffic is allowed to pass without question. What's needed is a slightly different architecture, one that provides a mechanism that allows encrypted traffic to be inspected by your edge-protection devices before it's passed further into your back-end infrastructure. Two physical connections are made for every logical connection. The client connects to the device, and a separate connection from the device to the server is made to fulfill any client requests.
Such an architecture is often called a co-appliance or side-arm configuration. By using a traffic-management device--usually a load-balancer--you can provide a method by which you can follow those security policies you so painstakingly created (see graphic "Web Infrastructure in a Side-Arm Configuration").
In this configuration, SSL-encrypted traffic is decrypted by first directing the traffic to the SSL appliance so it can be checked by the IDS and virus-scanning services. Once it passes through this outer crust, it's passed back to the load-balancer/content switch and on to your servers.
Another way to provide this functionality is by ensuring that your traffic director can terminate SSL sessions. The device serving as your traffic director would be configured as a reverse proxy for SSL connections, handling all encryption and decryption services between itself and the client. This removes the need for an external SSL appliance but introduces additional issues: If you use the client certificates to authorize access, they will be authenticated by the traffic-management device, not your application servers, unless you're using a traffic manager capable of inserting the user credentials into the HTTP header, such as F5 Networks' Big-IP (see Sneak Preview "Big-IP 5000 Switch Marks New Territory for F5 Networks").
Some industries need to continue SSL sessions all the way to the back-end Web servers. Financial and banking institutions, in particular, fall under stringent security regulations that require all transactions be encrypted regardless of whether they are internal or external. If this is a requirement for your business, you must ensure that your traffic director can terminate the SSL session with the client, and initiate SSL connections with devices deeper in your infrastructure. This type of configuration has an added benefit if your traffic director can use client certificates, which provide protection by offering a more secure method of identification. This isn't a perfect solution--certificate stores are often kept on disk and could be stolen--but it's more secure than nothing. If you go with this option and require a client certificate to connect to your back-end servers, you can prevent direct connections from the outside to your servers.
RSS
