What You Can Do #1:
Enforce High Encryption Cipher
When an SSL handshake occurs between a client and server, a level of encryption is determined by the browser, the client computer operating system, and the SSL Certificate. Low-level encryption, 40 or 56 bits, is acceptable for sites with low-value information. However, a hacker with the time, tools, and motivation can crack the code in a matter of minutes.
Disable support for LOW encryption ciphers. High-level encryption, at 128 bits, can calculate 288 times as many combinations as 40-bit encryption. That’s over a trillion times a trillion times stronger. That same hacker with the same tools would require a trillion years to break into a session protected by an SGC-enabled certificate.
How to Improve:
It is highly recommended to install a unique certificate on each server to activate 128-bit or stronger encryption using an SGC-enabled SSL Certificate, such as VeriSign Global Secure ID (128-bit Compulsory). A unique certificate on each server helps reduce the risk of single point of private key compromise. An SGC-enabled certificate ensures that almost every site visitor, no matter what browser or operating system they use, will get connected at the highest encryption level.
Many millions of Internet users worldwide still use browsers that will not connect at 128-bit encryption unless there is an SGC-enabled certificate on the server. These browsers include certain Internet Explorer browser versions from 3.02 to 5.23, Netscape browser versions from 4.02 to 4.72. Browser versions prior to these are not capable of 128-bit encryption with any SSL Certificate. Even many Windows 2000 systems using Internet Explorer browser will fail to step up to 128 bits regardless of the version of Internet Explorer they're running.
Subject to the browsers used, non-SGC SSL certificates in many cases encrypt at 40 or 56-bit strength while its CAs may claim to offer “128-bit certificates”, but they do not offer 128-bit SSL encryption to the most possible site visitors.
Web sites accepting credit cards for on-line payment, handling personal privacy data or transmitting confidential information should offer 128-bit or stronger encryption protection to their site visitors.
What You Can Do #2:
Manage Security Patch Updates
5 of the top 10 vulnerabilities are mainly the consequence of out-dated patching or users’ negligence in following guideline. The following suggest how they can be addressed.
Vulnerability:
Web Server HTTP Trace/Track Method Support Cross-Site Tracing Vulnerability - Solution for some of the common Web Servers are given below. For example:
| Apache: |
Recent Apache versions have a Rewrite module that allows HTTP requests to be rewritten or handled in a specific way. |
| Microsoft IIS: |
Microsoft released URLScan, which can be used to screen all incoming requests based on customized rulesets. URLScan can be used to sanitize or disable the TRACE requests from the clients. |
| SunONE/iPlanet Web Server: |
SUN recommends to disable the trace method. |
Vulnerability:
TCP Sequence Number Approximation Based Denial of Service – The Internet Engineering Task Force (IETF) has developed an Internet-Draft titled Transmission Control Protocol Security Consideration that addresses this issue For example, BGP-specific workaround information has also been provided in the draft.
Vulnerability:
WebDAV HTTP Method ‘PROPFIND’ Enabled – To disable WebDAV, please refer to Microsoft article "How to Disable WebDAV for IIS 5.0" for complete information.
Vulnerability:
Netscape/OpenSSL Cipher Forcing Bug – The problem can be fixed by disabling one of the options (namely, SSL_OP_NETSCAPE_REUSE_ CIPHER_CHANGE_BUG) from the options list of OpenSSL’s libssl library
Vulnerability:
Microsoft IIS Internal IP Address/Internal Network Name Disclosure Vulnerability – Information about this vulnerability in Microsoft articles – Internet Information Server Returns IP Address in HTTP Header (Content-Location) and also Microsoft support hyperlinks.
No matter what platform is used, patch management policy should be developed in enterprise with a focus on reducing security vulnerabilities. It should not be a reactive procedure in response to incidents.
How to Improve:
Maintain a source of vulnerability information associated with each class of application and identify the staff primarily responsible for administering the application. A vulnerability alert list should be developed. Resources include:
| 1. |
Third-party vulnerability alert Web sites such as CERT Coordination Center (www.cert.org), and the SANS (System Administration, Networking, and Security) Institute (www.sans.org/sac) |
| 2. |
Vendor Web sites such as Microsoft, HP and Sun |
| 3. |
Vulnerabilities alert subscription service, charged or free. |
| 4. |
Automated vulnerability scanning tools for regularly monitoring the risks of your systems. |
How to Improve:
Additional support for managing vulnerabilities is available from vendors. For example, Microsoft has developed a variety of tools to scan, assess, and update their products. Sun Microsystems has developed the Patch Manager utility to scan Solaris 9 operating systems, identify vulnerabilities, and automatically download and install needed patches. However, care must be taken with all such tools, because side effects might results in other applications that interoperate with the newly patched application.
How to Improve:
Regular health check your server. Enterprises need to focus on vulnerability management because the problem exists before the patches are available.
Vulnerabilities with Patch Available – Vendor are often under significant pressure to release patch as soon as possible. Before applying new patches to production environment, test should be conducted in a non-production environment to assess its effectiveness as well as side effects. As a low-cost alternative, some enterprises wait a few days to collect early adoptors' feedback and comments before installing patches.
Vulnerabilities with NO Patch Available – Preventive measures include disabling certain services or functions, close monitoring to detect or thwart actual attacks via an intrusion detection and prevention system.
How to Improve:
Standardize client and server operating systems. Operating system standardization should be introduced as part of a timed refresh of the client installed base. This type of standardization also provides substantial benefits beyond the patch management process.
How to Improve:
Establish processes and benchmarks. Establish processes that will track patching effort and map results against company and industry benchmarks. Create straightforward, high level patching performance reports, distribute them widely, and show the patch management improvement through time.
How to Improve:
Consolidate hardware configurations. Reducing the number of hardware configurations from 50 to 25 can reduce the overall time to deploy patches and other minor updates by as much as 50 percent.
Next: What You Can Do #3
- Harden New Servers >>
|
