Although virtually every system software vendor will claim its product is secure, some products are designed to be more secure than others. For instance, some products differentiate the tasks that need to be performed by an administrator from those that are
governments), such an undertaking is likely to be cost prohibitive. To mitigate this problem, the security industry has developed a common criteria for evaluating the inherent security of software products. The goal of the common criteria is to allow certified testing labs to independently evaluate, or certify, software products against an industry-standard criteria, thereby allowing potential users of the software to determine the level of security a product provides, without each user having to individually evaluate each tool.
SECURITY CERTIFICATION HISTORY
Circa 1985, the U.S. Department of Defense (www.defenselink.mil) defined seven levels of system software security, A1, B1, B2, B3, C1, C2, and D1 (A1 being the highest level of security), for the purpose of providing a common set of guidelines for evaluating the security of software products from different vendors. The exact criteria used to assign products to different levels were spelled out in a document commonly referred to as the Orange book. During the early 1990s several European governments jointly developed a European equivalent of the Orange book. These guidelines were called the European Information Technology Security Evaluation and Certification Scheme, or ITsec (see www.cesg.gov.uk/assurance/iacs/itsec/).
Both sets of guidelines have been superseded by a new set of general concepts and principles developed under the auspices of the International Organization for Standardization (www.iso.ch). This new standard (ISO 15408) is being referred to as the Common Criteria for Information Technology Security Evaluation, or Common Criteria (CC) for short.
Although comparatively few products have currently completed the evaluation process, the common criteria is becoming more widely recognized, which in turn should lead to more products being submitted for testing. Additional information about the common criteria and the status of the products that have been or are in the process of being evaluated can be found at www.commoncriteria.org.
Patching
The early versions of system software products used to support Web sites often contained obscure security holes that could potentially be exploited by a knowledgeable attacker. Thanks to an army of testers that knowingly (or unknowingly) tested each new version of software before and after its release, the later releases of these products have become much more secure. Unfortunately, more is a relative term; many of these products still have well-documented security vulnerabilities that, if not patched, could be exploited by attackers who have done their homework.
If a security issue with a particular version of a system software product exists, typically the product's end-users can't do much about it until the developers of the product (vendor or open-source collaborators/distributor) are able to develop a patch or workaround. Fortunately, most high-profile system software vendors are particularly sensitive to any potential security hole that their software might contain and typically develop a fix (patch) or workaround very quickly.
System software patches are only useful if they are actually installed. Therefore, rather than actually testing the product itself for as-yet-undiscovered security holes, the security-testing team would be much better advised to review the work of others to determine what known security issues relate to the products used on the Web site under testing. A common, manual approach to researching known security issues is to view entries on online bug- tracking forums or incident response centers such as those listed in Table 4.2. In addition,
many vendors also post up-to-date information on the status of known security defects (sometimes referred to by vendors as features) and what the appropriate fix or workaround is on their own Web site.
Table 4.2: Web Sites of Bug- and Incident-Tracking Centers
WEB SITE NAME WEB ADDRESS
CERT® Coordination Center www.cert.org Computer Incident Advisory Capability (CIAC) www.ciac.org Computer Security Resource Center (CSRC) http://csrc.nist.gov Common Vulnerabilities and Exposures (CVE) www.cve.mitre.org Federal Computer Incident Response Center
(FedCIRC)
www.fedcirc.gov Information System Security www.infosyssec.com Internet Security Systems™ (ISS) www.iss.net
National Infrastructure Protection Center (NIPC)
www.nipc.gov
NTBugtraq www.ntbugtraq.com
Packet Storm http://packetstorm.decepticons.org
System Administration, Networking, and Security (SANS)
www.sans.org
Security Bugware www.securitybugware.org
SecurityFocus (bugtraq) www.securityfocus.com
SecurityTracker www.securitytracker.com Vmyths.com www.vmyths.com Whitehats www.whitehats.com Windows and .NET Magazine Network www.ntsecurity.net
In addition, many vendors also post up-to-date information on the status of known security defects (sometimes referred to by vendors as features) and what the appropriate fix or workaround is on their Web site.
OPEN-SOURCE VERSUS CLOSED-SOURCE DEBATE
A debate still exists as to whether a proprietary (closed-source) product such as Windows is more or less secure than an open-source product such as Linux or OpenBSD. Open-source advocates claim that a product is much less likely to contain security holes when the source
Different vendors use different terms to describe their software upgrades. Often these names are used to infer that different degrees of regression testing have been performed prior to the upgrade being released. The situation isn't helped when the vendor offers such generic advice as "this upgrade should only be installed if necessary." Therefore, before installing any upgrade, try to determine what level of regression testing the vendor has performed. An organization should consider running its own tests to verify that upgrading the latest version will not cause more problems than it fixes. For example, an upgrade fixes a minor security hole, but it impacts an application's performance and functionality.
Instead of manually researching all the security holes and nuances of a system software product, the security-testing team could utilize an automated security assessment tool or online service. Such a tool or service can be used to probe an individual machine or group of machines to determine what known security issues are present and remain unpatched. Table 4.3 lists some of the tools available for this task.
Table 4.3: Sample List of System Software Assessment Tools
NAME ASSOCIATED WEB SITE
HFNetChk and Personal Security Advisor www.microsoft.com
Hotfix Reporter www.maximized.com
Internet Scanner www.iss.net
Nessus www.nessus.org Quickinspector www.shavlik.com
Security Analyzer www.netiq.com
Titan www.fish.com Whichever approach is used, the goal is typically not to find new system software defects,
but to ascertain what (if any) security patches or workarounds need to be implemented in order to mitigate existing problems.
For some organizations, installing patches every couple of weeks on every machine in the organization may consume an unacceptable amount of resources. For instance, a risk- adverse organization may want to run a full set of regression tests to ensure that the functionality of any existing application isn't altered by the workaround, or that the Web site's performance isn't noticeably degraded by a new patch. In some instances, a patch may even turn on features that have previously been disabled or removed, or it may alter existing security settings. Security policies should therefore be reviewed to ensure that they describe under what circumstances a patch or workaround should be implemented and what regression tests should be performed to ensure that any newly installed patch has not unknowingly changed any security configuration setting or otherwise depreciated the capabilities of the Web site.
Table 4.4 lists a series of checks that could be utilized to evaluate how well security patches are being implemented.
Table 4.4: System Software Patching Checklist YES NO DESCRIPTION
Table 4.4: System Software Patching Checklist YES NO DESCRIPTION
□ □ Is there a documented policy in place that describes under what circumstances and how a security patch should be implemented? (This is especially important when multiple patches are to be applied, as the installation order may be critical.)
□ □ Have all the known security issues for each system software product that is or will be used by the Web site been researched and documented? (The research should include evaluating any consequences of installing the patch.)
□ □ Have all the security patches deemed necessary by the documented policy been obtained from a legitimate source? (It's not unheard of for a supposed security patch to actually contain a Trojan horse.)
□ □ Have tests been designed that can demonstrate the existence of the security hole(s) that needs to be patched? (This is necessary if confirmation is needed that the security hole has indeed been fixed by the correct application of the patch.)
□ □ Have all the security patches and workarounds deemed necessary by the policy been implemented on every affected machine?
□ □ In the event an issue is discovered with a newly installed patch, is a process in place that would enable the patch to be rolled back (uninstalled)?
□ □ Is the person(s) responsible for monitoring new security issues aware of his or her responsibility and does he or she have the resources to accomplish this task?