patch management - tech...

Patchmanagement

a Practical guide to Building an effective Patch management Process

march 2008

contents

introduction 3

section 1 achieving management suPPort 4

section 2 forming the Patch and vulneraBility grouP 6

section 3 identifying vulneraBilities and Patches 10

section 4 Patching Process 12

section 5 validating Patches 13

section 6 summary 14

aPPendices

A: security tools 15

B: internet resources 16

A PrActicAl Guide to BuildinG An effective PAtch MAnAGeMent Process

3MArcH 2008

section 1

introduction

Policies and procedures provide the framework to successfully implement and maintain organizational actions – specific to information system vulnerabilities and security patching, effective policies and procedures provide this framework to support initiatives and actions to secure and keep secure affected systems. the process under which these actions occur is called patch management. timely patching of every organization’s information technology systems is critical to maintaining the operational availability, confidentiality, and integrity of information assets. Failure to keep operating system and application software patched increases the potential risk of serious financial, legal and reputation losses due to information compromise. Losses may result if such assets are compromised as a result of a Internet worm, virus outbreak, or a hacker gaining access through exploitation of unpatched (or otherwise poorly-protected) system vulnerabilities. For an organization to succeed at effectively managing its system patching, executive management, working with security managers who operate the program, must initiate and support an organization-wide Security Vulnerability and Patch Management Program. This document presents the essential elements for an effective Security Vulnerability and Patch Management Program.

PurPose

This guide will assist individuals who have been assigned the task or have identified the need to establish a patch management strategy. It details methods and approaches to effectively implement a sound patch management process. As stated in section 2.0, executive support for these programs is absolutely critical to insure their operational success.

scoPe

Information systems provide a critical asset to today’s key business functions -- this document is intended for all persons assigned the responsibility to properly maintain and secure these systems for the organization. The following describes an industry best practice approach to managing security vulnerabilities and patches. This document does not address specific patches or vulnerabilities or how systems with vulnerabilities specifically might be protected beyond installing the appropriate patch.

oBjective

this document provides advice on managing the patching process for information systems with the goal of improving security to information systems.

Audience And AssuMPtions

this guide provides details to meet the patch management needs for an organization; interested individuals performing some, all, or a portion of the following roles can benefit from this guide: > system administrators > it managers > security professionals > Critical business unit managers > Other staff members charged with the responsibility of managing and securing information systems


4MArcH 2008

Secondly, the guide provides a structured approach to implementing security patches with the end goal of mitigating risk through eliminating vulnerabilities. Overall, the guide presents guidance and procedures towards implementing an effective patch management process. Furthermore, the content illustrates patch management so that management may use this guide as a framework to educate employees and staff members on proper control and mitigation of vulnerability risks within information systems. The content provided is operating system-neutral and presents industry best practices rather than a specific method of implementation.

section 2

achieving management suPPort

Prior to implementing any organizational security initiative, executive support must be gained for the project. Without such support, efforts carry none of the weight of other organizational requirements. If such support does not exist in the organization, executive support must be sought. Prior to obtaining support, one must build a strong case to present to executive management. Building a strong business case permits the best method to addressing the needs of executives – proving that patch management directly impacts the bottom line. Obtaining executive support increases the chances for success of an effective patch management program. Available executive support provides the necessary backbone for ongoing patch management efforts.

Building tHe Business cAse

Building a business case for patch management is the most crucial step to obtaining executive support. Executives require the cost versus benefit of any initiative and how the initiative impacts the business’s bottom line. The following flow-chart illustrates a recommended approach to building a strong case for patch management and vulnerability risks.


5MArcH 2008


6MArcH 2008

After gathering the needed information for the business case, compile all information by placing emphasis on the strongest business rationale for a patch management process. Concisely present the business case limiting it to no more than one page. Highlight top critical findings revealed from the assessment as outlined above. An unpatched vulnerability can result in loss of customer confidence, productivity and legal ramifications if not properly resolved. The overall cost to a successfully exploited vulnerability can easily exceed the cost of patching against the vulnerability. Examples of these costs include some of the following:

Business cost exAMPle vulnerABility risk iMPActs

Loss Of Customer Confidence > Impact to customer confidence if e-commerce was unavailable for hours or even days.

> Inability of a sales department to process orders and check inventory quickly and efficiently.

loss of Productivity > Blaster virus (2003) takes organization infrastructure for days (patching would have prevented).

Legal Ramifications > guaranteed service delivery contract not met – lawsuit follows.

By describing the potential number of vulnerable critical production servers and potential business losses, an executive will quickly begin to ascertain the risk that the organization may be facing. These risks posed by vulnerabilities must be defined as potential costs to the bottom line as quantitatively as possible.

section 3

forming the Patch and vulneraBility grouP

Once approval and support of executive management is obtained, form a Patch and Vulnerability Group (PVG) to define business-specific processes for addressing the patch management issues. The PVG’s primary function is to manage the assessment, testing, and remediation of vulnerabilities in the organization’s information systems. In addition, the group coordinates efforts with system administrators to measure the success of and improve the vulnerability and patch management process. duties of the Pvg include: > Identifying vulnerabilities > Assessing and prioritizing vulnerability risks > testing and certifying patches > Scanning for vulnerable systems > Patching vulnerable systems > verifying patch installation > Measuring the process

Depending on breadth of the organization’s workforce, representative personnel of the PVG should include: > desktop support > server Administrators > network Administrators > security Management > Non-Technical Business Representatives (e.g., Business Analysts)


7MArcH 2008

The business analyst, or equivalent, will provide insights to interrelated business processes, systems, and projects likely to be impacted by a potential patch or hot fix deployment. In addition, the role also provides a liaison between functional business units and the information technology departments. Create a charter for the group listing its prime focus, goals, and responsibilities. The following presents an example charter for the Patch and Vulnerability group:

PAtch And vulnerABility GrouP (PvG) chArter

Purpose Prepare policies, guidelines and direction for the purpose of facilitating patch deployment and remediation of vulnerabilities.

executive sponsors Mia Hamm (CIO) and Brett Favre (CFO)

scope / Boundaries > Patch and vulnerability management includes: > creating and maintaining a hardware and software inventory > Identifying newly-discovered vulnerabilities and security patches > Prioritizing patch application > Creating an organization-specific patch database > conducting generic testing of patches > Distributing patch and vulnerability information to local administrators > verifying patch installation through system scanning > communicating with system administrators for coordination of

patch prioritization and deployment > Performing automatic deployment of patches > Performing automatic update of applications

desired goals and outcomes

Through its efforts, the PVG will: > educate – provide information to server and network administra-

tors relating to current patch status, deployment schedule, and any conflicts that a patch may have on current systems;

> Research – assess potential vulnerabilities and their related risks; > Assess – determine patch effectiveness through vulnerability scans; > test – determine patch impacts and attempt to reduce to a

minimum the risks associated with systems where patching is not acceptable due to negative patch impacts;

> recommend – communicate the patch deployment schedule and a priority ranking system for systems to be patched (server, desktop or network);

> Administer – Create, implement, maintain, and review policy and procedures relating to the patch management process.

Authority this work group will: > Make recommendations to the technical Panel regarding policies

and guidelines for a secure patch and vulnerability management process.

> Identify problems and issues related to the current environment as it relates to vulnerabilities and risk levels.

Membership Facilitator – Neal Pert, Information Security Analyst Any member in the data security group or information technology support staff may participate in the work group, with permission from the Director of Security. Membership should not exceed fifteen representatives. The sponsor of the work group may solicit membership from varied departments, thereby providing a cross-section of perspectives and information.

reporting Each month, the PVG will deliver a monthly patch status and exposure report to the Audit committee and Pvg sponsors.


8MArcH 2008

MAnAging Business risks

The end result of PVG’s activities is a reduction in business risks through effective management. Business risks related to information systems are a result in part from possibility of exploitation of system vulnerabilities. Vulnerabilities exist in most operating systems and many applications in use today. Vulnerability can be defined as a weakness or flaw in an operating system, application or firmware that allows unintended modifications, access, information disclosure or denial of service to the vulnerable machine. Exploitation of the vulnerabilities will cause damage to the business that ultimately affects the bottom line. Diagram A below represents the vulnerability management lifecycle. diAgrAM A initial vulnerability Assessment

Initially, the PVG must assess the organization’s current exposure to known and documented vulnerabilities. Much of this information will come from the initial assessment used to build the business case for patch management policy (see section 2). A more thorough and detailed vulnerability assessment will fully define the current state of the enterprise. Bringing in a third party to perform a vulnerability assessment of the enterprise typically provides the quickest and most efficient method to determine information risk as it relates to the organization.

ongoing risk AssessMent Following this initial assessment, the level of risk posed by unpatched vulnerabilities should be assessed. Assessing potential business impacts posed by current vulnerabilities (and those in the future) will be an ongoing responsibility of the PVG. In relation to possible impacts, the PVG will need to coordinate with executive management on defining acceptable level of risk for the organization. Patching (or not patching) systems will directly relate to these agreed-upon acceptable risks within an organization.

coordinAting tHe vulnerABility And PAtcH MAnAgeMent Process

Four key groups combine their efforts for an effective patch management process including: > executive Management > Patch and Vulnerability Group (PVG) > system Administrators > Business groups or departments As described earlier, executive management provides support for the patch process and determines acceptable level of risk the business can tolerate. The PVG’s primary function is managing the assessment, testing, and remediation of vulnerabilities in the organization’s information systems. In addition, the PVG coordinates efforts


9MArcH 2008

with system administrators to measure the success of and improve upon the vulnerability and patch management process. To insure the patch process is completed, responsibilities and ownership related to the patching of specific systems must be assigned to system and/or network administrators. these personnel require representation within the Pvg so operational constraints receive consideration prior to deploying workarounds or patch fixes to vulnerable systems and services. System administrators will provide operational feedback to the PVG so that necessary adjustments can be made to the vulnerability and patch management process. System administrators’ surrounding patch management includes: > coordinate testing of patches with the Pvg. > inform the Pvg of patch failures. > Identify vulnerabilities and patches associated with software not monitored by the PVG. > Patch systems not monitored by the PVG.

Typically business groups understand department requirements and inter-related needs of their applications. Open lines of communication between business groups, system administrators, and the Pvg increases the potential for success (through understanding of system inter-relation) when applying a patch or implementing a workaround to vulnerabilities. These communications will also provide a more accurate picture and consistent approach in the PVG’s patch and vulnerability status report prepared for executive management.

executive management will rely on the patch status report for determining the risk level associated with the organization’s IT infrastructure. Validating risk and vulnerability levels is increasingly relevant to achieve compliance with federal regulations which mandate organizations to validate privacy protections and provide due diligence. Diagram B illustrates the vulnerability and patch management process from an operational viewpoint: diAgrAM B


10MArcH 2008

section 4

identifying vulneraBilities and Patches

Identifying vulnerabilities is the first step toward reducing the risks to systems from such weaknesses. Patching, when available, provides the simplest means to reduce the risks posed. Sometimes, however, mitigating risks associated with vulnerability may require a workaround instead of a patch. Vulnerabilities, as described above, consist of weaknesses in software exploitable by malicious or unintentional entities. These entities can exist as other applications, processes, worms, viruses, websites and users of information systems. Patches provide a fix to systems so the vulnerability can no longer be exploited.

Not all vulnerabilities have vendor-supplied patches available. In addition some patches will break critical business system functionality. For both cases, system administrators must deploy other means to protect systems from the risks (mitigate risks) posed by these vulnerabilities. Third party, security-related websites and email groups may suggest such other means. Potential non-patching methods of risk mitigation include specific firewall rules, router access control lists, Public Key Infrastructure (PKI), reducing or disabling server services, port redirection or application migration. Because patches are not always the means to mitigate risks, monitoring security references for patch information alone is not adequate; rather, one must maintain a vigilant watch for vulnerabilities in general. System administrators, information security analysts and information system managers can monitor and learn from a number of vulnerability references. Some of these channels include (see Appendix B for details): > Vendor websites and email notifications. > Third party websites such as security and system research groups. > third party mailing lists and newsgroups. > Vulnerability scanners. > Vulnerability databases. System administrators and information systems management likely belong to vendor mailing lists for products utilized in the organization’s environment. Many vendors provide free security and bug notification in their software through update features or email notification. Such mechanisms provide the simplest means to stay up-to-date on system vulnerabilities directly related to an organization’s systems. Prior to a vendor patch release (or if never released), using and joining a third party mailing list provides an excellent forum for possible workarounds. Frequently, researchers and security organizations post vulnerability information to public mailing lists. Typically disclosures occur after the vendor has been notified and allowed time to provide a patch or workaround to the vulnerability. In the case where the vendor does not supply the fix, the third party will typically release a notice to the public via mailing list. These lists also provide information about particular vulnerabilities a software vendor may not have advertised through a public announcement. If a vulnerability has been publicized through a third party source, the public announcement may also provide Proof of Concept (POC) code. This code can be leveraged by system administrators and security analysts to determine whether systems are vulnerable to attack. Always run POC code in a test environment so that damage can be isolated from any production network including the Internet; POC code may itself be an exploit. See Appendix B for a partial listing of third party security and bug tracking mailing lists.


11MArcH 2008

vulnerABility scAnners

Vulnerability scanners are the easiest and most popular tools for specifically identifying system vulnerabilities found in an organization’s infrastructure. Using the scanner results, system experts can assess the risks posed by discovered vulnerabilities. These scanners directly identify machines (sometimes called hosts) and other network devices containing known vulnerabilities. Information provided by scanning typically include identified machines, open ports on each machine, operating system type, and major active applications currently running on the target machine. A number of vulnerability scanners are available; they range widely in cost from free to over $1000. Key features typically associated with high cost scanners include report generation and database functionality. Appendix A provides a short list of free and commercial vulnerability scanners.

vulnerABility scAnning Best PrActices

To most effectively implement vulnerability scanning, the following common best practices must be followed. These practices prevent skewed results and alleviate avoidable problems. > Update the vulnerability database used by the scanner as frequently as possible prior to

performing any scans. Out-of-date vulnerability information will miss the most recent and most likely exploited vulnerabilities.

> Scan only production networks that are known to be stable, preferably during times of least impact to the critical functionality of the system.

> request permission from information system management prior to scanning any host on the target network.

> Inform system administrators prior to performing a vulnerability scan so systems can be moni-tored, adjusted, and/or corrected if problems occur due to a scan.

> Research and/or brainstorm potential negative impacts (e.g., scanning certain routers may cause a denial of service (dos).

> Prioritize network assets so scanning provides a snapshot that is both representative and high-lights the most critical network systems.

Assessing risks using scAn results

Vulnerability scanners provide the means to quickly view known security problems on the organization’s network infrastructure; these scanners however, do not quantify the overall risks posed by the vulnerabilities. Assessing such risks requires analysis of vulnerability reports by expert personnel within each functional area. The analysis by these personnel provides risks levels that the business requires to make decisions on mitigating or accepting the risks. These personnel might include network-specific, application-specific or operating system-specific administrators. Knowledge of the systems in question allows an expert assessment of risks posed by vulnerabilities discovered. This allows determination of the risk’s true impact. If a scan discovers numerous low-rated vulnerabilities, experts in each functional area can determine if these low-risk vulnerabilities pose a high-risk exposure. This detailed analysis provides accurate current risk levels. this also assists the Pvg in determining what patches to apply and how to most effectively mitigate risk that vulnerabilities introduce. The inclusion of results from the risk assessment provides important data to develop and implement a patch process which is designed to mitigate known vulnerabilities.


12MArcH 2008

A risk assessment will include a combination of the following concepts: > threat – an activity with the potential to cause damage. > Vulnerability – flaw, misconfiguration or weakness that allows security of a host to be

compromised. > Criticality – a measure of value that a host or asset has on the business. Balancing the possibility of threats discovered versus the value of the information assets gives the information required to compare the risks posed by various vulnerabilities.

section 5

Patching Process

Developing an effective patching process involves key activities beginning with: > Asset inventory > risk Assessment These activities should result from the previously-described case-building, PVG-forming, and vulnerability-scanning results and provide the greatest positive returns through synthesis of the collective data. To successfully implement a patching process, an inventory of assets and their rank in criticality must be established. If not complete from the case-building activities, complete the inventory of assets prioritized by business value. Taking into account: > Most critical business functions. > Most valuable business data. > Greatest business cost, if disrupted. A risk assessment should have been conducted in relation to the vulnerability scan results(Section 4). The risk assessment activities described in Section 4 should also be conductedon an ongoing basis as new vulnerabilities and patches become known and/or available. the patching process involves prioritizing systems most critical in relation to the magnitude of the vulnerabilities.

oBtAining PAtcHes or WorkArounds

Obtaining patches to mitigate the risks of vulnerabilities is typically available through system vendors. Vendors play a key role in providing patches that better secure the products they sell. Quite often, vendors ask for individuals to sign up for a product mailing list upon purchase to keep the customer abreast of updates and enhancements. Typically, email or website locations run by vendors provide links to download necessary patches for the vendor’s product. In addition, software vendors often provide website bulletins describing vulnerabilities with links to download a corresponding patch. When a vulnerability is discovered but a patch is not available, consult with third party references (described in Section 4) for other means to mitigate risks posed by the vulnerability. Such references may include forums, mailing lists, open-source projects and newsgroups (see Appendix B). Frequently, research groups provide a security fix or workaround to a discovered vulnerability (that remains un-patched or without a patch available). Obtaining advice, patches, or additional code through third party resources hinges on trust. Even for vendor-related patches (if obtained from a third party), the PVG must answer and obtain a consensus to the following questions:


13MArcH 2008

> According to the third party advisory, are we vulnerable? > Is the origin of the patch or method of workaround trustworthy? > What is the history of the group or individual? > Is the source code for the patch available for review? > Do we have the expertise to review the source code for any anomalies? > How critical is the system where the vulnerability exists?

validating Patches

No matter how the patch is obtained, some form of assurance must exist around the patch file’s integrity and that it addresses the vulnerability it purports to fix. Avoiding this validation phase will introduce excessive risk to the organization; introduction of possible exploits or additional vulnerabilities may result, which ultimately lead to business loss. careless acts are contrary to the goals of the Pvg. of greatest weight in assuring the patch is correct and original is the location from which it is downloaded. Going to a known, trusted source is one of the best methods to validating that a patch received is valid. However, this should not substitute authenticating the patch files once downloaded. Authentication must take place whenever possible. Additional security measures such as digital signatures on patch files may also provide assurance of the patch file’s integrity. Most reputable vendors provide or upon request will provide authentication mechanisms such as Message Digest 5 (MD5) checksums, PGP signatures or digital certificates. The most popular of the three is the use of MD5 checksums. An MD5 checksum produces a 128-bit one-way hash value. This means that the hash value cannot be reversed to produce the original data and the same hash value is not replicated for two separate messages or files. A second level of validation should occur with the use of a virus scanning engine. the virus scan database should be updated with the latest definitions and the patch file should be virus-scanned while isolated in a safe network location. this way if a virus is accidentally executed from the patch file, damage will be limited.

testing PAtcHes

When deploying a patch to a production environment, conduct patch deployment testing in an isolated environment prior to “going live” with the patch. Assess the impact of the patch on test systems that mimic the production systems as closely as possible.

Patches consist of nothing more than an additional piece of software that is developed to fix a problem. Typically, the patch file or files replace existing files to remove the vulnerabilities’ which reduces risk. From past experience with some patches, patches may break or alter system functionality needed by business-critical applications or services. After applying the patch, patch testers should try applications and test required services to verify that acceptable post-patch functionality exists. Assessment of post-patch functionality can also be tested through a review of system log files, searching for additional or unusual errors. To further validate patching, look at the files the patch was purported to update. Dates on the files should indicate either the date of patch application or the date of patch release. Following assessment of post-patch functionality and validity, assess the test system to verify that the patch indeed fixed the vulnerability. Vulnerability scanning of the test system should easily provide this information given that the scanner’s database contains the vulnerability in question. Use of multiple scanning tools provides even greater assurance of successful patching, if cross-validation between the tools indicates removal of the vulnerability in question. If the vulnerability is found not to have been resolved, review the patch instructions to verify the patch was applied correctly. If the patch was applied correctly, consult vendor support or newsgroups to determine if others have experienced similar issues. these sources may provide the means to successful patching. If not, these findings should be documented in the PVG summary report so future vulnerabilities or patches can be addressed with appropriate care.


14MArcH 2008

dePloying PAtcHes

deploying patches currently employs two methods: manually or automatically. it is assumed that either method follows thorough, non-production testing of patch deployment (Section 5). The most commonly used method for applying patches on UNIX-based systems and network devices is accomplished either manually or by upgrading to the patch branch of the OS version. UNIX systems incorporate numerous configuration variables that can make automatic patch deployment difficult. On the other hand, Microsoft Windows-based systems have multiple commercial and free tools available for automatic patch deployment and installation. For the most critical systems, best practice is to complete a full backup of the system prior to patching. Balance between the ease of system recovery following patching and ease (speed) of system backup must be achieved. Backups save time where rebuilding the system is required due patch corruption of the system. However, backups may require more time and effort than rebuilding the system from scratch following corruption by the patch. Manually installing patches on UNIX-based systems (including Linux®) typically involves compiling the patch source code and patching the application or kernel corresponding to the patch. in Microsoft Windows® systems, automated tools exist for patching operating system and application vulnerabilities. These tools are generally user-friendly and are easily-configured to effectively managing patch deployment.

VERIFyING PATCHES

Following the completion of the patch deployment stage (Section 5), one critical step remains – verification of successful patch deployment. As described for test systems (Section 5), assess the patched systems to verify that the patch elimited the vulnerability. Vulnerability scanning of patched systems should easily provide this information provided the scanner’s database contains the vulnerability of interest. Use of multiple scanning tools provides even greater assurance of successful patching; cross-validation between tools indicates removal of the vulnerability of interest.

section 6

summary

Patch and Vulnerability Management is a process that decreases the overall information technology risks to an organization, if effectively implemented. The key element to any patch process and vulnerability management program is executive management support. Obtaining support for a Patch and Vulnerability Group (PVG) protects the business and provides due diligence for federal mandates that organizations must adhere to. Following the formation of the PVG, the patch management process can be directed and managed at the operational level. The PVG will provide the framework and define the relationships and roles between technical and business personnel. Using this framework, patch and vulnerability management will proceed with its goal of reducing information technology risks to the business. It is essential to place emphasis on communication between functional groups to convey obstacles, constraints and conflicts when applying patches on the information systems. Communication, patch testing and deployment must be managed and controlled. In doing so provides a productive environment that supports the required due diligence towards an organization’s information integrity, confidentiality and availability.


15MArcH 2008

aPPendix a: security tools

the following is a list of some of the most popular tools used for security testing and analysis. this list groups tools according to testing and analysis methodologies. note that the listed tools also perform security auditing functions and should be used only with proper approval from the owner of the tested machine.

INFORMATION GATHERING

cheops – Network User Interface, plots out your network in a graphical image. Current source code is for linux only. url: http://www.marko.net/cheops/ nmap – Network scanning, port scanning and OS detection. url: http://www.insecure.org/nmap/index.html hping – Command-line oriented TCP/IP packet assembler/analyzer. url: http://www.hping.org/ netcat - Unix utility which reads and writes data across network connections, using TCP or udP protocols. url: http://netcat.sourceforge.net/ (Gnu version) firewalk - Determining firewall ACLs and traffic rules. URL: http://www.packetfactory.net/projects/firewalk/ ethereal - Monitoring and logging return traffic from maps and scans. url: http://www.ethereal.com/ ettercap – Terminal based network sniffer, interceptor and logger for switched LAN environments. url: http://ettercap.sourceforge.net/ tcpdump – Dumps traffic on a network for further analysis. url: http://www.tcpdump.org/ icmpquery - determining target system time and netmask on uniX systems. url: http://packetstormsecurity.com/unix/scanners/

superscan – Powerful connect-based TCP port scanner, pinger and hostname resolver. URL: http://www.snapfiles.com/get/superscan.html rAt – Benchmark and Audit tool for cisco ios routers url: http://www.cisecurity.org/bench_cisco.html

vulnerABility detection

dell Patch Management - The Dell Patch Management software service enables the distribution of Windows and Office patches consistent with IT and business policies. Dell’s on-demand Patch Management software solution utilizes the Dell Control Center --- our centralized, easy-to-use management platform --- to enhance the ability of IT to respond to software vulnerabilities in a timely manner by controlling when patches are applied. url: http://www.dell.com/desktopmanager Microsoft® MBsA - graphical and command line interface that can perform local or remote scans of Windows systems and report vulnerabilities url: http://www.microsoft.com/technet/security/tools/mbsahome.mspx


16MArcH 2008

nessus – Remotely audit a given network for vulnerabilities url: http://www.nessus.org/ sArA – The Security Auditor’s Research Assistant; UNIX-based security analysis tool url: http://www-arc.com/sara/ Whisker/libwhisker – CGI and Web vulnerability scanner url: http://www.wiretrip.net/rfp/p/doc.asp?id=21&iface=2

PenetrAtion tools

Brutus – Telnet, FTP and HTTP Password cracker url: http://www.hoobie.net/brutus cain & Abel – Password recovery tool for Microsoft® operating systems url: http://www.oxid.it/cain.html dsniff - A suite of powerful network auditing and penetration-testing tools url: http://naughty.monkey.org/~dugsong/dsniff/

MiscellAneous

Pstools – enhanced Microsoft® Windows tools to manage, audit and test Windows systems both locally and remotely. url: http://www.sysinternals.com/ntw2k/freeware/pstools.shtml

aPPendix B: internet resources MAiling lists PatchManagement.org This list discusses the how-to’s and why’s of security patch management across a broad spectrum of Operating Systems, Applications, and Network Devices.url: http://www.patchmanagement.org/faqs.asp Bugtraq A moderated mailing list for the *detailed* discussion of computer security vulnerabilities: what they are, how to exploit them, and how to fix them.url: http://www.securityfocus.com/archive security Management A forum established for the discussion of information security program management as a critical business support process. url: http://www.securityfocus.com/archive Microsoft Security Notification Service This is a free e-mail notification service that Microsoft uses to send information to customers about the security of Microsoft products. url: http://www.microsoft.com/technet/security/bulletin/notify.mspx

for more information: www.dell.com/desktopmanager

Specifications are subject to change without notice.

6591 dumbarton circle, fremont, ca 94555 · 888.307.7299/fax 510.818.5510

WeB sites dell.com/desktopmanager: Experience unprecedented control and unparalleled visibility of your desktop and laptop systems. Click “Try” for a FREE 30-day Test Drive of Dell’s innovative on-demand services –Patch Management, Asset Management, Software Distribution, Virus Protection, Online Backup and more. url: http://www.dell.com/desktopmanager Windowsupdate.Microsoft.com: This is Microsoft’s automatic update website designed to automatically scan Microsoft software and look for updates. this site is useful for checking local machines and highly effective for the home user. url: http://windowsupdate.microsoft.com

sAns.org: Provides a host of information security resources including sample policies, scoring tools, student case studies and a Top 20 vulnerability list with much more content available. url: http://www.sans.org/resources/ insecure.org: Homepage for the network scanner called “nmap”. the site also provides a top 75 list of security tools and a quick summary of what each tool is designed to do. url: http://www.insecure.org searchsecurity.org: general information security news site that also provides information on latest vulnerabilities, exploits and security tips. url: http://searchsecurity.techtarget.com/ cert.org: A major reporting center for Internet security problems. The staff members at CERT coordinate responses to security compromises, identify intrusion trends and work with other security experts to identify resolutions to identified security problems. url: http://www.cert.org/ cisecurity.org: This site is a non-profit organization that provides an array of operating system benchmarking tools designed to assist businesses in reducing disruptions as a result of security weaknesses. url: http://www.cisecurity.org/ nist.gov: is a non-regulated federal agency designed to develop and enhance standards and technology with the end goal of improving the quality of life. url: http://www.nist.gov/

aBout dell

dell inc. (nAsdAQ: dell) listens to customers and delivers innovative technology and services they trust and value. Dell is a leading global systems and services company and No. 34 on the Fortune 500.

THIS CASE STUDy IS FOR INFORMATIONAL PURPOSES ONLy, AND MAy CONTAIN tyPogrAPHicAl errors And tecHnicAl inAccurAcies. tHe content is PROVIDED AS IS, WITHOUT EXPRESS OR IMPLIED WARRANTIES OF ANy KIND.

Other trademarks and trade names may be used in this document to refer to either the entities claiming the marks and names or their products. dell disclaims proprietary interest in the marks and names of others.

For more information, contact Dell.

Information in this document is subject to change without notice.

patch management - tech...

Documents