Symantec DCS: Optimizing Security Performance From Day 1

 

Symantec Data Center Security: Advanced offers IT organizations an unparalleled means of securing the state and integrity of their Windows and UNIX servers and application environments, both within the physical and virtual space.  Default security protections are provided for local file, registry and network resources; additionally, protections are available for running processes in the memory space as well.  When fully and correctly implemented, a server protected by Data Center Security can be provably expected to stand against virtually any known means of directly attacking or compromising a protected server.

 

This is not to say that adoption of the solution is not without its own unique challenges. In fact, it is the unanticipated (and often non-technical) challenges that the organization encounters that are the difference between a successful implementation and failed initiative.  Key aspects to consider and those which are important to manage effectively often include:

 

The Challenge: Time and Energy invested to deploy:  This is a common, and at times, daunting hurdle that is actually easy to see, but at the same time, is also easy to overstate — particularly when the organization does not have the benefit of experience or a well-thought approach to addressing it.  Implementing Symantec Data Center Security Server: Advanced involves deploying a new software agent and then tuning the security policy for that agent to account for system conditions.  Allowing both of these activities to occur simultaneously can create an environment where it appears that you are unable to successfully complete one without first completing the other; and that progress may only be made incrementally as you first deploy a subset of agents and then tune that subset to stability before moving on to the next subset – continually to a point of completion.  Faced with this approach, it is not uncommon for an organization’s effort to stall before the first successful milestone is reached.

How to avoid this Challenge: Fortunately, this is an easy one to address. By first committing to completing the installation of the agent BEFORE embarking on any tuning of the policy, you can do so very easily, AND identify and address any unexpected compatibility concerns that may arise and ensure a clean environment to begin tuning in.  Additionally, by focusing specifically on deployment first, without carrying a minimum tuning dependency with it, you can capitalize on deployment opportunities and change Windows as they become available without fear of missing a hard-to-obtain Window for particularly sensitive systems.  Finally, by addressing deployment in its entirety first, you have the luxury to introduce the population to log-only policies for tuning at your discretion with minimal (if any) further participation from your application owners to do so.  Commitment to the solution can be secured via the installation, and completion of tuning can occur while minimizing disruption to application owner priorities.

The Challenge: The Degree of Policy tuning is higher than expected.  This is another fairly common challenge that organizations may encounter.  Symantec DCS offers several levels of policy strength — ranging from policies that only address specific items defined by the administrator, up to and including full, system-wide whitelist-based policies which will automatically deny access to anything not specifically assigned to the policy.  As this is a security solution to which a measurable degree of investment is attached, there is a commonly-encountered bias toward employing the strongest control level available when implementing, many times without weighing in additional, very important factors that can also credibly influence your policy direction.

How to avoid this challenge: This is also something that is fairly straightforward to avoid as a challenge — although some attention must be paid when planning and making initial decisions about what we expect to realize from the solution versus what we are prepared to put into it.  One of the first things to understand is that successfully applying ANY of the DCS policies, where the policy actually includes protected resources, results in a net improvement of the state of security for the protected asset.  Benefit can (and often is) realized from basic level policies as often as it is from whitelist policies.  Over the past year, my organization has performed numerous deployments where policies focused exclusively on securing the Windows Server 2003, to the exclusion of other security elements. These deployments have been used as compensation for loss of patch availability for this platform.  This type of policy is by requirement very, very open for elements outside of the core operating system.

• It does NOT secure the network interface.
• It does NOT secure any third party applications, modules or runtimes outside of Windows, SQL, IIS, Office, and Internet Explorer. If the application is anything other than the aforementioned, no restrictions typically get applied to it.

We use this policy in these cases because:

• It can be deployed very quickly, and time sensitivity is a priority for the clients.
• It can be deployed very broadly, and structural simplicity is a priority for the clients.
• It is very tolerant to changes, and policy stability is a priority for the clients.
• It compensates for the loss of a specific control, and that parity is the only security priority in scope.

The clients are well-informed as to what they are getting out of the solution and why; and it is agreed that the primary objectives are being satisfied.  This policy is much weaker than the whitelist policies that could be used, and in practice is generally acknowledged to be weaker than the default “hardened” policy. Clients are informed of this when we propose it.  We have demonstrated the ability to roll this policy out fully in many of our client shops in time periods ranging between 4 and 8 calendar weeks — with a measurable portion of that timescale resulting from change control schedule considerations and forced validation periods.  Recently we have had occasion for some of our clients to test this policy against red team and formal penetration testing efforts to validate the strength of the control.  Those efforts have consistently reported successfully stopping the penetration attempts when using the policy.

These clients were able to:

• Fulfill their original security objective
• Achieve this objective in an acceptable short time period
• Sustain the resultant solution easily from point of adoption onward
• Measurably raise the overall state of security for their organization

This was accomplished using a policy that fit the needs of the organization at the time and likely would NOT have been accomplished had the organization simply elected to adopt the strongest policy as indicated on paper.  By considering an appropriate and realistic range of factors, you can identify a correct strength of policy that fits both your security objectives AND your organization objectives and be able to sustain it long term in a satisfactory manner.

In summary, Symantec Data Center Security is a powerful, highly valuable addition to the security portfolio.  While it may, on the surface appear intimidating, none of the challenges it poses are insurmountable. You may, in fact, find that they are actually not nearly as substantial as they appear on first impression when viewed from a proper perspective and with the benefit of the right degree of awareness and experience.

 

Contributed by: Christian Karwatske