Using Symantec Critical System Protection for Patch ... · Using Symantec Critical System...

WH

ITE

PA

PE

R: T

EC

HN

ICA

L

Using Symantec Critical System

Protection for Patch Mitigation

and Securing Legacy Out-of-

Support Platforms Symantec Security Group Technical Field Enablement Team

Contents

INTRODUCTION .................................................................. ERROR! BOOKMARK NOT DEFINED.

THE CHALLENGES OF MANAGING OUT-OF-SUPPORT SYSTEMS ........................................ 4

Understanding the impact of Microsoft’s Support Lifecycle ....................................... 4

Microsoft Vulnerabilities: Ratings and Trends .............................................................. 7

Vulnerabilities and the Patch Cycle .............................................................................. 10

SURVEYING AVAILABLE OPTIONS .............................................................................................. 15

SYMANTEC CRITICAL SYSTEM PROTECTION .......................................................................... 16

Key features and Benefits ............................................................................................. 17

Patch Mitigation with Symantec Critical System Protection .................................... 18

SUMMARY ........................................................................................................................................... 22

Where to get more information..................................................................................... 22

Table of Contents

Patch Mitigation with Symantec Critical System Protection

3

Executive Summary

End of Support (EOS) for software products is a normal and expected part of enterprise IT

lifecycle planning. However, unlike point applications whose EOS milestones may affect just one

line of business, the end of support for a commonly used operating system such as Windows

2000 has a far reaching impact to an IT organization. Given that operating systems comprise core

technologies affecting many systems and business units, IT groups face the difficult effort and

costly exercise of upgrading or replacing many production systems throughout the enterprise—

even though there is often no actual business benefit in doing so. Companies prefer to control

the pace of system upgrades appropriate to their business needs, rather than conforming to a

deadline imposed by an operating system vendor. As a result, many companies choose to stay

with these unsupported—yet perfectly functional—systems until there is absolutely compelling

business reason to change.

Increasingly, this compelling driver to upgrade comes from the escalating number of

vulnerabilities and higher security risks these legacy systems pose to an organization. Patching

has traditionally been seen as the only way to mitigate these vulnerabilities and risks. However,

the continuing cost to patch these legacy systems becomes so excessive that companies feel

forced to upgrade to a newer, supported OS simply to address these security concerns.

This white paper illustrates how Symantec Critical System Protection provides an alternate

approach to mitigating legacy system vulnerabilities and risks. By examining two popular yet

unsupported environments—Windows 2000 system and Windows NT—this paper will

demonstrate how Symantec Critical System Protection helps customers to:

• Improve legacy system security and risk management

• Realize cost savings from reduced patch management and remediation efforts

• Gain control over the legacy OS upgrade cycle for business—not security—reasons

While this report covers specific operating systems and versions, the general principles and

protections can apply and to shield vulnerabilities in critical systems running other operating

systems.


4

The challenges of managing out-of-support systems

This section summarizes the challenges faced by organizations that choose to run unsupported

products. These challenges and risks can include:

• The lack of operating system security patches and updates, resulting in significantly

increased security risks for unpatched systems

• The high cost to purchase security updates for a subset of known vulnerabilities

• The system threat exposure due to patch windows and zero day vulnerabilities

• The ongoing patch management costs and business impacts

Understanding the impact of Microsoft’s Support Lifecycle

Understanding the Microsoft Support Lifecycle is a prerequisite to appreciate the potential risks

of out-support systems. This section summarizes how Security Updates are handled generally as

well as specific implications for Windows 2000 and Windows NT.1

Security Update Policy

Microsoft provides Security Updates for a minimum of 10 years from initial product release for

Business products such as Windows 2000 and Windows NT. The support is divided into two

phases, referred to as Mainstream Support and Extended Support each spanning five years in

length. During this 10 year period Security Updates (patches) are available to fix identified

vulnerabilities. Microsoft advises customers to install the latest supported service pack to

continue to receive and install security updates and remain as secure as possible. After 10 years,

the product enters the “End of Extended Support” Phase and all security updates cease.

Impact on Windows 2000 and NT systems

Given that Windows 2000 has just recently passed its End-of-Support date on July 13, 2010 and

Windows NT 4.0 has been unsupported for over 5 years, Microsoft no longer issues security

updates for Windows 2000 or Windows NT 4.0. Customers running these systems receive:

• No new security updates (or even identification in security bulletins that a vulnerability

may also affect these out-of-support products)

• No non-security hotfixes

1 Key timelines for product retirement and applicable support services in different phases of the lifecycle are documented by Microsoft at http://support.microsoft.com/gp/lifeselect

http://support.microsoft.com/gp/lifeselect


5

• No free or paid assisted support options

• No option to engage Microsoft’s product development resources

• No updates to online content (Knowledge Base articles, etc.)

Microsoft guidance: simple in theory but not always practical

Microsoft’s guidance to customers running these systems is not surprising: migrate to the

supported products, such as Windows 7 and Windows Server 2008 R2. While Microsoft

understandably wants customers to purchase an upgrade to a newer product, there is often no

compelling business need on the customer end to upgrade. The support lifecycle policy does not

invalidate the life of a purchased license or dictate how when IT shops must stop using a product.

Ending support for old operating system versions is the main way Microsoft pushes customers

into buying and implementing newer operating system versions such as Windows 2008, even if

there is no tangible business benefit in doing so. With security updates cut off, customers

running production systems are essentially left unprotected by Microsoft once these operating

systems have reached the end of extended support.

Costly and Onerous “Custom Support”

A last-chance option that Microsoft offers desperate customers is a very expensive “custom

support” program that comes with some very onerous business terms and implications. This

program provides customers with the opportunity to receive a subset of Security Updates on

legacy versions of some Microsoft products and service packs that have reached the end of

support. This level of support is negotiated and available for purchase for those customers who

have not been able to complete their migration to a supported product and as such absolutely

need additional support from Microsoft. The Custom Support offerings include access to some

security hotfixes and are specifically designed to help customers bridge the support gap while

they complete their migration.


6

Table 1-1 summarizes the terms and security update implications for the available support

offerings: Custom Support Standard, for customers with a large number of unsupported devices,

and Custom Support Essentials, for customers who have a small number of unsupported devices.

Table 1-1 Microsoft Custom Support Offerings2

Offering Availability Restrictions and notable terms

Standard

• First year after a product or service pack leaves support

• Windows 2000 eligible until July 2011

• Windows NT not eligible

• Additional fees for “Important” vulnerability fixes • No fixes for “Moderate” or “Low” vulnerabilities • Additional fix fee for “non-security” hotfixes • Problem Resolution Support requires the

purchasing of Premier Support hours • Requires purchase of Premium Support contract • Must ensure operating system is up to a specified

release level • Must provide Microsoft an OS migration plan

Essentials • No fixes available for “Important”, Moderate” or “Low” vulnerabilities

• Additional fix fee and per device fee for Non-security hotfixes

• Problem Resolution Support requires the purchasing of Premier Support hours

• Must purchase a “premium” support contract • Must ensure operating system is up to a specified

release level • Must provide Microsoft an OS migration plan

The forced upgrade cycles of the Microsoft Windows platforms have completely reversed the

leverage customers normally wield over their suppliers. In many cases, customers have seen little

utility in switching to newer versions of Windows but have little choice in the matter. These older

Windows programs—which in many cases are still perfectly functional—must either be

redeveloped for a newer Windows platform, or replaced. The application upgrades place yet

another migration cost on top of the OS upgrade itself.

KEY TAKEAWAYS

• Unsupported operating systems no longer have Security Updates available for free • Yearly Custom Support contracts from Microsoft to obtain Security patches are

expensive and burdensome • Even under contract, patches are not made available for all vulnerabilities

2 See Gartner Research Note, Plan for the End of Support of Windows 2000, Publication Date: 14 September 2009; ID Number: G00170059, Page 4


7

KEY TAKEAWAYS

• Customers are at a severe disadvantage when dealing with Microsoft regarding upgrades. Microsoft uses the security “hammer” to force customers to upgrade to newer OS products even when the business case does not otherwise justify the migration

Microsoft Vulnerabilities: Ratings and Trends

A key implication to the Microsoft’s process of deploying Security fixes to vulnerabilities for

unsupported products is that “Critical” fixes are made available at a steep cost while “Important”

fixes are even harder to come by and fixes for “Moderate” to “Low” vulnerabilities are not

obtainable at any price. This section provides a review of the Microsoft rating system as well as a

statistical review of the frequency and distribution of vulnerabilities across the various severity

levels over the past decade.

The following table summarizes Microsoft’s severity rating system, which provides a single rating

for vulnerability in a software product. Table 1-2 : Severity Rating System

Rating Definition3

Critical Vulnerability whose exploitation could allow propagation of an internet worm without user action

Important Vulnerability whose exploitation could result in compromise of the confidentiality, integrity, or availability of users’ data, or of the integrity or availability of processing resources.

Moderate Exploitability is mitigated to a significant degree by factors such as default configuration, auditing, or difficulty of exploitation

Low A vulnerability whose exploitation is extremely difficult, or whose impact is minimal

The severity rating has a couple of implications to be aware of. First, the higher the vulnerability

severity, the greater the damage an exploit can inflict. The exploit may also be easier to create

and have a higher chance of succeeding. The lower ratings indicate the vulnerability is more

difficult to exploit and that the potential damage may be limited and mitigation activities can

reduce the risk further. One would hope that most reported vulnerabilities would fall into the Low

to Moderate rating levels.

3 Source: http://www.microsoft.com/technet/security/bulletin/rating.mspx

http://www.microsoft.com/technet/security/bulletin/rating.mspx


8

Unfortunately, the opposite is true. Based on an analysis of all

the publicly announced Windows NT and Windows 2000

vulnerabilities between January 2000 and October 20104,

nearly half (213 of 448) are Windows 2000 and NT 4.0 critical

vulnerabilities and three quarters of all items are in the top

two severity categories (critical/important).

The number of Critical Vulnerabilities per year has not varied

much over the last 8 years, averaging about 2 per month with

total vulnerabilities averaging 41 per year, as shown below.

Table 1-3 : Vulnerabilities Count (2000—2010)

Severity Count Critical

2010 47 23

2009 49 32

2008 39 20

2007 36 26

2006 45 27

2005 43 23

2004 28 13

2003 31 21

2002 38 24

2001 36 4

4 Bulletins retrieved from http://www.microsoft.com/technet/security/Bulletin/MS10-061.mspx Data available by request.

http://www.microsoft.com/technet/security/Bulletin/MS10-061.mspx


9

Severity Count Critical

2000 56

Total 448 213

Avg/yr 41 23

Given the constant stream of Critical and Important severity vulnerabilities, there is significant

pressure on organizations to apply patches as soon as possible because the potential security

risk is so huge. However, this activity goes against the best instincts of IT change management to

ensure adequate testing of any software changes before being deployed to production systems.

As a result, many enterprises still do not deploy the patches right away and are caught between

two vastly competing time elements: patch as soon as possible to close the exposures but take

enough time to ensure the changes won’t break critical business processes.

A second implication regarding severity rating has to do with customers paying Microsoft for

Custom Support on unsupported operating systems. Microsoft will not produce and will not

deliver any patches for security vulnerabilities with a Moderate or Low severity rating. As seen in

the previous section, Custom Support Essentials customers cannot get “Important” fixes. Custom

Support Standard customers may have to pay additional fees to get “Important” fixes (as per the

terms and conditions in the Microsoft Custom Support Agreement5). The bottom line is that not

all vulnerabilities have fixes available.

KEY TAKEAWAYS

• Vulnerabilities always exist and will continue to exist in the future • The rate and severity of vulnerabilities is likely to continue • Unsupported systems accumulate unpatched vulnerabilities making legacy systems

riskier over time • The continuing rate of Critical/Important vulnerabilities and zero day exploits points

out the lack of protection both unsupported (and supported) operating systems have when relying on patching as the primary security defense mechanism

5 See http://download.microsoft.com/download/3/a/5/3a5b342b-2f1b-4ebe-9261-98205902a74f/custom_support_agreement.pdf

http://download.microsoft.com/download/3/a/5/3a5b342b-2f1b-4ebe-9261-98205902a74f/custom_support_agreement.pdf

http://download.microsoft.com/download/3/a/5/3a5b342b-2f1b-4ebe-9261-98205902a74f/custom_support_agreement.pdf


10

Vulnerabilities and the Patch Cycle

This section focuses on how security fixes are made available to customers and provides a look at

the security implications and costs associated with a Patch Cycle.

Microsoft Patch Tuesday (and “Exploit Wednesday”)

Patch Tuesday is the second Tuesday of each month when Microsoft releases a consolidated set

of the latest security patches. In order to reduce the costs related to the deployment of patches,

security patches are accumulated over a period of one month and then dispatched all at once on

the second Tuesday of the month, an event for which system administrators can prepare and plan

for.

Just because support has ended for an operating system doesn’t mean vulnerabilities and new

risks have stopped – in fact recently the pace has been has been accelerating. In October 2010

Microsoft released its largest Patch Tuesday, when it provided fixes for 49 security vulnerabilities

in a “monster” Patch Tuesday update, including a privilege escalation bug exploited by Stuxnet,

worm that targets industrial control systems and exploited a privilege escalation vulnerability in

the Windows kernel-mode drivers.

One dangerous side effect of this model is that the following day is known by some as “Exploit

Wednesday,” when exploits are created and launched against the newly announced

vulnerabilities. Organizations that do not deploy the fixes immediately are at an increased risk of

attack once the patches are available. The sheer volume of the patches Microsoft releases each

month makes it difficult for even the most adept IT department to get every patch out to all of the

affected systems in a reasonable amount of time. Automated Patch management systems can

certainly help, but it still takes lots of manpower to rollout many patches to a large enterprise.

Microsoft, like any other organization, has finite resources and its Security Response Center staff

can only build and test so many fixes in a given month. That means that some vulnerabilities may

remain unpatched for months at a time, even when there is exploit code publicly available and

confirmed attacks going on.


11

The Window of Exposure

Every day there are new vulnerabilities discovered, new exploits written, and new threats emerge.

Whenever a new way to attack a host is discovered, there exists a window of exposure until that

attack method is prevented.

In the general case, someone discovers a new attack technique that renders some hosts

vulnerable to the exploit and the exposure grows as more people learn about this vulnerability.

Sometimes the window of exposure grows very slowly: there are attacks that are known by a few

researchers and no one else. Other times, the window grows very quickly (e.g., a developer writes

an exploit that takes advantage of the vulnerability and distributes it freely on the Internet.)

Sometimes the software vendor patches the vulnerable software quickly, and sometimes the

vendor takes months or even years. And some IT departments install patches quickly and

religiously, while others never do. Ultimately, there isn't a single window of exposure, but rather

an overlay of many windows of exposure that differ for each vulnerability and exploit. The result

is a constant state of exposure and risk within corporate systems.

The window remains open until the vendor patches the vulnerability and the system

administrator installs the patches or applies some mitigating technique to shield the system from

the hole. Ideally, the vendor will distribute the patch before any exploits are written but this

neither a given nor is it certain that system administrators will completely install the patch in all

affected systems without missing a few outliers.

A key characteristic of this exposure time period is that it the majority of the exposure period is

not under the control of security administrators but under the control of hackers and the

underlying software vendor. All the administrators can do is install patches if and when they

become available. In some circumstances, Microsoft has decided that it is “infeasible” to correct

the flaw in older operating systems due to inherent design or implementation issues. These older

platforms were developed before most of the current computing models were in use and the

threat landscape was much more limited. For example, the security kernel of Windows NT 4.0

was written before there was a World Wide Web and before TCP/IP was the default

communications protocol. Similarly, the security kernel of Windows 2000 Server was written

before web Services were widely deployed, before exploit tool kits were generally available, and

before most IT professionals had ever heard of a buffer overflow.


12

As a result, there are some vulnerabilities that cannot reasonably be corrected. Vulnerabilities

will always exist on any system, and with Windows NT 4.0 and Windows 2000, there is an extra

handicap in that those systems were never designed to withstand the processing or threat

environment that exists today. An alternative approach to securing systems is necessary since it

is never possible to fix all known and unknown vulnerabilities.

Reducing or Closing the Window of Exposure

Relying on a single security methodology such as patching as the only countermeasure to

vulnerabilities is both reactive and insufficient from a security perspective given the windows of

exposure discussed above. The best practice is not a reactive patch-centric security model but

one based on multiple countermeasures that include proactive prevention, detection and

response. Preventive countermeasures provide defense in two ways: they provide a hard barrier

(or barriers) that an attacker must overcome and when coupled with a good detection and

response mechanism it makes it much more difficult for the attack to hide its activities. Attackers

can be detected and blocked inside the host, regardless of which old or new vulnerability they

used to enter. In many cases, the window of exposure can be completely closed.

Even if a customer paid for the maximum Microsoft Custom Support they would still not receive

the “Moderate” patch and may have to pay extra for the Important patches. In addition a

customer also has to worry about obtaining and applying patches for the old application versions

such as web servers, databases, industrial control and other third party apps running on the host

– this may constitute an even larger (and generally unknown) patching burden than does the OS

itself.

For customers with unsupported Windows NT 4.0 and 2000 environments that are not receiving

any new patches have in essence an indefinite exposure and must look to other means to

mitigate the risk and secure their systems. Thus with the realization that vulnerabilities and risks

will always be present no matter how hard one tries to patch, it simply makes sense to take steps

to defend the system with a comprehensive host-based solution designed to protect and against

a broad array of exploits without relying on patch availability or signatures.


13

KEY TAKEAWAYS

• Organizations need to consider alternative approaches to securing their systems rather than simply believing that a quicker patch cycle will protect them

• Defensive countermeasures that include proactive prevention, detection and response capabilities to stop known and unknown threats are the best way to close or reduce the exposure window

• Comprehensive HIPS/HIDS Security products such as Symantec Critical Systems Protection provide the most effective way for IT organizations to reduce patch cycle frequency, reduce downtime and save manpower while improving overall endpoint security posture

The Patch Cycle and the Associated Costs

Determining that a new security vulnerability exists and a patch is available from the vendor is

only the first step for a customer in a costly and time consuming security patch cycle. A patch

cycle facilitates the application of standard patch releases and updates within the organization.

The tasks performed for each patch cycle typically include the following:

• Patch Research, Prioritization and Scheduling—Security and operational staff

determine the nature of the vulnerability, the components to be patched, and the

priority of the patch within the organization.

• Patch Testing—Detailed patch testing requirements are created and vary by system

criticality and availability requirements, available resources, patch severity and

software impacted.

• Change Management—Patches and updates are performed and tracked through the

change management system, with associated contingency and backout plans.

• Patch Installation and Deployment—Patches actually applied patches and

productions systems updated. Automated tools can help with this but often there are

outliers that need to be patched manually.

• Audit and Assessment—Determines what systems need to be patched for any given

vulnerability/bug and whether systems that are supposed to be updated were actually

patched.

• Post Implementation Consistency and Compliance—Controls put in place to ensure

that newly deployed and rebuilt systems are updated to reflect the just deployed

patches.


14

Clearly, patching is costly and manpower intensive. For many organizations 13-16 patch cycles

per year are not uncommon when following the monthly Patch Tuesday schedule, as well as

accommodating 2-3 emergency critical patches during the year. Given the frequency of security

patches, critical systems face downtime and potential risk of patch breakage more than once a

month. For organizations with thousands of servers affected, patching introduces an enormous

impact to system downtime, to say nothing of the additional burden on the IT operations staff.

For critical flaws, it may be simply unacceptable for some organizations to run with these known

vulnerabilities without other compensating controls in place. In these cases, immediate patch

deployment is required often within 48 to 72 hours.

PATCH COST DRIVERS—EMERGENCY PATCH

Scenario: One large scale financial organization is evaluating an emergency patch for the organization deploy an out-of-cycle patch to 35,000 hosts within 48 hours. Cost drivers for the emergency patch:

• Overtime pay for personnel—Systems Administrators, Security Engineers, QA Specialists, Operations staff, Configuration Control board members, Help Desk Staff (to handle failed patches or malfunctioning systems/applications), Managers

• Production system downtime—Outages of business systems (reboots are usually required) as well as the need to bring up and coordinate standby systems

• Additional organizational costs—Productivity losses for users and staff, including delays and impacts to other business projects from re-directed staff. Also included coordination costs (one of the largest costs is lost labor time in coordinating people and systems)

Avoiding the costs with host-based intrusion prevention system: Mitigating the risk of a vulnerability from a “critical” rating to a lower severity by using

otherprotective measures (such as HIPS) allows the IT department to defer the emergency patch to a normally scheduled patch cycle yielding major cost savings for the organization

PATCH COST DRIVERS – SMALL SCALE LEGACY ENVIRONMENT

Scenario: An organization with 300 Windows 2000 servers under Microsoft Custom Support contact is estimating costs to maintain the patched environment. Cost drivers:

• Microsoft Support fees for out-of-support Security Fixes • Monthly patch cycle costs


15

PATCH COST DRIVERS – SMALL SCALE LEGACY ENVIRONMENT

Reducing costs by reducing patch cycles: Customer can potentially reduce the number of patch cycles from 10-12 per year to 1-2,

saving the company upwards of $50,000 per quarter for out of support costs, according to Gartner.6

Surveying available options

Customers running legacy operating systems have basically three main options or approaches for

addressing patch mitigation. This section evaluates each of these approaches.

Option 1 – Traditional Patch Approach

In this option, the customer pays the Microsoft Custom Support fees and continues the same

frequency of patching as when the OS was supported. This is by far the most costly option but

does provide explicit protection from the vulnerabilities that are actually patched. The downside

is it does not address zero day vulnerabilities (vulnerabilities where no patch is made available

and other windows of exposure that leave the systems open for attack.) All of the money and

effort applied with this approach has not changed the fundamental security of the platform but

simply maintains the same security as the previous month before the new vulnerabilities were

made known.

Option 2 – Do Nothing Approach

With this option, the customer decides not to pay the Microsoft Support fees and therefore no

longer gets vulnerability patches for the unsupported platforms and thus has no upfront security

related patching costs. This option bets that the legacy systems will not be the subject of an

attack. This is certainly the lowest cost option in the short term but has a number of

disadvantages and risks, including:

• Possible violation of compliance or regulatory mandates to which an organization may

be subject, perhaps resulting in fines or penalties

• Potential exposure to a data breach that damages the company or brand, the cost of

which far outweighs the cost for establish protection

• Increased labor resources to remediate the environment once an attack occurs

6 See Gartner Research Note, Plan for the End of Support of Windows 2000, Publication Date: 14 September 2009; ID Number: G00170059


16

• Increased range and number of exploits likely to be successful in their attack due to the

cumulative effect of “doing nothing” across many separate vulnerabilities

The customer ultimately needs to decide from a “risk management” standpoint whether the cost

savings more than offset the possible damage to the systems or the company.

Option 3 – Harden systems using host-based IPS/IDS security agents

In this option the customer deploys HIPS/HIDS based security agents at the endpoints to harden

the operating system and applications, mitigate vulnerabilities and stop known and unknown

threats. This is the only option that actually improves the overall security posture of the hosts

and gives flexible choices to the customer to reduce the patch frequency and reduce or eliminate

the Microsoft support fees. This is the most cost effective option with savings in patching costs,

support fees, downtime and remediation efforts more than offsetting the initial acquisition and

deployment costs.

Option 3 clearly provides the best choice – better and more consistent host security, lower

overall costs, and the return of control to the customer with regard to legacy system

replacement. The main concerns for a customer are likely to be the effort involved to deploy and

manage a new endpoint security agent; and the compatibility of that agent within their legacy

system environment. A Proof of concept is usually the best way to demonstrate ease of

deployment, manageability, legacy system compatibility, security efficacy and the value of the

overall solution.

Symantec Critical System Protection

When it comes to selecting the best product to protect legacy systems and offset patching costs

there is a very short list of appropriate products that have the necessary platform support,

technical capability, industry presence, and proven track record to be considered for protecting

the legacy systems. Symantec Critical System Protection (Symantec Critical System Protection)

easily exceeds these key criteria:

• Platform Support—Windows NT and Windows 2000, as well a broad array of other

platforms as well including Windows 2003, 2008, XP, Solaris, AIX, Linux, ESX and

others.


17

• Technical Capability—Full featured HIPS/HIDS features with extensive out-of-the-box

policies for comprehensive system and application protection

• Industry Presence—Symantec is one of the world-wide leaders in IT security with best

in class products including endpoint protection

• Proven Track Record—the HIPS/HIDS technologies in Symantec Critical System

Protection have been defending Windows 2000 and Windows NT enterprise systems for

the last seven years

This section reviews the Symantec Critical System Protection product architecture and

capabilities appropriate to protecting legacy systems and use in Patch Mitigation Detailed

description of the technology. Include visual elements to reinforce the learning.

Key features and Benefits

Symantec Critical System Protection is an industry leader in defending endpoints against

targeted attacks, malicious mobile code, rootkits, worms, and day-zero attacks. Zero-update

protection is critical when addressing brand exploits or variants that take advantage of published

and unpublished system and application vulnerabilities. Symantec Critical System Protection

continuously defends critical servers that cannot be taken out of service to apply operating

system or application-specific vulnerability patches. This reduces emergency patching of systems

in response to vulnerability announcements and minimizes patch-related downtime and IT staff

expenses.

Benefits for Critical System Protection include: Significant reduction of Patching Costs by

• Reducing the frequency of patch cycles and the costs associated with Microsoft custom support fees

• Reducing the business impacts from system downtime, breaches and expensive remediation efforts

• Reducing the staffing burden by replacing the reactive and often urgent patch management process with a steady, predictable software maintenance cycle

Significant improvement of security posture of host systems • Shields systems from OS and application vulnerabilities and exploits • Provides proactive, system wide prevention against known and unknown

vulnerabilities (compared to Patch management that is only effective against known, vendor-corrected vulnerabilities)

• Provides centralized policy management to control system, application and user behaviors across a wide range of Unix, Linux and Windows systems including legacy Windows NT and 2000 systems and virtualized environments.

• Provides extraordinary insight and control over important system security events Increased control over legacy system replacement strategy and timeline

• Extend use of legacy systems without the continued pressure of increasing security risks and costs

• Extend use of legacy systems and further reduce IT costs using virtualization where appropriate


18

Patch Mitigation with Symantec Critical System Protection Patch relief—the ability to delay deployment of security patches to lengthen the patch cycle time frame—is a key security-related benefit of Symantec Critical System Protection. When using Symantec Critical System Protection, the vulnerabilities may still be present on a system, but any exploit potential is limited. Symantec Critical System Protection protects systems with known or unknown vulnerabilities by limiting the scope of resources and capabilities for programs and users to only those features they need to access for normal operations. To support Symantec’s contention that customers can delay patching efforts for Windows 2000 and NT, Symantec maintains a running document listing past Microsoft vulnerablitlies and exploits, accompanied by explanations on how Symantec Critical System Protection could have addressed them. To date, over 400 vulnerabilities have been addressed (more than 200 were deemed critical by Microsoft). For Symantec Critical System Protection, the typical response is that the customer is already protected if they have deployed the out-of-the-box prevention policy. Since Symantec Critical System Protection is a behavioral-based product, its policies are not associated with particular exploits or signatures. No matter how an exploit reached the system—via any number of vulnerabilities when it attempts undesired behaviors such as inserting a rootkit, performing unwanted network access, modifying the registry run list, or other malicious behaviors—the activity is blocked. Just a few examples of the many examples are presented in this section7.

IIS Protection Response Sample The out-of-the-box Symantec Critical System Protection policies provide significant protection against Internet Information Server (IIS) attacks. No policy updates are necessary. As soon as the injected code attempts behavior that is not normal for the program it was injected into, Symantec Critical System Protection blocks that behavior. Since the goal of most attacks is to use the program's privileges in unauthorized ways, most attacks will be blocked. Some specific examples:

• All Symantec Critical System Protection policies provide tight confinement around the

IIS service. Attacks that attempt to modify resources other than the small set of resources required by normal IIS service behavior are blocked.

• All Symantec Critical System Protection policies block the IIS service from launching suspicious programs. So if the attack code tries to download and run a Trojan program, it won't be able to launch the Trojan. This is true whether the attack is made via this vulnerability or any other method.

• All Symantec Critical System Protection policies block incoming network connections by default, thus preventing access to this vulnerability from remote systems. If inbound network connections are required, the customer must configure the policy to allow specific remote networks to connect. Unknown (and potentially malicious) remote systems would still be blocked.

In addition, the Symantec Critical System Protection policies block other services from modifying the IIS content directories. (This is due to the standard Symantec Critical System Protection policy controls that only allow services access to the resources they need to do their jobs.) Thus,

7 To view the entire set of detailed written responses from the Symantec Critical System Protection engineering team provided in response to vulnerability/patch announcements, see the document titled: Symantec Critical System Protection Response to Microsoft Vulnerabilities (Feb 2006 - Sept 2010).


19

if attackers find vulnerabilities in other Windows Services that would allow them to add or modify files in the IIS content directories, the Symantec Critical System Protection policies would block those changes. By default the Symantec Critical System Protection policies allow services read access to most of the file system. To protect against information disclosure vulnerabilities, customers can configure the policy so the IIS programs cannot even read certain files or folders. This would be appropriate for sensitive areas of the file system that are not normally accessed by the programs and would further limit the damage that information disclosure attacks could cause.

Generic Windows Service Protection The out-of-the-box Symantec Critical System Protection policies provide significant protection against these buffer overflows, similar to how they protect against any type of injected code. No policy updates are necessary. As soon as the injected code attempts behavior that is not normal for the program it was injected into, Symantec Critical System Protection blocks that behavior. Since the goal of most attacks is to use the program's privileges in unauthorized ways, most attacks will be blocked. Some specific examples:

• All Symantec Critical System Protection policies block services from modifying critical Windows files or registry values. So if the attack code tries to damage the system, it won’t be able to.

• All Symantec Critical System Protection policies block incoming network connections by default, thus preventing access to this vulnerability from remote systems. If inbound network connections are required, the customer must configure the policy to allow specific remote networks to connect. Unknown (and potentially malicious) remote systems would still be blocked.

• All Symantec Critical System Protection policies block services from writing executables to disk and from launching suspicious programs. So if the attack code tries to download and run a Trojan program, it won't be able to launch the Trojan. This is true whether the attack is made via this vulnerability or any other method and whether it is injected from a remote system or a malicious local program.

Specific exploit vectors The following are just a few examples of how Symantec Critical System Protection addresses specific exploit vectors comment to operating system threats.

Exploit Strategy Mitigation by Symantec Critical System Protection

Placing malicious programs and executables on disk

• Blocks by default the dropping or modification of executable components (CMD, EXE, DLL, SYS files, etc.) onto the host system by untrusted programs or users.

• Prohibits the dropping or modification of any files (of any file extension) into critical system areas (such as Windows/system32

Creation or Modification of Critical System Registry Keys and configuration files

• Uses default blocking mechanisms (cited above) to prevent exploit payload from persisting on the system in an executable form and from registering and launching itself after a reboot

Remote command and control (phone home)

• Tightly limits networking ability of processes on the systems to communicate external to the host.


20

Exploit Strategy Mitigation by Symantec Critical System Protection

• Provides firewall settings to block activity and control network access by program, user, ports, protocol and IP address

Buffer overflow and code injection

• Ensures that running authorized software cannot be hijacked by code injected via buffer overflow or thread injection.

Privilege Escalation/Abuse • Treats these privileged processes as any other contained program. As such they cannot violate defined policy behaviors even if the Windows operating system grants them complete system permissions and accesses

Zero-day exploits (Blaster and Stuxnet) With its behavior-based, lease privilege protection model, Symantec Critical System Protection is able to easily thwart new and unknown threats. This section covers two examples of infamous zero-day exploits that are years and worlds apart in complexity: Blaster and Stuxnet. Blaster Protection Example

The Blaster Worm (also known as Lovsan, Lovesan or MSBlast) was a computer worm that quickly spread on computers running the Microsoft operating systems, including Windows XP and Windows 2000 during August 2003. The worm spread by exploiting a buffer overflow discovered in the Windows DCOM RPC service on the affected operating systems, for which a patch had been released one month earlier in MS03-026 and later in MS03-039. This allowed the worm to spread without users opening attachments simply by spamming itself to large numbers of random IP addresses. As with most attacks, multiple steps are involved to exploit the vulnerability, land a payload, execute the payload, persist the threat and infect other hosts. The diagram below shows these multiple attack steps (buffer overflow, outbound network connection, insert file into root directory, modify system registry key, and so on) for this exploit and also shows that these actions are blocked by the Symantec Critical System Protection policy.

The reason these actions are blocked is that they violate the behavior-based policy rules established for the Windows RPC service. The RPC service performs a very specific set of operations and accesses that has been codified into the policy. Abnormal behaviors represent an attack and thus are blocked by default. Thus, the Blaster exploit is neither successful in


21

damaging the system nor infecting other hosts. This containment model is the core foundation that Symantec Critical System Protection uses to stop known and unknown threats. Stuxnet Protection Example Stuxnet, a recent and highly sophisticated targeted attack seen to date, had the followings characteristics:

• Includes 4 zero day vulnerabilities (some of which are still not fixed by Microsoft) and at least 2 known vulnerabilities

• Contains multiple attack vectors (8 or more) • Targets industrial control systems • Replicates across the network as well as across “the air gap” (using thumb drives &

removable media)

For Symantec Critical System Protection, however, Stuxnet is just another threat trying to modify critical system files and registry keys and violate network containment rules. Without requiring a policy change, the Symantec Critical System Protection environment thwarts the attempt to break out of the hardened environment.

Elements of Stuxnet Attack Symantec Critical System Protection’s Automated Defenses

Uses a Window Spooler network vulnerability (MS10-061) to replicate itself

• Prohibits Windows Spooler service (spoolsv.exe) from write any executable (or for that matter any file) into the %SYSTEM% directory

Uses a Windows rootkit to hide Windows binaries

• Default policy blocks writing of the Stuxnet driver .SYS files as parent process is not a trusted program allowed to perform driver installs

Tries to register driver files as a service and starts running before the system boots up in the next successive system starts

• Default Policy blocks modification of relevant driver registration keys

Uses root kit techniques to hide injected PLC code

• Default policy denies command shells from being launched from within SQL Server (a common SQL Injection attack technique).

Communicates with C&C servers using HTTP

• Leverages customer best practice configuration to limit activity to specific customer networks and block outbound communication to external C&C servers

Communicates with other C&C hosts

• Likely blocked depending on how the approved network IP address/subnet lists were set up during initial policy deployment

Symantec Critical Protection’s behavioral rules are not affected by the time lag between discovery of a new exploit and the release of a corresponding signature to combat it. Given how rapidly new exploits are introduced, the ability to proactively stop a new and unknown attack the first time it appears is a tremendous benefit. Protection against zero-day threats yields significant financial benefits by avoiding the costs of remediation and recovery from an outbreak. Symantec Critical System Protection gives staff the time to properly test and deploy system patches and alleviates the urgency of emergency system patches.


22

Summary

Symantec Critical System Protection provides proactive control and security features that enable

significant gains in patch relief. Vulnerabilities and responses presented for Windows 2000 and

NT demonstrate that Symantec Critical System Protection would have enabled significant patch

cycle reduction opportunities over the last 4 years with equal savings to be had in future years.

In all cases noted above regarding vulnerabilities and exploits examined, the IT staff would have

had the option of delaying critical patch activities until a later, planned patching window. With

patch cycle frequency rising to double digits per year for many customers, eliminating even one

or two patch cycle per year can provide sizable cost savings. Reducing security patches to 2 or 3

for an entire year would yield huge benefits in cost and manpower savings. In summary, with

Symantec Critical System Protection, you can patch less frequently, less urgently, cost effectively

and on your own schedule.

Where to get more information

For more information on Symantec Critical System Protection, visit

http://www.symantec.com/business/critical-system-protection

http://www.symantec.com/business/critical-system-protection

About Symantec Symantec is a

global leader in providing

security, storage and systems

management solutions to help

consumers and organizations

secure and manage their

information-driven world.

Headquartered in Mountain View,

Calif., Symantec has operations

in 40 countries. More information

is available at

www.symantec.com.

For specific country offices and

contact numbers, please visit our

Web site.

Symantec World Headquarters

350 Ellis St

Moutain View, CA 94043 USA

+1 (650) 527 8000

1 (800) 721 3934

www.symantec.com

Copyright © 2011 Symantec Corporation. All rights reserved.

Symantec and the Symantec logo are trademarks or

registered trademarks of Symantec Corporation or its affiliates in the U.S. and other countries. Other names may be

trademarks of their respective owners.

Using Symantec Critical System Protection for Patch ... · Using Symantec Critical System...

Documents

Transcript of Using Symantec Critical System Protection for Patch ... · Using Symantec Critical System...