Data Center Security: Achieving Prevention & the Targeted Prevention Policy's Role

Data Center Security: Server Advanced 6.x ACHIEVING PREVENTION & THE TARGETED PREVENTION POLICY’S ROLE Daniel Lopez

Date published: June 5th 2015

Document Version: 1.0

Achieving Prevention and the Targeted Prevention Policy Role Page 2 June 5 2015

Contents Introduction ........................................................................................................................................................................................................ 3

The Challenge ..................................................................................................................................................................................................... 3

Solution 1: Prevention deployment suggested best-‐practice process ...................................................................................... 4

Phase 1 -‐ Monitoring/IDS only .............................................................................................................................................................. 4 Phase 2 – Targeted Prevention Policy ............................................................................................................................................... 5 Phase 3 – Learning Mode (log only) .................................................................................................................................................... 5 Phase 4 – Full System Protection ......................................................................................................................................................... 5

Solution 2: Gain confidence in prevention technology by using the Targeted Prevention Policy ................................ 6

About the Targeted Prevention Policy ............................................................................................................................................... 6 How the policy works ................................................................................................................................................................................ 7 Use Cases ........................................................................................................................................................................................................ 8 Memory Protection ................................................................................................................................................................................ 9 Resource Restriction .......................................................................................................................................................................... 10 Network Control .................................................................................................................................................................................. 11 Privilege De-‐escalation ...................................................................................................................................................................... 12 Blacklist .................................................................................................................................................................................................... 13 SDCSSA Agent Self-‐Protection ........................................................................................................................................................ 14 Application Protection ...................................................................................................................................................................... 15

Summary ........................................................................................................................................................................................................... 20

Glossary ............................................................................................................................................................................................................. 20


INTRODUCTION This whitepaper will discuss a suggested process to achieve the deployment of host-‐based intrusion prevention (HIPS) policies in your organization and how the Symantec Data Center Security: Server Advanced Targeted Prevention policy plays a major role in helping your organization gain confidence in Symantec’s intrusion prevention technology.

THE CHALLENGE The ultimate goal for an IT Security team is to protect assets in their environment. One way to do this is to deploy an intrusion prevention solution, which will provide a pro-‐active security model rather than the traditional reactive model from solutions like antivirus products. Intrusion prevention solutions will lock down systems and prevent zero-‐day threats without the need for updates like virus definitions. The main goal to protect assets is something the business units within an organization will agree upon. Often however, when seeking to implement prevention technologies the security teams will get push back. This is due to lack of confidence in the ability to deploy a prevention solution and still allow for regular business practices to continue.

However, proposing the following two questions can mitigate this challenge:

1. What process can the IT security team set in place to gradually introduce intrusion prevention to the organization without causing business disruption?

2. How can the IT security team build confidence in the technology so that business units see the benefit in their investment?


SOLUTION 1: PREVENTION DEPLOYMENT SUGGESTED BEST-‐PRACTICE PROCESS The graph below represents the four recommended phases and suggested best-‐practice process to achieve intrusion prevention:

Figure 1 -‐ Prevention Deployment Best-‐practice Suggested Process

Phase 1 -‐ Monitoring/IDS only

SDCSSA includes intrusion detection policies with abundant security and monitoring intelligence for Windows and Unix based operating system environments. Some examples of such policy intelligence includes rule sets to detect Active Directory changes, login and access activity, OS-‐specific system critical file monitoring, privilege command and bash monitoring, among many others. Additionally, based on the operating system type and version of the SDCSSA agent it is capable of using real-‐time file integrity monitoring to provide instantaneous information about file access and modifications proving extremely helpful for auditing and compliance needs.

The implementation of detection policies is rather straightforward; you must enable or disable the specific rules for which you wish to generate events for. If there are monitoring requirements not met in the out-‐of-‐box detection policies the user can build rules to fit their specific use cases. During the server monitoring cycles you can generate alerts and notifications based on triggered events. These alerts and notifications can then be fed into your organization’s information security analysis and action process.


Phase 2 – Targeted Prevention Policy

Moving beyond detection, the second and most important phase to achieve intrusion prevention is to take advantage of the Targeted Prevention policy. The Targeted Prevention policy will allow you to focus on specific uses cases (large or small) without the risk of numerous false positives and the need for a major business and administrative process around policy tuning. This policy is very important because it will help establish prevention technology confidence in the business units and high-‐level management; furthermore, it will help establish a sense of priority in on-‐going business operations and revenue streams while solidifying its security.

The section of this whitepaper named “Solution 2: Gain confidence in prevention technology by using the Targeted Prevention policy” will cover the Targeted Prevention policy in detail with some specific use case examples.

Phase 3 – Learning Mode (log only)

Assuming that you have successfully implemented Targeted Prevention use cases and your organization now has assurance in the intrusion prevention technology it is time to move security capabilities to a higher level, by implementing additional prevention policies. The SDCSSA prevention policies have the ability to run with “prevention disabled” which allows the SDCSSA agent to detect and generate events triggered by the prevention rules but not actually prevent (deny) the action from occurring, it merely reports on it. As such, this prevention policy feature facilitates a “learning mode” where it is possible to understand the behavior of any application or process/daemon running on the system.

Ideally in this step you have a narrow focus on one or more set of critical servers in the organization (i.e. domain controllers, database servers, etc.). You will then apply and leave the policy in “learning mode” for a defined time period during which you can ensure that the machine(s) have gone through all possible operational iteration. This is a very important step as it provides visibility into the full server threat landscape and identifies specific customization requirements for specific server workloads that will be used in the last phase.

Phase 4 – Full System Protection

The last phase of the prevention deployment best practice suggestion is where you actually turn prevention on to start pro-‐actively protecting your server environment. At this point you have a blueprint of the way a server(s) behaves thanks to the prevention policy’s “learning mode”. Taking advantage of this information the prevention policy is then customized to lockdown down and enable full protection of the applications/services running on the server, ensuring the specific server use case is accurately achieved while protecting the server operating system and resources as a whole.

Some additional comments to consider as you step through all four phases are:

• Before starting with phase two it is recommended that a server risk assessment be executed to define a good starting point for protection. The goal of the assessment is to establish a reachable and accountable asset protection plan that can be presented to upper management.


• Per figure one above, there is a trade off between your desired security posture and time/effort. The more time and effort you are willing to put into the SDCSSA implementation the more protection it will yield for your organization.

• The policy tuning process effort is generally larger at the beginning of the project. Overtime the effort and load levels down as policy rules and control can be reused across different servers.

• Assuming that some security is better than no security, each phase can be achieved individually but it is highly recommended that you follow the specific listed order. Once each phase is completed you will be incrementally increasing the security stance of your environment provided you have the right business processes in place to support and administer the SDCSSA implementation.

SOLUTION 2: GAIN CONFIDENCE IN PREVENTION TECHNOLOGY BY USING THE TARGETED PREVENTION POLICY The Targeted Prevention policy was introduced in Critical System Protection 5.28 MP2. The policy was designed for very specific customer scenarios where one specific prevention rule needed to be in place without the need of locking down the entire system and go through the whole policy tuning process. The Targeted Prevention policy takes a different approach than the legacy policy security template and new Windows 6.0 security strategies in that there are no resources restrictions that are enabled by default on the operating system or network controls.

About the Targeted Prevention Policy

The Targeted Prevention policy provides the following options:

Global Policy options -‐ Provides a set of global options that apply to all the processes on the system. When you apply a global option in the policy, it is applied to all the sandboxes (or PSETs) in the policy.

Built-‐In sandbox/PSET options -‐ Provides a set of options to configure the built-‐in sandbox. These are only displayed when Show advanced options normally hidden in the policy is selected. These built-‐in sandboxes include the Kernel Driver options, Remote File Access options, and the self-‐protection sandboxes, which include the Symantec Data Center Security Server agent and manager.

Default sandbox/PSET options -‐ With the exception of built-‐in sandboxes, the policy routes all processes to a default sandbox. All protection features are configurable in this default sandbox.

My Custom Programs -‐ One or more custom programs can be defined within the policy, which can override the security settings in the default sandbox. Additionally, custom lists can be created and referenced elsewhere in the policy.

If you set disable prevention at a global level, then SDCSSA protection disables prevention for all sandboxes. You can also enable/disable prevention per individual sandbox, be it the default sandbox or any individual custom sandbox.


How the policy works

The Targeted Prevention policy takes a different approach than the Core, Strict and Limited legacy policy templates and the newer security strategies. By default all applications and services/daemons are routed to the default sandbox.

Figure 2 -‐ Default Sandbox

Any restrictions that are placed at this level will affect all applications and services/daemons running on the system. If Buffer Overflow and Thread Injection Detection are enabled at this level it will apply to everything that is running on the system. In some cases a customer might be just looking to deploy a prevention policy to implement network rules or restrict access to a certain directory. This could easily be done with this policy.

To define specific rules for individual applications or service/daemon a custom sandbox can be created and defined. When an application or service is placed in a custom sandbox, the restrictions that are placed at that level will supersede anything set at the global Policy Option level.

There are two different types of custom sandbox that an application can be placed in:


Figure 3 -‐ Two Custom Sandboxes Categories

1. Fully open PSET – If an application or service/daemon is place in this sandbox category there will be no restrictions placed on that process, even if a restriction was applied at the global level. When choosing this starting point you start with a fully open sandbox and gradually close down the security of the process.

2. Fully closed PSET – If an application or service/daemon is placed in this sandbox category, the process will be completely denied access to any resource including network, files, registries, etc. In other words, when choosing this custom control as a starting point you start from a fully closed sandbox and you will need to gradually open up the security for the process.

Use Cases

Use Case Description

Memory Protection The customer is only interested in protecting their system(s) against zero day attacks. The Targeted Prevention policy can be deployed with buffer overflow and thread injection detection enabled at the default PSET option level. This will provide memory protection for all applications and services running on the system.

Resource Restriction Customer wants to protect access to intellectual property on the server. A resource restriction can be placed at the Default PSET option level restricting access to a directory or file. This will apply to all applications and services running on the system.


Use Case Description

Network Control Customer wants to limit network access to a server. Network rules can be written at the Default PSET option level restricting inbound and outbound connections to and from the box.

Privilege De-‐Escalation

Customer wants to restrict the movement and capabilities of an administrator or root user. A resource restriction can be placed at the Default PSET option level to help determine what each user or group can access or do.

Blacklist Customer wants to black-‐list certain applications from running on the server. A fully closed custom sandbox will be used for this.

SDCSSA Agent Self-‐Protection

Customer wants to only use the intrusion detection policies but wants to protect the SDCSSA agent from being tampered with. This will apply to all applications and services running on the system and can prevent an attacker from tampering with the SDCSSA agent’s resources and services.

Application Protection Customer wants to quickly protect a single application or service/daemon without having to go through the entire policy tuning process.

MEMORY PROTECTION Buffer overflows and thread injection prevention to everything running on the system

By enabling all the rules in the memory controls section of the default sandbox and applying the policy this will protect all applications and services running from buffer overflow, thread injection, unusual memory permission changes.

1. Open the Targeted Prevention policy 2. Click on Sandboxes 3. Click on Edit[+] next to Default Sandbox options 4. Click on the Memory Controls section 5. Check the boxes next to Enable Buffer Overflow Detection, Block unusual memory allocations,

Block unusual memory permission changes, and Block turning off Data Execution Prevention (DEP)

6. Save the policy and apply it


Figure 4 -‐ Default Sandbox Memory Controls

RESOURCE RESTRICTION Protect critical data without worrying about full application or system lockdown

The Targeted Prevention policy does not provide any sort of operating system or application lockdown by default. This allows you to focus on a single protection goal without having to worry about tuning the entire policy for third-‐party applications and unique operating system behaviors. You can use a resource restriction to lock down critical files from either being changed or accessed.

To prevent changes to a specific file using the Targeted Prevention Policy:

1. Open the Targeted Prevention policy 2. Click on Sandboxes 3. Click on Edit[+] next to Default Sandbox options 4. Click on File Rules section 5. Check the box next to Block modification to these files underneath the Read-‐only Resource Lists 6. Click on Edit[+] next to expand Read-‐Only Resource Lists 7. Click the Add button. 8. Enter the path and filename for Resource Path.

a. Examples C:\temp\flag.txt, C:\temp\*, C:\temp\*.txt, C:\temp\?file.txt 9. Click OK. 10. Save the policy and apply it.


Figure 5 -‐ Read-‐only file resource

NETWORK CONTROL Restrict network traffic to a critical servers

Network rules can be written to restrict traffic to and from a server in the Targeted Prevention policy. One of the options that can be used is to only allow systems within the same subnet to communicate.

1. Open the Targeted Prevention policy 2. Click on Sandboxes 3. Click on Edit[+] next to Default Sandbox options 4. Click on the Network Controls section 5. Check the box next to Inbound network rules 6. Click on Edit[+] next to Inbound network rules

a. Click on Add b. Create a rule with the following information:

Action Protocol Local Port Remote IP Remote Port

Logging

Allow TCP Any (0-‐65535)

Local Ipv4 Subnet Addresses

Any (0-‐65535)

Log

7. Click on Edit[+] next to Default Inbound rule a. Set the Default inbound rule action value to Deny

8. Check the box next to Outbound network rules


9. Click on Edit[+] next to Outbound network rules b. Click on Add c. Create a rule with the following information:

Action Protocol Local Port Remote IP Remote Port

Logging

Allow TCP Any (0-‐65535)

Local Ipv4 Subnet Addresses

Any (0-‐65535)

Log

10. Click on Edit[+] next to Default outbound rule 11. Set the Default outbound rule action value to Deny 12. Save the policy and apply it.

Figure 6 -‐ Inbound Allowed For Subnet Only

PRIVILEGE DE-‐ESCALATION Restricting the movement and capabilities of an administrator or root user

The Targeted Prevention policy restriction rules allow extreme granularity permitting de-‐escalation of privileges by locking resources to specific users, groups, and/or programs; stopping insider abuse use cases. In the scenario shown below, a local administrator will not have the ability to access the financial data on a server, which he/she administers. Instead, the only individuals who have access to this information will be the “Finance” group. Note that this could also be Active Directory group, i.e. <Domain_name>\Finance.

1. Open the Targeted Prevention policy


2. Click on Sandboxes 3. Click on Edit[+] next to Default Sandbox options 4. Click on the Files Rules section 5. Check the box next to Block all access to these files 6. Click on Edit[+] next to Block all access to these files

a. Click on Add button b. In the Resource Path file type the name of the file(s)/folder(s) you will like to deny access to

(example c:\FinanceApp\credit_card_data.txt). c. Click OK.

Figure 7 -‐ Restrict file resource

7. Check the box next to Allow but log modifications to these files 8. Click on Edit[+] next to Allow but log modifications to these files

a. Click on Add button a. In the Resource Path file type the name of the file(s)/folder(s) of the same file you block

access to (example c:\FinanceApp\credit_card_data.txt) b. In the Program Path field type the application which can be used to access this data

(example: *notepad.exe*) c. In the Group Name field type the name of the group whom you want to grant access to

modify this data (example: Finance). d. Click OK e. Save the policy and apply it

Figure 8 -‐ Allow Group to Read/Write File Resource

BLACKLIST Restrict certain application(s) from running on a server

With the Targeted Prevention policy a security or system administrator can make sure that if certain applications are executed on the system then they have no rights to do anything. This is done by placing an application in a fully closed custom PSET that prevents it from having any access to resources on the system. In this scenario, a custom PSET called Blacklist will prevent an application from running in a machine.


1. Open the Targeted Prevention policy 2. Click on My Custom Sandboxes and Lists 3. Click on the Plus sign (Add a new Custom Control) 4. Enter Blacklist in the display name. This will be the name of this new custom sandbox. 5. For category, select This custom program PSET is fully closed and locked down by default. 6. Type Blacklist again for identifier. This is a unique name for this sandbox (no spaces are allowed).

Figure 9 -‐ New Fully closed custom PSET

7. Click Finish 8. Click on Edit[+] next to new Blacklist custom PSET control 9. Check and expand This custom program PSET is fully closed… 10. Click on Add 11. Enter the path to the program in the Program Path field 12. Click OK 13. Save and apply policy

SDCSSA AGENT SELF-‐PROTECTION Deploy instrusion detection (HIDS) but make sure that the SDCSSA agent is self protected

The Targeted Prevention policy includes controls to protect the SDCSSA agent against any attack to its services and/or resources. In a scenario where only detection policies (HIDS) will be used you can still deploy the Targeted Prevention policy on the same agent to include self-‐protection.

1. Open the Targeted Prevention policy 2. Click on Sandboxes


3. Click on Edit[+] next to Default Sandbox options 4. Check the box next to Enable SDCSS Self Protection 5. Save and apply policy

Figure 10 -‐ Enable Self Protection

APPLICATION PROTECTION Customer wants to lock down a single application

Instead of going through the motions of tuning a policy for the entire system, the Targeted Prevention policy allows you to lock down a single application or service. In the scenario below, a Windows Apache webserver installation will be locked down. The scenario will walk through how to prevent unauthorized users from making changes to the web server configuration and html files. Additionally, it will allow only the admin to have access to make changes to configuration files using notepad only.

Step 1: Block access to apache folder

Create a rule to block modifications to the Apache configuration and html files. The below option will block modifications to all files under the Apache directory

1. Open the Targeted Prevention policy


2. Click on Sandboxes 3. Click on Edit[+] next to Default Sandbox options 4. Click on the Files Rules section 5. Check the box next to Block all access to these files

a. Click on Add button b. In the Resource Path file type the %programfiles%\Apache Software

Foundation\Apache2.2\* c. Click OK.

Figure 11 -‐ Block Access to Apache Files

Step 2: Allow modifications to Apache folder only by Administrator using Notepad Create a rule that allows only the admininstrator user to use notepad in order to make modifications to configuration files under the Apache directory.

1. Go back to the Policy editor Home 2. Click on My Custom Sandboxes and Lists 3. Click on the Plus sign (Add a new Custom Control) 4. Enter Notepad in the display name. This will be the name of this new custom sandbox. 5. For category, select This custom program PSET is fully open, it has no default security

restrictions. 6. Type Notepad again for identifier. This is a unique name for this sandbox (no spaces are allowed). 7. Click Finish 8. Click on Edit[+] next to new Notepad custom PSET control 9. Check and expand This custom program PSET is fully open…


10. Click on Add 11. Enter %systemroot%\System32\notepad.exe in the Program Path field 12. Click OK

Figure 12 -‐ Notepad Custom PSET

13. Expand the File Rules section 14. Check and click on Edit[+] next to Allow Modification to these files 15. Click on Add 16. Type the following information in the corresponding fields

a. Resource Path: %programfiles%\Apache Software Foundation\Apache2.2\* b. Program Path: %systemroot%\System32\notepad.exe c. User name: admin

17. Click OK


Figure 13 -‐ Limit modifications to admin only

With this rule only the admin user can use notepad and to make any changes to the Apache configuration files.

Step 3: Allow modifications to Apache folder only by Administrator using Notepad Create a rule that allows the Apache application to read/write to its directory and configuration files.

1. Go back to the Policy editor Home 2. Click on My Custom Sandboxes and Lists 3. Click on the Plus sign (Add a new Custom Control) 4. Enter Apache in the display name. This will be the name of this new custom sandbox. 5. For category, select This custom program PSET is fully open, it has no default security

restrictions. 6. Type Apache again for identifier. This is a unique name for this sandbox (no spaces are allowed). 7. Click Finish 8. Click on Edit[+] next to new Apache custom PSET control 9. Check and expand This custom program PSET is fully open… 10. Click on Add 11. Enter %programfiles%\Apache Software Foundation\Apache2.2\bin\httpd.exe in the Program

Path field 12. Click OK 13. Expand the File Rules section 14. Check and click on Edit[+] next to Allow Modification to these files


15. Click on Add 16. Type %programfiles%\Apache Software Foundation\Apache2.2\* for the Resource Path 17. Click OK 18. Save and apply policy

With these three simple steps you are constraining the ability of any user or application (other than the administration using Notepad and Apache itself) to access the Apache’s directory, which contains critical log, executables, and configuration files. Any access to these files and directories will be denied across the operating system without compromising other less critical services. The simplicity of this policy makes testing and implementation of these rules very simple to achieve in either a development or production environment providing you have the ability to disable prevention and still trigger events as if prevention would have taken a pro-‐active action.


SUMMARY Achieving least privilege access control across your server environment using Symantec’s intrusion prevention technology takes time, effort, and commitment but it will yield an exceptional security result. Using the suggested phased deployment approach explained in this document along with the Targeted Prevention policy can help you achieve results faster and help your organization gain confidence in Symantec’s Data Center Security: Server Advanced.

GLOSSARY SDCSSA, SDCSS, DCS -‐ Symantec Data Center Security: Server Advanced

PSET, PS – Process set. This is the product’s technical name for sandboxes.

Any technical information that is made available by Symantec Corporation is the copyrighted work of Symantec Corporation and is owned by Symantec Corporation. NO WARRANTY. The technical information is being delivered to you as is and Symantec Corporation makes no warranty as to its accuracy or use. Any use of the technical documentation or the information contained herein is at the risk of the user. Documentation may include technical or other inaccuracies or typographical

About Symantec Symantec is a global leader in providing security; storage and systems solutions to help businesses and consumers secure and manage their information. Headquartered in Mountain View, Calif., Symantec has operations in more than 40 countries. More information is available at www.symantec.com.

For specific country offices and contact numbers, please visit our Web site. For product information in the U.S. call toll-‐free 1 (800) 745 6054.

Symantec Corporation World Headquarters 350 Ellis Street

Mountain View, CA 94043 USA +1 (650) 527-‐8000 www.symantec.com

Copyright © 2015 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.

Documents

Data Center Security: Achieving Prevention & the Targeted Prevention Policy's Role