best practices for critical system protection proof of ... best practices for pocs... · best...

1

BE

ST

PR

AC

TIC

ES

FOR

SC

SP

PO

CS

Best Practices for Critical System Protection Proof of Concepts Version 1.0

2

1. UNDERSTANDING SERVER RISK .................................................................................................................................... 4

1.1. HOW TO PROTECT YOURSELF: DEVELOPING SERVER HARDENING CONFIGURATIONS ................................................................. 6 1.2. LOGGING AND MONITORING ........................................................................................................................................................ 7

2. INTRODUCTION TO CRITICAL SYSTEMS PROTECTION .......................................................................................... 8

2.1. DETECTION AND PROTECTION ...................................................................................................................................................... 8 2.2. UNDERSTANDING THE COMPONENTS OF SCSP ............................................................................................................................. 9 2.3. PORTS AND COMMUNICATIONS .................................................................................................................................................... 9 2.4. DEPLOYMENT CONSIDERATIONS ................................................................................................................................................. 10 2.5. DATABASE SIZING ...................................................................................................................................................................... 10

3. INSTALLING SCSP ............................................................................................................................................................ 12

3.1. SERVER INSTALLATION .............................................................................................................................................................. 12 3.2. CONSOLE INSTALLATION ............................................................................................................................................................ 14 3.3. WINDOWS AGENT INSTALL ........................................................................................................................................................ 14

4. WORKING WITH SCSP .................................................................................................................................................... 19

4.1. CONSOLE PAGE .......................................................................................................................................................................... 19 4.2. ASSETS PAGE ............................................................................................................................................................................. 20 4.3. PREVENTION POLICIES ............................................................................................................................................................... 21

4.3.1. Windows Core Prevention Policy ....................................................................................................................................... 22 4.3.2. Windows Strict Prevention Policy ...................................................................................................................................... 23 4.3.3. Creating a new policy for a server using the Wizard ......................................................................................................... 24

4.4. APPLYING A POLICY ................................................................................................................................................................... 34 4.4.1. Monitoring a Policy Behavior ............................................................................................................................................ 36 4.4.2. Editing a policy .................................................................................................................................................................. 36 4.4.3. Host Firewall Protection .................................................................................................................................................... 38 4.4.4. Application Buffer Overflow Protection ............................................................................................................................. 39 4.4.5. Application Lockdown ........................................................................................................................................................ 40 4.4.6. System Variables ................................................................................................................................................................ 40

4.5. DETECTION POLICIES ................................................................................................................................................................. 41 4.5.1. Baseline Policy ................................................................................................................................................................... 41 4.5.2. Windows Template Policy .................................................................................................................................................. 42 4.5.3. NT Event Log ...................................................................................................................................................................... 45 4.5.4. File Integrity Monitoring .................................................................................................................................................... 46 4.5.5. Registry Watch ................................................................................................................................................................... 48 4.5.6. Text Log Watch ................................................................................................................................................................... 49

4.6. PREVENTION POLICY CREATION AND PROFILING ....................................................................................................................... 50 4.6.1. System variables ................................................................................................................................................................. 50 4.6.2. Resource Variables ............................................................................................................................................................. 51 4.6.3. Custom Table Options ........................................................................................................................................................ 52 4.6.4. Profiling an Application ..................................................................................................................................................... 53 4.6.5. Example: Locking Down an Oracle Server ........................................................................................................................ 56 4.6.5.1. Working with Resource Restrictions ............................................................................................................................... 67 4.6.5.2. Working with Network Restrictions ................................................................................................................................ 81

5. WALKTHROUGH OF COMMON USE CASES ............................................................................................................... 87

5.1. FILE INTEGRITY MONITORING .................................................................................................................................................... 87 5.2. PRIVILEGE DE-ESCALATION ....................................................................................................................................................... 89 5.3. WEB SERVER CONFIGURATION AND WEB DEFACEMENT PREVENTION ...................................................................................... 92

3

5.4. PROTECTING APPS FROM USERS ................................................................................................................................................. 93 5.5. CONFIGURING CONNECTIONS TO AND FROM AN AGENT COMPUTER ............................................................................................ 93 5.6. ALLOWING GRANULAR ACCESS TO FILES, DEVICES, AND REGISTRY KEYS................................................................................... 94 5.7. BLOCKING ACCESS TO USB DEVICES ......................................................................................................................................... 95 5.8. GIVING A PROGRAM ACCESS TO A SPECIFIC RESOURCE SET ........................................................................................................ 95 5.9. GIVING A PROGRAM WIDE ACCESS TO RESOURCES ..................................................................................................................... 96 5.10. PREVENTING ZERO DAY ATTACKS ......................................................................................................................................... 96 5.11. WHITE LISTING ....................................................................................................................................................................... 99 5.12. VIRTUALIZATION PROTECTION ............................................................................................................................................. 104

6. CONFIGURATION, REPORTING AND MONITORING .............................................................................................. 108

6.1. ALERTING................................................................................................................................................................................. 111 6.2. MONITORING ............................................................................................................................................................................ 112 6.3. SEARCHING AND REAL-TIME MONITORS ................................................................................................................................... 113

7. POC TIPS .......................................................................................................................................................................... 115

4

1. Understanding Server Risk

Servers are responsible for serving content and invoking applications that generate content. Many application servers provide services that Web applications can use such as data storage, directory services, mail, messaging, and more. Failure to manage the proper configuration can lead to a wide variety of security problems. When deploying servers, you must defend against malicious attackers who can exploit the vulnerabilities in these servers and applications.

Application vulnerabilities provide the potential for an unauthorized party to gain access to critical information, use resources inappropriately, and interrupt business or theft. Applications might be vulnerable to buffer overflows, which occur when a program attempts to store more data in a static buffer than it was designed to manage. The added data overwrites and corrupts memory, allowing an attacker to insert arbitrary instructions on the Web server or to crash the system or gain access. Applications might not adequately prevent introducing arbitrary code into the system that could be executed with the administrator privileges of the operating system. For example, a hacker might enter a command-line executable statement, such as into a legitimate Web site form under the guise of an "http request" to gain access to the Web server. If your security configuration allows, the hacker would receive the /etc/passwd file and have access to files, and access to usernames and passwords, which are stored on the Web server.

Many application logs contain sensitive information, such as passwords, session IDs, These logs and other sensitive files may be stored on the web server or back-end database that hackers can retrieve to perform unauthorized functions, view their content or compromise the resource.

Cybercriminals will examine applications and infrastructure to understand its design, identify any potentially weak aspects, and use these weaknesses to break or exploit the application. Server vulnerabilities can come from exposures in the server's operating system, server administration practices, or from flaws in the applications. These types of attacks can lead to the hackers installing a password stealing program and seizing full control of the machine.

Server misconfiguration attacks exploit configuration weaknesses found in servers. Many servers come with defaults turned on that might be unnecessary depending on the role of the server They might also have unnecessary services enabled, such as content management and remote administration functionality. Debugging functions may be enabled or administrative functions may be accessible to anonymous users. These features may provide a means for a hacker to bypass authentication methods and gain access to sensitive information, perhaps with elevated privileges.

Improper file system permissions are a threat to the confidentiality, integrity and availability of applications. The problem arises when incorrect file system permissions are set on files, folders, and symbolic links. When improper permissions are set, an attacker may be able to access restricted files or directories and modify or delete their contents. For example, if an anonymous user account has write permission to a file, then an attacker may be able to modify the contents of the file influencing the application in undesirable ways. An attacker may also exploit improper symlinks to escalate their privileges and/or access unauthorized files; for example, a symlink that points to a directory outside the web root.

5

The following table summarizes the typical types of attacks.

Attack Type Description

Denial of service Any of the network, web-server, or application-based attacks that result in denial of service, a condition in which a system is overloaded and can no longer respond normally

Exploitation of configuration errors These errors are our happen more often than you might think

Insider Attack (Intentional or Unintentional)

Admin with high privileges installs a malware or grants a user account with high privileges

Exploitation of application vulnerabilities Unpatched or unknown problems in deployed web applications

Attacks through other services Access through RDP, Telnet, FTP and SSH

Applied Example: Attacks on Web Servers

1. The Web server account is incorrectly given write access to the server's index file, "default.asp". An attacker accessing the web page might be able to modify the contents of the "default.asp" file.

2. The Web server account is incorrectly given access to system files such as password files, password hashes and critical operating system files. An attacker might be able to access and modify those files through the web server, such as when a directory traversal vulnerability is present.

3. The Web server account is incorrectly given script source access; an attacker might be able to view the source code of the Web application.

6

1.1. How to Protect Yourself: Developing Server Hardening Configurations

The following table summarizes the key points to consider when creating a hardening guideline for your server configuration. This configuration should be used on all servers, including ones that are used for testing.

Actions to take to protect a server

• Identify default files and directories that hackers could exploit

• Detect inadequate patch levels and vulnerable applications

• Point out poor passwords and controls

• Identify users that have too many privileges

• Identify applications and services that should not be installed and running

• Prevent unauthorized traffic to and from the system

Best Practices to consider when creating hardening guidelines for server configurations

• Configuring all security mechanisms

• Turning off all unused services

• Setting up roles, permissions, and accounts, including disabling all default accounts or changing their passwords

• Configuring logging and alerts

• Monitoring the latest security vulnerabilities published

• Applying the latest security patches

• Updating the security configuration guideline

• Performing regular vulnerability scanning from internal and external perspectives

• Conducting regular internal reviews of the server’s security configuration as compared with your configuration guide

• Running regular status reports to upper management documenting security posture

Questions to ask about the environment in which the application resides

What operating system is the server running?

What kind of protection does it have?

What other services does it offer?

Is the server exclusively used for this application? Are many applications sharing the same server? Is it a shared hosting server managed by a third party?

Who has access to the system and how? Shell access is the most dangerous because it gives great flexibility. Other types of access (FTP, CGI scripts) can become equally dangerous with effort and creativity.

7

1.2. Logging and Monitoring

While one of the most important administrator tasks is to configure a system to be secure, it is also necessary to know it is secure. The only way to know a system is secure (and behaving correctly) is through review of log files. Most administrators do not think about the logs before an intrusion happens. Only then do they realize their configuration mistakes when they discover that critical forensic information is not available.

Monitoring activity on the system can help identify a breach before the outcome leads to a leak. Most attack vectors for systems compromised can often be discovered in monitoring activity on the system. Detection and preserving evidence are key components to an effective response to an incident.

Log activity should be not only monitored but should be stored on a system other than the system where the activity is being created. Hackers will try and clear their tracks as quick as possible once they have gained control of the system.

8

2. Introduction to Critical Systems Protection

Symantec Critical Systems Protection (SCSP) can be used to secure and lockdown servers. SCSP installs as a kernel-level driver that protects the operating system and applications from hackers trying to gain access to the system through known or unknown vulnerabilities. SCSP can also be used to monitor and lock down application configuration files from being changed, which could weaken the security of the application.

The previous section addressed how server applications contain vulnerabilities and provided examples of how hackers can use buffer overflow attacks to try and gain access or launch commands. SCSP wraps around the applications and monitors for buffer overflow attacks, and prevents the attack from using the application to gain access to the system.

Running unnecessary services on a server could allow a hacker to exploit one of them and gain access to the system. When SCSP is installed on the server, rules can be written to only allow services that are needed to run, and prevent all others. Even if an application or a piece of malware was installed on the system and attempted to open a back door, SCSP would prevent this from occurring by controlling network communication to and from the server.

Often, applications running on a server might use an account that has more rights that what is needed, allowing access to configuration files and logs. If a different account is used and given write access to the wrong files, a hacker could gain access to the. SCSP can be used to restrict access to files based on what rights the user or application should have to those files.

Hackers will try and exploit applications that are running with privileged users to either use the user account to install a backdoor or create another user account for access. If a hacker cannot gain access to a system using an account that he hijacked, the hacker will often try and gain access to the system and create a new account.

Log files and debug files can contain information that can help hackers discover the purpose of the application. Hackers can also use such files to map out other systems in the network that are communicating with the server, such as a database system. SCSP can lock down the log files, only allowing certain users or applications from viewing the files. SCSP can also prevent the file from being removed from the system.

Administrators often need to restrict which internal systems can talk to critical servers. For example, an organization might have a back-end database server that houses information that is accessed by the web server application. If a hacker successfully performs a SQL Injection attack, he may be able to gain access to that backend database. By installing SCSP on the back-end database, administrators can write rules permitting communication only between those two systems. This configuration would prevent data from getting extracted from that database system.

2.1. Detection and Protection

Critical System Protection has two components that companies can deploy on their critical systems. One component provides prevention of potential security or compliance threats to the system. The other component will detect such violations but will not prevent them.

Several regulations require that companies deploy file integrity monitoring to monitor for critical system and application files changes. The detection component of SCSP can help companies meet this requirement. If the ultimate goal was to deny the changes in the first place, the prevention component would be more applicable. Detecting that svchost.exe was just modified is very different than preventing that modification from occurring. SCSP can impose resource restrictions to prevent the modifications of important files on the system.

In most large scale data breaches, a system was compromised and was used to launch attacks or target other high profile systems that contain the data that they attacker was after. In a lot of cases misconfigured systems and open shares allowed this leap frog attack to occur. Many times data is left sitting on a system where anyone who can access the system can access the data.

9

The out of the box detection policies can be used to alert on activity on a system that could be a compliance or security violation. Normal activity does not always mean good activity. A compromise to a system and the hijacking of an account can go unnoticed unless something is there to prevent the attack in the first place.

Many companies will deploy detection to get by the checkbox of meeting the regulation or to say that we are monitoring activity on our critical systems. As important as that is in the overall big picture of looking at the security posture of the system, things can still slip through the cracks if someone is not responding to those alerts.

2.2. Understanding the components of SCSP

SCSP has several components. These components can be installed on one system or installed in a distributed model.

The console is available as a thick client that can be installed on a system or accessed through a Web UI. The management server, data store and thick client are only supported to run under Microsoft Windows. The SCSP agents are supported to run under several different operating systems.

2.3. Ports and Communications

When deploying CSP in your environment, you need to make sure that the proper communication is available for the components. The following figure summarizes the key port and communication flows.

10

2.4. Deployment considerations

Platform Prevention Detection Microsoft Windows®

Windows 2000, 2003 and 2008, including 64-bit versions, Windows 2008 SP2 and R2 Windows NT

Windows 2000, 2003 and 2008, including 64-bit versions, Windows 2008 SP2 and R2, Windows NT

Solaris™ Solaris 8, 9, 10*

*includes x86, x86 VM, 64-bit & Global Zones

Solaris 8, 9, 10*

*includes x86, x86 VM, 64-bit & Local Zones Linux™ SuSE Linux Enterprise Server 8, 9,10

RedHat Enterprise Linux 3**, 4**, 5 includes 32-bit & 64-bit support

VMWare ESX 3.5 Host

SuSE Linux Enterprise Server 8, 9,10

RedHat Enterprise Linux 3**, 4**, 5 includes 32-bit & 64-bit support

VMWare ESX 3.5 Host

AIX™ Future release AIX 5L (5.1, 5.2, and 5.3)

HP-UX™ Future release HP-UX 11i v1 (11.11)**, v2 (11.23)** and v3 (11.31)**

HP Tru64 Unix V5.1B

Component Hardware OS Management Console

150MB free disk space 256 MB RAM Pentium III 1.2 GHz

Windows 2000 SP4 / Windows XP Pro SP1 Windows 2003 including 64-bit versions SP1, R2

Management Server

1GB free disk space (all platforms/databases) 1 GB RAM Pentium III 1.2 GHz

Windows Server 2003 Standard/Enterprise x64

Agent Windows

100MB free disk space (all platforms) 256 MB RAM Pentium III 1.2 GHz

SuSE Linux Enterprise Server 8, 9,10

RedHat Enterprise Linux 3**, 4**, 5

includes 32-bit & 64-bit support

VMWare ESX 3.5 Host Agent Solaris Sun SPARC™ 450 MHz

Sun SPARC32, SPARC64 Solaris 8, 9, 10

Solaris 10

Agent HP-UX Hewlett-Packard PA-RISC 450 MHz

HP-UX on PARISC

Agent AIX IBM Power PC (CHRP) 450 MHZ AIX

Agent X86 X86 Windows NT Server Windows Server 2003 32-bit Windows XP Professional Red Hat Enterprise Linux ES 3.0, 4.0 SUSE Linux Enterprise 8, 9, 10 Sun Solaris 10 (IDS only in non-global zone)

VMWare support VMware Workstation v5.00 and v5.54 VMware ESX v3.01 and 4.1

2.5. Database Sizing

By default SCSP installs with SQL Express 2005. Your data retention needs will dictate whether this default choice is appropriate. SQL Express has a limitation to 4 GB in size (4 million events). If your servers generate a lot of traffic, and you plan on retaining events for a long period of time, consider using the full version of SQL Server. If you are feeding the

11

events from SCSP to a log management or SIEM product, then the limitation might not be a problem. For example, if a deployment consists of 10 agents (for example, 10 Web servers), this equates to storing 200,000 events per agent. In this case, 5,000 events/day would equate to retention period of 40 days

If deploying on SQL server, the disk space needed for storing event data (data content and database overhead) can be sized at 1KB for each event stored (or 1 million events per 1 GB disk space). So a typical size of 5 million stored events will require about 5GB of database disk space.

All the other objects in SCSP (asset data, policy data, configs, and query/alert/reports) will often never take more than 2GB of disk space regardless of agents deployed.

So the primary consideration is to determine the average number of events to be generated by an agent each day and how long you wish to retain events in the database. Both of these variables are directly under your control. 20 GB of space is more than enough for CSP to function.

One of the key factors to database management is to enable purging, which by default it is off as shown in the following figure.

12

3. Installing SCSP

The following table summarizes the installation sequence for the different SCSP components.

Order of installation File to execute (in root CSP directory) Notes First: Server® Server.exe • For a POC, install all components on a

single system. You can install the console on a separate system or use the Web UI for management

Second: Console Console.exe

Third: Agent Agent.exe (To install agent on a Windows systems (except for NT). Use the other agent files in the directory to install other operating systems.

3.1. Server Installation

To install the server component using the embedded database:

1. Launch the installation by executing server.exe. This example assumes a server monitoring installation, in

which the default SQL Server Express 2005 database is acceptable

2. Choose the installation path for the Server.

13

3. Confirm the ports used for communication with the agent and the console.

If you are installing the agent on a system that contains an application that is already using port 443, ensure that no other host software conflicts with SCSP communications. Possible conflicts can occur with the following types of programs and software:

Host based firewall

Programs using SSL (port), such as IIS server, WebVPN, or Symantec Endpoint Protection Manager (if agents use SSL to connect)

4. Choose a password that will be used by SCSP to connect to the database.

14

5. Click Finish to complete the installation.

3.2. Console Installation

To install the console component:

1. Launch the installation wizard by executing console.exe.

2. Proceed through the wizard prompts.

3.3. Windows Agent Install

Symantec Critical System Protection agents support prevention and detection features.

• Prevention:Agents that support prevention features control behavior by allowing and preventing specific actions that an application or user can take. For example, a Symantec Critical System Protection prevention policy could specify that aWeb application may not spawn other processes, including dangerous processes like viruses, worms, and Trojan horses.

15

• Detection: Agents that support detection features control behavior by detecting suspicious activity and taking action. For example, a Symantec Critical System Protection detection policy could act when it detects an attempt by an unauthorized user to gain illegitimate access to a system. No action would be taken for failed attempts that resulted from normal behavior such as an expired password or a user forgetting a password.

Before installing the agent, the certificate file that was created during the management server installation needs to be copied to the system where the agent is being installed. On Windows installations, the certificate is in C:\Program Files\Symantec\Critical System Protection\Server. The name of the file is called agent-cert.ssl. Copy this file to a directory on the agent system.

Note: For information on installing the agent on platforms other than Windows or on using the silent installation, refer to the CSP documentation. In general, you need to be logged in as the superuser and perform the following tasks:

• Insert the installation CD

• cd /mnt/cdrom

• Run the ./agent-os.bin file for the appropriate operating system.

To install the agent a Windows platform:

1. Launch the installation wizard by executing agent.exe.

2. Accept the default installation path for the agent of choose a new folder.

16

3. On the Agent Configuration page, specify a name for the agent that will appear in the CSP console. Also specify a Polling Interval to control how often the agent will poll the manager for updates.

4. Click Enable Intrusion Prevention to allow prevention policies to be deployed. When you enable prevention the system must be rebooted before a prevention policy will work.

5. Set the Enable Real-Time notification option to configurations to be pushed to an agent. If this setting is disabled, the agent will only pull down configurations during the set polling interval.

6. On the Management Server Configuration page, specify the management server that will manage the agent .

17

7. Specify the agent port that was configured during the management server installation. If the port was changed

because this system has an application that is using port 443, change the port number appropriately. Make sure that the agent port matches what was specified at the management server.

8. Optionally specify fail-over servers in the Alternate Management Server(s) field.

9. In the Management Server Certificate field, specify the path to the certificate that you copied from the management server.

10. Click Next.

11. If configuration and policies have been pre-defined in the console, you can configure agent management groups.

This option is helpful if, for example, you want all your Web servers to go into a specific group that has a prevention policy assigned to it. Agents assigned to a group will receive policies pushed down to its respective group. Note that you can leave this page blank, and assign the agent to the group after the installation.

12. On the Service User Configuration page, specify the account the agent will run as on the local system. You would usually leave the default account as LocalSystem unless you want it to run as a different account. The account must have administrator privileges if you plan on using a different account.

18

13. Click Finish to complete the agent installation.

19

4. Working with SCSP

Once SCSP is installed, log in to the management console to manage policies and the agents.

When you login, use symadmin for the user name and leave the password field blank. You will be prompted to set a new password.

4.1. Console Page

Once logged in, you will be presented with the SCSP console.

From the console screen you will see the agents that you registered to the manager.

20

The Home page provides current agent, event, and Internet security statistics that show the health and status of your network. You can analyze this information to identify problem computers and threats to your network's security. From this page, you can :

• View statistics for your entire network

• View statistics for agents that support prevention features

• View statistics for agents that support detection features

• View the Symantec ThreatCon rating

• Access popular management console tasks

You can view the Home page in all three console views (Master, Prevention, and Detection.). Each view presents a customized view of agent and event statistics.

4.2. Assets Page

Use the Assets page in the management console to apply policies and configurations to agents, and to monitor the health of your agents. Assets are the computers on which agents are installed. Agents are the software that you install on the computers that you want to protect.

From the Assets page, you can

• Determine how agents communicate with the management server, and which events agents send to the management server

• View information about the agents in your network, including which policies are enforced on agents, and how the agents are configured

• View a list of agents that run on Windows, Solaris, Linux, AIX, and HP-UX operating systems

• Apply policies and configurations to agents and groups

• Delete an agent’s record from the management server database

When an agent first registers with the management server, it tells the server whether it supports prevention features, detection features, or both. The agent is placed in a default group in each console view that it supports, unless a group was assigned during agent installation.

21

Each console view lets you create agent groups in different ways. Each view has its own rules about policy and configuration assignment to agents, and lets you perform specific actions.

Agent Health is the first column in the agent pane. The Agent Health column indicates whether an agent is in contact with the management server. Place your mouse cursor over the Agent Health column to view a pop-up tool tip.

The Agent Health column displays one of the following icons:

● A green circle icon indicates that an agent is healthy.

● A yellow circle icon indicates than an agent is possibly offline and experiencing minor problems.

● A red circle icon indicates that an agent is offline and experiencing major problems.

The Shield Icon indicates that an agent is protected. A Shield Icon with red X indicates that an agent has limited or no

protection. If an agent has a shield with an X it could mean that the policy that was pushed down contains problems

If an agent is not listed after you install it, check the SISIPSService.log file found under the scsplog directory on the agent.

4.3. Prevention Policies

The Symantec Critical System Protection prevention policies protect against inappropriate modification of system resources. The policies confine each process on a computer to its normal behavior. Programs that are identified as critical to system operation are given specific behavior controls; generic behavior controls provide compatibility for other services and applications.

The following graphic summarizes the overall flow during the system hardening process as it relates to Prevention Policies:

22

To begin, click the Prevention View tab to work with prevention policies.

The Symantec Critical System Protection prevention policies often require tailoring for your site-specific needs. For example, the base policies limit network connectivity to and from applications. If your organization requires protection beyond what the Symantec Critical System Protection prevention policies provide, you can increase or decrease the restrictions enforced by the policies.

Depending on the CSP policy that is deployed, good guidance to follow when creating firewall rules includes:

• Deny everything by default

• Allow only what is necessary

• Treat internal networks and servers as hostile and only give them minimum privilege

SCSP provides several pre-installed prevention policies. The degree of protection and lockdown you want on the server will depend on which policy you use. You can only have one prevention policy deployed per system.

The two prevention policies that we recommend to be chosen for servers are the Windows Core Prevention Policy and the Windows Strict Prevention Policy.

4.3.1. Windows Core Prevention Policy

The Windows Core prevention policy, suitable for most servers and workstations, provides basic protection for the operating system and common applications, while enabling a highly compatible environment for all other programs. The core policy prevention prevents remote computers from making inbound network connections to an agent computer. Exception lists allow for remote computers to make inbound network connections. The core policy denies services from launching programs that may be used by exploits and that services normally do not launch.

The core policy provides specific behavior controls for the core operating system services and the following application services:

• Microsoft Exchange Server

• Microsoft SQL Server

• Microsoft Internet Information Server

23

The core policy treats every application as safe. Safe privilege is subject to Symantec Critical System Protection resource restrictions and resource list restrictions. Any program that you do not want Symantec Critical System Protection to interfere with should be allowed safe access. The Core policy also gives safe privileges to the Windows administrators group. When a user logs on to an agent computer using an account that is a member of this group, all default interactive programs and default services that are run by this user are given safe privileges.

The Core Policy will have the less impact on a system as far as preventing applications from running or accessing the resources that they need. If the main focus is to protect the operating system and prevent zero day attacks, the Core Policy is a good choice.

4.3.2. Windows Strict Prevention Policy

The Windows Strict Prevention Policy provides all the protection of the Core prevention policy, and also provides additional restrictions on interactive applications. The Strict Policy enforces additional restrictions on interactive applications, including blocking networking, blocking modification of executable files, and treating Windows administrators as normal users.

Common interactive applications work under the Strict Policy, but you may need to relax the additional restrictions for some interactive programs. For example, the Strict Policy denies interactive programs from writing to disk. The policy would block downloading of binaries from the internet or the saving of an email attachment.

The Strict Policy also denies network access from default services and default interactive programs. This means arbitrary programs are blocked unless they are placed in the exception list. The strict policy allows outbound and inbound network connection on ports 80, 135, 389 and 443.

The Strict Policy gives standard privileges to default services and default interactive programs. Standard (default) privilege is subject to core operating system resource restrictions, Symantec Critical System Protection resource restrictions, and resource list restrictions.

The strict policy:

• Protects auto-start locations as read-only. Because many programs attempt to write to these auto-start locations in their normal Privilege level

• Gives no special privileges to Windows administrators. You can use policy options to set privileged users and user groups.

• Gives standard privileges to default services and default interactive programs.

• Restricts the types of e-mail attachments that can be opened.

• Denies interactive programs from writing executable files on disk. This means, for example, that the policy denies downloading binaries from the Internet or saving executables sent as e-mail attachments.

• Denies network access from default services and default interactive programs, except for specific ports. This means that arbitrary programs trying to access the Internet are blocked unless specified in the exception list. The Strict policy allows outbound network connections on ports 80 (HTTP), 135 (Location Service), 389 (LDAP), and 443 (HTTPS).

• Blocks COM object registration and ActiveX component installation.

• Blocks changing network settings, such as the DNS servers. Many VPN products change the DNS server setting when a tunnel is created or terminated. The policy blocks these changes, and the tunnel likely will not work. You can add the VPN program to the safe privilege list to allow software to work properly. The DHCP client also changes the DNS server setting. The policy specifically allows the DHCP client to make the changes, so systems using DHCP do work with the Strict policy.

• Blocks the ability of the system to recognize a Bluetooth device.

24

4.3.3. Creating a new policy for a server using the Wizard

When you create a new policy based on an existing policy it takes the settings from the policy that you chose. When creating a new policy this way it brings up a wizard that guides through some tuning options. This is the quickest and easiest way to build a policy for a server.

To create a new policy using an existing policy:

1. Click on the plus key or right mouse click on a policy that is found under the Prevention Tab.

2. Choosing the Windows Core Policy as the basis of the policy we are creating called Web server.

25

3. All the default settings for the Core Policy will be used. Any changes made using the wizard will be applied to the new policy called Web Server.

4. It is always a good practice to either start off using the wizard to build a policy or make a copy of a default policy and rename it. This way if there is a problem you still have the default policy to fall back on.

5. We mentioned before the differences in the Core and Strict policy. There is two ways you can look at this. One way would be to start with a more strict policy and lessen the restrictions as opposed to starting with a policy that is less secured and tighten it.

6. To start we will want to disable prevention.

With the policy set to Disable, SCSP will monitor, log and alert just as if the policy was active, but will not prevent actions from occurring. This configuration is always recommended when first deploying a prevention policy. As the activity is getting logged, you can monitor what would be happening and adjust the policy if a process, application, or activity is getting blocked or prevented that should not be. This is important when deploying to servers since as you do not want to accidently deploy a policy that could have a negative effect on the server. For customers who are reluctant to deploy prevention on the system due the affect the policies may have, this is a good starting point. Once you have the system running the way that you want it, you can enable prevention.

26

7. If installing SCSP on systems that have direct connections to other servers (back-end database servers, etc), use the settings on the Configure Inbound Network Access page to limit network connectivity to these systems from any other system besides what is authorized.

Limiting communication from servers to the outside world can prevent data leakage as well as malware from “phoning home.”Several regulations require that systems that contain PHI, card data, and personal data should have secured communication to the outside world. Communication on certain ports that might be needed can be configured in the policy to allow for example traffic on port 80 if required.

27

8. Configure the Outbound Network Access page if needed for specific applications.

By default SCSP limits outbound connections except on certain ports. If the server is running applications that need to make outbound connections, you can specify them here. For example, a Web server might need connections to a back-end database so it would need to make a connection outbound on port 1433 (SQL).

9. If necessary, complete the Configure Outlook attachments pages to override the default restriction of opening attachments. Most customers will not be running Outlook on a server.

28

10. If you have an application running on the server that needs access to core OS resources to function, the application can be placed in Safe Privileges. Any program that you do not want Symantec Critical System Protection to interfere with should be allowed safe access.

If you want an application to have full access to the system and bypass SCSP protection, you can place it in Full Privileges. Even when a product is in the Full Privileges list, it is still subject to remote network restrictions. This means that, even though you have given the application full rights to the system, the traffic to that system is still limited based on the network list are created.

Customers that are using software distribution tools to push out patches and updates would give those safe privileges to the system. These applications when installing patches might need to have certain rights.

29

11. Use the Give Users Extra Privileges page to manage rights for users.

Some users that are logging into servers should need to have more rights when running certain interactive type programs. If the program requires access to core OS resources when the user runs the application, the user should be places in Users with Safe Privileges. This is somewhat the same as placing an application in Safe Programs, but now you are granting it to the User and not to the program. If the programs the user is running needs full access to all resources, than the user should be placed in Users with Full Privileges.

30

12. Use the Give Groups Extra Privileges page to manage rights for groups.

Some Groups that are logging into the Web server (for example) should need to have more rights when running certain interactive type programs. If the program requires access to core OS resources when the users of this group run the application, the user should be places in Groups with Safe Privileges. This is somewhat the same as placing an application in Safe Programs, but now you are granting it to the Group and not to the program. If the programs the user is running needs full access to all resources, than the user should be placed in Groups with Full Privileges.

13. Use the Allow Users to Override the Policy page to allow logged-in users to disable the policy.

31

In cases where you have users or groups that need the capability to bypass the prevention policy that is being deployed to the server you can place that user or group into one of this list. This allows the user to launch a command to disable prevention on the system. This privilege should only be granted if CSP prevention is really required to be disabled.

32

14. Users that are going to be managing the CSP agents on the servers might need to have access to run the command-line tools on these systems in certain cases. These users are groups can be placed in this list to give them that privilege. Refer to the documentation on what these command line tools are and what you can do with them.

15. Use the Allow users to run the agent event viewer to give rights to logged in users.

33

Users that are going to be managing the CSP agents on servers might need to have access to view the local events on these systems in certain cases. These users are groups can be placed in this list to give them that privilege.

16. Click Finish after reviewing the Summary.

34

4.4. Applying a Policy

Before using one of the pre-installed policies, first make a copy of the existing policy and rename it. You can do this by right-clicking on a policy and making a copy of it. Afterwards you can rename it.

You should make a copy of the policy and rename it based on the type of system or policy. This way as you are changing or creating new policies for different system, you know which policy belongs to which system. You can also use the previous method of creating a policy using the wizard. The benefit to using the wizard is that you can do some tuning on the policy before deploying.

When first deploying a policy, the policy should be set to Disable prevention.

35

With the policy set to Disable, SCSP will monitor, log and alert like the policy was active, but will not prevent. This is always the recommended approach when first deploying a prevention policy. As activity is occurring on the system, it will log the events and tell you like prevention was enabled. As the activity is getting logged, you can monitor what would be happening and adjust the policy if something is getting blocked are prevented that should not be.

To deploy a policy you can either right mouse click on the policy or apply it to the asset or group or from the Asset screen you can right mouse click on the asset or group and apply policy.

If you apply a policy to a group, all the assets that belong to that group will have that policy pushed down to them.

To create an agent group, follow the procedure below:

1. In the management console, click a console view tab.

36

2. In the management console, click Assets.

3. If you are creating a detection policy group, select a domain.

4. On the Assets page, select the default group or another group, and then right-click New. A agent group is created with the New Group

5. Type the name of the agent group, and then press Enter

When you are applying a policy to an asset or group, note the following choices for merging the changes:

The Take the new option settings option ignores the target policy and uses the option settings in the template policy. The Merge the changed options will merge the option settings in the target policy with the option settings in the new policy.

4.4.1. Monitoring a Policy Behavior

Once a policy has been deployed and prevention is disabled, you can monitor the activity that is being allowed and blocked by viewing the Monitor tab and going to Real-Time monitors All Events.

You can also create a New Monitor to only view the exceptions that occur. For example after deploying the strict policy on a Web server, you should want to see what effect it would have on other applications that are running on the system. You would want to make sure you first had the policy set to prevention disabled before deploying. Once deployed you can create a new monitor to filter on Event Disposition = Denied. This would show any applications or potential connections to the Web server that would be denied if this policy was deployed.

4.4.2. Editing a policy

After determining which restrictions to relax on the policy, you can edit the policy and enable prevention. If you have applications that would be affected by this policy, the policy can be tuned to add exceptions for those applications. To understand where to start tuning a policy, we can break down the different options.

37

You have the following options to choose from:

• Global Policy Options—Applies to all processes on a system. Changes made at this level will affect everything on the system. One use case is that you want a certain application or services to have access to a folder or file, but you want to prevent all other applications from accessing that folder. As an example, there is no reason why an application or service except the Web Server application (for example) should be able to write to the Web server directory where the configuration files and logs exist. You can restrict access to that directory at the global level, but allow access at the lower lever for that application.

• Service (daemon) options—Applies to services that run in the background. These can be either operating system services or application server programs. Application services are not part of the core operating system. Application services are usually installed separately after the operating system is installed. By default, there is one created for Internet Information Services and Microsoft SQL Server that can be used for Web sites or back-end database servers, and Apache for Unix. If a change is made at this level it will override a change made at the group level. An example to this is by default no traffic is allowed inbound to the system if Microsoft Internet Information Services allows traffic inbound to port 80, 443, 389, 636, 3268 and 3269. If you have a service that you want to control separately from others you can define it under the Custom Service Option. Most process sets and their associated behavior controls are tailored for a specific service or application.All other services and applications are placed into the default process sets in their Service Options and Interactive Program Options groups.

• Interactive program options—Applies to programs that are launched by the users logged on to a system. The Interactive programs option is divided into several areas. Global applies to all Interactive programs on the system. Specific are several programs that are defined out of the box with pre-built settings. Full Interactive Programs would give an application full privilege on the system, this would bypasses SCSP protection. Safe Interactive Program is subject to Symantec Critical System Protection resource restrictions and resource list restrictions. Custom Interactive Program allows you to define settings specifically for a unique application. Default Interactive Programs allows you to define settings that will apply to all applications that fall under here. All interactive programs that are not defined under Custom will fall under Default. An example to this, on a Web server for example, you would want to prevent launching some applications that could lead to the system getting compromised or opening up a backdoor on the Web server. If you want to lock down a Web server tightly and be able to specify only some applications that can run on it. The Limited Execution policy for

38

Windows can be considered. This policy prevents all Interactive programs from running unless specified. This policy is good for dedicated servers.

4.4.3. Host Firewall Protection

Though a network firewall is necessary for every network, individual hosts should have their own firewalls. For one, the main firewall is misconfigured, breaks down, or has a flaw. It’s also helpful to protect from other hosts on the same LAN and from hosts from which the main firewall cannot protect (e.g., from an internal network).

Whenever you design a firewall rule for a web server, follow the basic guidance:

• Deny everything by default.

• Allow only what is necessary.

• Treat internal networks and servers as hostile and give them only minimal privileges

Using Netstat can provide you with a list of services. From there you can determine which ones are necessary and write rules to allow connections only to and from those.

39

4.4.4. Application Buffer Overflow Protection

Buffer overflow occurs when an attempt is made to use a limited-length buffer to store a larger piece of data. Because of the lack of boundary checking, some amount of data will be written to memory locations immediately following the buffer. When an attacker manipulates program input, supplying specially crafted data payload, buffer overflows can be used to gain control of the application.

Buffer overflows affect C-based languages. Since most web applications are scripted (or written in Java, which is not vulnerable to buffer overflows), they are seldom affected by buffer overflows. Still, a typical web deployment can contain many components written in C, such as:

• Web servers, such as Apache

• Custom Apache modules

• Application engines, such as PHP

• Custom PHP modules

• CGI scripts written in C

• External systems

With a prevention policy deployed on your web server CSP, you can protect these components from being attacked and used to gain control of the application.

40

4.4.5. Application Lockdown

As a good practice, administrators should lock down application binary, logs and configuration files. To illustrate the danger, consider the following scenario.

Depending on the account that the Web server is running under, an attacker could use that account to break in and then subsequently replace the httpd binary with something else to ultimately shut the Web server down. The administrator, thinking the Web server had crashed, would log in and attempt to start it again and would have fallen into the trap of executing a Trojan program.

As a best practice, no one other than the root use should have the ability to write to the Apache binary files or the logs and configurations. To ensure this within SCSP, a prevention policy can be used to restrict access to files and folders. If the restriction is done at the group level, it would apply to all applications and services running on the box. Restrictions can be lifted at the different levels if an application or service needs to read or write to a specific director or file. In this case we will prevent anything from having access to the apache binary files or logs and configurations

Allowing any other account to have write access to the httpd binary would give that account privileges to execute anything as root.

4.4.6. System Variables

System variables can be used throughout prevention and detection policies. User specific variables cannot be used.

Examples

%PROGRAMFILES%—Returns the location of the default install directory for applications.

%SYSTEMDRIVE%—System returns the drive containing the Windows root directory (i.e., the system root).

%SYSTEMROOT%—System returns the location of the Windows root directory

41

%WINDIR%—System returns the location of the OS directory

4.5. Detection Policies

A detection policy is a collection of rules that is configured to detect specific events. Detection policies define that system events or user-defined criteria are selected, which criteria are ignored, and what actions are performed after select and ignore criteria are met. The Symantec Critical System Protection detection policies monitor events, files, syslogs, and registry keys to report suspicious behavior. Some policies require that you enable specific Windows features; these features may also require a configuration change. Other types of configuration changes should also be needed, depending on the policy.

A system can have more than one detection policy assigned to it. Policies can also be assigned to groups. These groups can be based on location, operating system, or system application. Once a system is assigned to a group, that policy will be assigned to the system.

4.5.1. Baseline Policy

When performing a POC, the best detection policy to start off with is the Windows Baseline Policy or UNIX Baseline Policy, depending on the operating system. This policy is a combination of several individual policies with updates and more granular control. The policy allows you to disable components against which you don’t want to monitor. The individual policies do not allow you to show the strings that they have been written to monitor.

Q: Is there anything I need to disable or change in the Windows Baseline policy before deploying?

A: Yes, consider disabling autostart keys under Settings, Windows Baseline Detection Options System Registry Monitor, disable the AutoStart Keys. This option will flood the monitor with events.

Q: Is there anything I need to disable or change in the Windows / Unix Baseline policy before deploying?

A: Yes, consider not monitoring directories that are constantly being updated or files are changing. An example to this would be the print spooler directory on Windows or /Var/logs on Unix.

42

During a POC situation, go through each section of the Baseline policy with the customer and enable anything the customer wants to track. Disable anything the customer does not want to track.

If the customer is concerned about malware or attacks against critical systems, consider enabling the Local Account Locked Out, Account Created, and Account Changed settings.

4.5.2. Windows Template Policy

The Windows_Template_Policy is a reusable workspace container that creates custom rules. You can customize this policy to monitor:

• NT Event Log (Windows Event Logs)—Monitors the Window Application, System or Security logs for Event ID codes or strings.

• File Watch (File Integrity Monitoring)—Monitors files on the system for changes or what has changed in a txt or ini file.

• Registry Watch (Registry Watch)—Monitors registry keys or trees for changes.

• Text Log (String Watch)—Monitors log files for string matches. Text Log is where you can also define a Virtual Agent to monitor log files from an unsupported platform.

44

To use the Windows_Template_Policy:

1. Create a new policy and choose the Windows_Template_Policy as the starting policy, and then click Next.

45

2. Choose My Custom Rules, and then select New.

From here, you can define the Display, Category and Identifier. Display Name is what appears in the policy editor. The available Categories are:

• NT Event Log

• File Watch

• Registry Watch

• Text Log

• Prevention Watch

• Generic

4.5.3. NT Event Log

Use this option to specify a Windows Event ID to monitor in the Application, System or Security log.

46

From here, you can:

• Specify the Windows Event ID to monitor

• Specify a pattern in the event

For Example:

Windows Event ID to monitor 626 (User Account Enabled)

Event Patterns: * Any user account

4.5.4. File Integrity Monitoring

Use this option to specify a file or files to be monitored for changes

47

Q: Why are “Monitor Checksums” and “Monitor Access Times” in both the policy options and the Detection Parameters object? Which should I use?

A: The settings in the Detection Parameters object are obsolete and should no longer be used. They have been replaced by the corresponding policy options. Using the options in the policy gives you greater granularity in using these options. Both options do have performance impacts and we do not recommend using them for all files without careful consideration. Rather, we recommend using these options on a selected subset of the files you monitor that warrant the extra monitoring.

Q: Does real-time file monitoring work on all drives?

A: Real-time file monitoring monitors all disk, CD, DVD, and floppy file systems. It does not monitor network file systems in real-time. Network file systems are handled with the traditional polling-based model.

Q: I want to monitor for changes in a file which option should I use?

A: The minimum monitoring is to select the “Monitor file modification. ”We also recommend selecting “Monitor file creation” and “Monitor file deletion” to be sure you will notice if the file is deleted and re-created rather than simply modified in place. Choosing these options will tell you if any of the file attributes have changed. This includes file size, modification date, owner, name, etc. On platforms that support real-time monitoring, these options also tell you what user and what program modified the file. But they do not directly monitor the data in the file.

If you want to be sure to tell if the data in a file has changed, you should also select “Monitor File Checksum” in the policy. But you must be aware that monitoring checksums does have a performance impact

If you want to be notified of specific content changes in a file you can use the “Report File Differences” option. For instance, if you wanted to monitor a text or ini configuration file for changes to a specific setting you would use this option. The option only works for plain text files and should only be used on relatively small files. This option does

48

require keeping a baseline of the file contents in memory so the total size of all files being monitored for differences affects the memory usage of the IDS Service.

Q. How do wildcard characters and recursion levels work in IDS file monitoring?

A: When you use wildcard characters in IDS file monitoring, the following rules apply:

• Only the asterisk (*) and question mark (?) wildcard characters are allowed

• The asterisk (*) stands for one or more characters

• The question mark (?) stands for a single character only

• Wildcard characters are allowed only in the last element of file path. You can only place a wildcard character after the last slash in a file path. The following are examples of valid uses of wildcard characters in a file path:

C:\temp\*

C:\temp\L1\*.txt

C:\temp\L2\*file*.ini

C:\temp\L1\file?.ini

C:\temp\L1\file?.*

The following are examples of invalid uses of wildcard characters in a file path:

C:\temp\*\L3\*.txt

C:\temp\L2\*\file?.txt

4.5.5. Registry Watch

This option watches changes to user-specified registry keys. You can watch changes to key/value, operations (created, modified, deleted), operation results (success, failure, either), and process.The key/value string supports wildcard characters. Multiple key/value strings are allowed in a rule. The filtered keys appear in the Registry.ini file on the agent computer. You can watch all operations or none (meaning any activity). You can filter the result of the operation. The process can be specified only once in the rule.

49

4.5.6. Text Log Watch

Use the Text Log Watch option to monitor for certain items to appear in log files.

50

Key options:

1. Specify the text log to monitor

2. Where you can specify a virtual name to represent logs coming from an unsupported platform

3. Specify item in the log for to monitor for

This rule type monitors user-specified text patterns in user-specified text logs. The rule type is associated with the text log collector, which watches for matches in user-specified text logs.

The text log rule type is also used with virtual agents. Symantec Critical System Protection recognizes and processes virtual event data indirectly via a text log rule, where you designate resulting events as originating from virtual agents. In a manner similar to specifying a user-defined text string, you can identify a source system identification tag that indicates the events are from an agent other than the host machine that processed the events.

4.6. Prevention Policy Creation and Profiling

This section walks through the process of creating a custom prevention policy, using lockdown of an Oracle server as a representative use case.

4.6.1. System variables

System variables can be used throughout prevention and detection policies. User specific variables cannot be used. Examples of System Variables include:

%PROGRAMFILES%—Returns the location of the default install directory for applications.

%SYSTEMDRIVE%—Returns the drive containing the Windows root directory (i.e., the system root).

51

%SYSTEMROOT%—Returns the location of the Windows root directory

%WINDIR%—Returns the location of the OS directory

4.6.2. Resource Variables

Resource Variables can be used in the resource path with defining a resource restriction. Resource restrictions can be used to restrict access to files, folders and registry keys. Examples of Resource Variables include:

C:\*.pdf This will affect all PDF files on the system

C:\temp\* This will affect everything under the temp folder and sub folders

C:\temp\*.pdf This will affect all PDF files under the temp folder and sub folders

52

4.6.3. Custom Table Options

When creating a custom table to reference a list of applications, there are several parameters used to reference parts of the table.

:Prog References the program name field in a customer table

:cmdline Passes arguments to the program referenced above

:id References the user account that is allowed access to the run the program

:groupid References a group that is allowed access to run the program

53

4.6.4. Profiling an Application

When deploying a CSP policy on a system, the policy might have an effect on certain applications running on the box. There are several ways you can handle this situation. First, you can use the profiling feature in the policy to learn which resources that application is using. This feature allows the application to run without CSP prevention getting in the way.

54

While profiling, the application will run as normal but all actions are recorded. You can view the resources the application is trying to access by using the Monitor tab in the Profile section, as shown in the following figure.

55

You can use the information provided about the product during the profiling session to build a PSET for the winscp

machine

56

If the application fails to run properly after the policy is deployed, several options are available. One option is to move the application into the Alternate Privilege Group with Safe or Full Privileges. This option will assume that you trust the application running, and, as such, it will run without the prevention policy having effect on it. If an application is not defined by the policy, it falls under the Default Option restrictions. Changes to the Default restrictions will apply to everything that is covered by it. You can define an application under the Custom Options or create a new process set (PSET) for it under My Custom Programs. You should always start off with Prevention disabled and monitor the affect the policy has on the system. The monitor tab will allow you to tune the policy allowing actions that would normally be blocked by the restrictions of the policy.

4.6.5. Example: Locking Down an Oracle Server

This example demonstrates how to create a prevention policy that locks down a critical server, in this case Oracle 10 Express Edition. This example will use the Strict Policy as the base policy to lock down the Oracle Server. Because there is no PSET created for Oracle 10 Express so the product will be covered under the Default Option restrictions unless we specify it under Custom Options or create a Custom Application PSET.

Oracle Express has two services that load

57

Any child process or component of Oracle that is spawned by one of these two services will have the same restrictions placed on it as the parent. You can create separate Custom PSET to place different restrictions on child processes if required.

We will use the Policy Wizard to start building the policy for our Oracle Server. The wizard can be a starting point to establish a baseline policy for the server. When using the wizard you will start by choosing one of the out-of-box policies as the basis for the Oracle Server policy. It will take the settings of that policy.

We will want to start off by Disabling Prevention. This means that the Critical System Protection will log what the policy will do first to the system and Oracle before performing any blocking.

58

Critical System Protection has a built-in stateless firewall that can be used to control access to and from the system. An internal Oracle System should only be accessed from certain systems on the network. You can configure the Inbound Network Access list to limit the systems that should be talking to the Oracle. Note that when using the Policy Wizard to create the inbound list, you cannot use wild cards and lists.

59

Just as important as creating a list of the systems allowed to talk to the Oracle server is creating a list of what applications on the Oracle server are allowed to communicate freely on the network. This restriction prevents an administrator or someone else from installing an application that could open up a backdoor or a vulnerability that can be subsequently exploited. On the following screen, you can define which applications on the Oracle Server you want to be able to communicate freely on the network. By enabling the Prevent checkbox in the following screen, only the applications that are listed or ones that are allowed in the policy would be unable to make outbound connections. This screen is only for interactive applications not services running on the box.

60

The following screen allows you to restrict Outlook or Outlook Express from opening attachments. Outlook would probably not even be installed on an Oracle server, but if it is, we would definitely not want someone using the applications to open attachments.

61

If you do not want the prevention policy to restrict an application running on the system, you can allow that application to run in Safe or Full privilege mode. For example, you might trust Oracle to run on the system but you do not want the OS resource restrictions that are put in place by the Strict Policy to get in the way. By default the OS resource restrictions could prevent Oracle from accessing or modifying registry keys, system directories or executables. Running under Safe mode, Oracle would not be able to access CSP resource protection or if the user defines a restriction.

If a software distribution application is running on the system, you might let it run in Safe or Full privileges. This way when patches and updates are being deployed you do not have to worry about CSP preventing updates.

62

Some users might need to be granted the ability to run interactive applications on the Oracle server without the prevention policy restricting that application. This needs to be done with caution since this option permits any interactive application on the box without any restrictions in place. If user-defined restrictions were put into place, they would still be active as long as the user is running with Safe Privileges. If the user is running with Full Privileges, than he or she would have full access to the system.

When defining a user you can specify a domain\user if you want to restrict a domain account, as shown in the following figure.

63

Some groups might need to be granted the ability to run interactive applications on the Oracle server without the prevention policy restricting that application. This needs to be done with caution since this allows them to run any interactive application on the box without any restrictions in place. If user defined restrictions were put into place they would still be active as long as the user is running with Safe Privileges. If the user is running with Full than they would have full access to the system.

64

If a user or group needs to be able to disable prevention on the system you can specify them in the policy. This allows the user or member of group to run the sisipisconfig – i. This command line switch can be used to enable and

disable prevention. If prevention is disabled or enabled, the system will require a reboot.

66

The SISIPSConfig.exe, located in the CSP\Agent\IPS\bin directory, allows you to reconfigure the agent.

67

A local Event Viewer, found on the system on which the agent is installed, allows you to view the events local to the system that were collected by the agent, based on policy violations or management events. The following screen provides configuration options for the Agent Event Viewer.

Once we have our base Oracle policy defined, we can either use data that we collected from profiling Oracle or we can deploy the policy with prevention disabled and see what type of policy violations we encounter.

4.6.5.1. Working with Resource Restrictions

By profiling Oracle.exe service we can see that it requires read access to the Oracle directory and to the Oracle registry key trunk. From here we can start modifying the policy to give Oracle the rights that it needs. We might also want to put in restrictions to prevent other applications or users from accessing the Oracle directory.

68

Because Oracle is not covered by the out-of-the-box policy, we can either leave it running under the default service option or we can define it as a Custom Program Options. If you define multiple applications under this option, any restrictions that you give will apply to all of them running. Using the Custom Options is effective for some use cases where you might be only defining one application on the system or when you want to apply the same restrictions to multiple applications. The Custom Service Options configuration screen is shown in the following figure.

If you are planning on having multiple applications running on the system you want to create individual PSETs. You can create these under My Custom Programs.

69

When creating a Custom Control for a new application, it will probably need to be broken down into several PSETs. You will need one PSET to handle the interactive side of the application. These are the components that are launched by the end user. You will also need one to handle the services that run in the background.

Example

Oracle.exe— Service

Oradmin.exe—Interactive Program

Sqlpluse.exe—Interactive Program

Once the policy is applied, some of the OS components might be affected by the policy trying to read files in the Oracle directory.

In this case Oracle.exe runs in the background, so we will assign it to the PSET called oracleservices.

70

Assume for example we want to prevent anyone from making modifications to the Oracle directory, except for the application itself. Applying a no access restriction at the Global Level will prevent any user or application from accessing the Oracle directory unless they are granted privileges at a lower PSET level.

71

It is important when creating a prevention policy to understand the hierarchy. There are several different layers of a prevention policy:

• Global Policy Option – This applies to everything running on the system. This is mostly true except for the exception if you disable prevention at this level it applies to the whole policy. Also the policy override section applies to the whole policy. Individual PSET settings will override Global Policy settings except for the two just mentioned. If there is a deny at the Global level but an allow at the individual level it is allowed.

• Service Options – This applies to background services running. Under the Service Options there is a General Service Options area. Anything that is defined here will apply to all services running on the box, unless the individual defined PSET for a service allows. Also under Service Options is a Default Service Options which is where services not defined by the policy will fall under.

• Interactive Program Options – This applies to applications launched by the end-user. Under this is a General Interactive Program options area. Anything that is defined here will apply to all applications running on the box, unless the individual PSET for an application allows it.

It is important to understand how restrictions work. The settings at the individual PSET will supersede the rest of the policy. After the individual PSET level the settings at the General Options level is next line followed by Global.

After we apply this policy to our Oracle server, we can use the monitor tab to see what kind of effect the policy will have on the system. Also, as we try and launch certain tools on the server we can see if the policy is preventing the application from running properly. An example of a typical error message caused by a misconfiguration in the prevention policy is shown below.

72

To troubleshoot, we can look at the Monitor tab. We can immediately see a number of exceptions

1. Oracle.exe is being denied the ability to access its directory

2. Several other applications are denied access to the Oracle directory.

To address the issue with Oracle being able to access its files, we can create an exception in the Oracle Services PSET to allow Oracle.exe have the ability to write to its directory.

73

The global level was set to deny all programs and users from accessing the directory, but we have now removed the restriction for anything that is defined in the Oracle Services PSET. If we go back and look at our Monitor tab we should start seeing writes allowed for Oracle.exe to its directory. These types of restrictions can be placed on the entire director, individual files or Registry Keys. If a restriction is placed at the Global level but allowed at the lower PSET level the action will be allowed.

Now that we have addressed the issue with Oracle we still have the issue of not being able to launch Oracle application, as shown below.

Returning to the Monitor tab, we can see that the restrictions put in place by the policy are not allowing the Oracle application to launch.

74

Using the Event Wizard, we can make modifications to the base Oracle Server policy to allow these actions to occur. In this case Explorer.exe needed read access to the Database_homepage.url. We can use the Wizard to grant read

only access to this file, as shown in the following figure.

Using the Event Wizard will place the application that is trying to access the files into a readable list. In this case, we need to place several applications in a readable list to allow them access to the Oracle directory that stores the component or file that needs to be read or executed.

75

When the policy is applied, you will need to go through every aspect of the product to see what the policy might prevent from running. As a best practice, you should always start with the policy in a disabled mode and then tune the policy accordingly.

There were several components outside of Oracle that needed to be defined to allow access to the Oracle directory. We will modify the Interactive Program Options\Default Interactive Program Options and give these two applications read-only rights to the Oracle directory and file that they are trying to access. In some cases, you might want to give the component full read access. With any resource restriction, you can also limit the access to a user or group.

After reapplying the policy and launching the interface, we can confirm that we are able to log in.

76

Next, we can move on to another component of Oracle to run the SQL command line, as shown below.

In this case, however, launching the Run SQL Command Line results in an error, as shown in the following figure.

Returning to the Monitor Tab, we can see that sqlplus.exe is being denied access to the Oracle directory.

77

Because sqlplus.exe is an Interactive Program, we will need to either create a new PSET for Interactive programs to

give it rights to the Oracle directory or define it under Default Interactive Program Options. Earlier, we had created a PSET for Oracle services and granted them write access to the Oracle directory. We will now create one for the interactive side of Oracle and grant it write access to the Oracle directory.

78

Now that we have granted sqlplus.exe access to the Oracle directory, we can successfully launch the command line.

This process of tuning the policy can take some time. Using the Monitor tab and Event Wizard can help speed the process up. We have gone through some of the process of getting the policy working with the Oracle Web GUI and SQLPlus.

79

When we try and start and stop Oracle we can see that we are getting some errors.

Looking at the Monitor tab we can see that services.exe is having some problems reading Oracle.exe to start it.

Using the Event Wizard we will make a change to the policy to allow Oracle.exe to be read by this process set under which Services.exe is covered.

80

Looking at the policy, we can see that the change was made to the scm_ps process set to allow Services.exe to read Oracle.exe.

81

After some additional tuning on the policy, and allowing authorized activity to occur, Oracle is able to start but now Oradmin is having an issue.

Oradmin is one of the interactive components of Oracle, so we will add it to our PSET that we have created to give it

access to its folder

4.6.5.2. Working with Network Restrictions

Now that we a resource restrictions setup to allow Oracle to start and operate, we will need to allow authorized traffic to and from the system. Oracle has requirements for communication to occur on certain ports as follows:

82

The Strict Policy that we used to build the Oracle policy denies all inbound traffic at the global level, except for traffic that is allowed at the individual PSET level.

Using the Monitor tab we can see that inbound traffic is being blocked.

In this case the inbound traffic that is being denied is preventing the launch of the Oracle Web UI on the Oracle Server, as shown in the following figure.

Oracle HTTP Server listen port / Oracle HTTP Server port 80 Oracle Application Server

Oracle Internet Directory(non-SSL) 389 Oracle Application Server

Oracle HTTP Server SSL port 443 Oracle Application Server

Oracle Internet Directory(SSL) 636 Oracle Application Server

Oracle Net Listener / Enterprise Manager Repository port 1521

Oracle Application Server / Oracle Database

Oracle Net Listener 1526 Oracle Database

Oracle Names 1575 Oracle Database

83

We will need to write a network rule to allow traffic to the local IP address on port 8080. Network rules have a specific scope and format. If a rule is defined at the Global level to allow traffic, it is allowed for all applications and services running on the system. You can alternatively specify whether you only want that traffic to be allowed for a specific application. In this case, we have a PSET that we created for Oracle. We will need to modify the PSET to allow inbound traffic for IP addresses that we want to allow to connect to the system. We also need to define what ports we are going to allow these connections to take place on. The firewall component in CSP is stateless. When working with rules, note the following:

1. Rules at the individual PSET level supersede rules placed at the General or Global level

2. Rules run in order. If you have a rule that allows traffic and one that follows that denies traffic, the traffic will be allowed.

3. If you are testing with rules and you allow traffic and then write a rule to deny the traffic, the traffic will still be allowed until the system is restarted. Once the state is allowed, changing the rule will not affect it until the box has been restarted or state is cleared.

For our example, we will specify in the Inbound Host list which IP addresses are allowed to connect to the system. By specifying the list in the Oracle PSET, we can control connections for this specific application. If we specify it in the Global inbound host component list any PSET that references that list will allow the connections.

84

Based on the Oracle chart we know that there are certain ports that Oracle listens on for inbound communication.

85

A firewall rule can be written to reference the host and port list.

86

Similar rules will have to be setup to allow outbound connections.

87

5. Walkthrough of Common Use Cases

This section demonstrates some common POC use cases where CSP locks down critical servers in a customer environment.

5.1. File Integrity Monitoring

Tracking file changes is a large part of compliance. SCSP has multiple methods for tracking changes to both files and registry values. In addition, SCSP can proactively enforce who and what should be able to modify these values. The quickest way to enable tracking for a specific list of files is by using a Template Policy.

To create a new policy based upon a Template Policy:

1. Click on the Detection Viewtab and then click the Policies tab.

2. Choose Windows Template Policy from the list of Policies in the window and then click Next.

3. Click Edit Policy.

4. Select My Custom Rules.

5. Select New.

a. Enter File Watch Rule as the Display Name.

b. Select File Watch for the category

c. Enter file_watch_rule as the identifier (this cannot have spaces but underscores are permitted)

d. ClickFinish.

Your new custom rule will be shown under My Custom Rules.

88

6. Click Settings..

7. Expand your rule (represented by the name you provided).

8. Expand File Watch Rule Options and enable the check box.

9. Provide a value for this specific rule under Rule Name(for example, Web server). If you have multiple rules you can have multiple names.

10. Provide a Rule Severity Value (from 0 to 99)

The severity you enter will affect how the rule is logged in the console

0-19 = Info

20-39 = Notice

40-59 = Warning

60 – 79 = Major

80-99 = Critical

11. Select Monitor File Creation, File Deletion, and File Modification.

12. Under File Modification, select Use File Checksums to check if files are modified and set the Report File Differences Type to Text.

13. Enable Files to Watch and expand this option

14. Enter the directory and files you want in List of Files to Watch (example c:\temp\*.log)

15. ClickOK.

16. Enter comments if desired and select Finish.

To apply the policy:

1. Right-click on the new policy you have created and select Apply Policy.

2. Double-click on Policy and choose Windows. This setting ensures that only Windows servers receive this policy.

3. Click Next.

The policy will now be applied.

To test the policy:

1. Open c:\temp.

2. Modify a file in this directory (for example, open the file and then add or change some text).

3. Go back to the SCSP manager and look at the events created. You can do so in the following ways:

• Choose the Monitor tab.

• Click on Assets, find the server under Windows and select Recent Events.

89

5.2. Privilege De-escalation

Restricting the movement and capabilities of an administrative or root user can be difficult in most environments. With SCSP, you can take a policy-based approach to what each user or group of users can do.

To prevent a privileged user from executing an application:

1. Click the Asset Viewtab.

2. Right-click the server for which you have a policy deployed, and then click EditPolicy.

90

a. Expand Interactive Program Options.

b. Expand General Interactive Program Options.

c. Expand Alternate Privilege Lists.

d. Select Specify Interactive Programs that should not start.

91

3. Specify a program that you would never want to start on the server.

4. ClickApply.

To test the policy:

1. Open Windows Service Manager

2. Try to start the application

3. Go back to the SCSP manager and look at the events created

92

5.3. Web Server Configuration and Web Defacement Prevention

SCSP can assist with protecting critical data by allowing only certain users, groups of users or applications to access any data sets, whether the data sets are databases, mail stores, HTML or MS Office documents.

To restrict access to a specific set of data:

1. Click the Prevention Viewtab, and then click the Policies tab.

2. Open the Asset View.

3. Edit the policy on the chosen server.

4. Expand Global Policy Options.

5. Expand Resource Lists.

6. Expand Read-only Resource Lists.

7. Enable and expand Block modifications to these files.

8. Click Add, and then enter the following path in the resource field: C:\temp\*.log

9. Click OK.

10. Enter comments if desired and click Submit.

11. Apply the policy

To test the policy:

• Open one of the log files under the temp directory and see if you can modify it.

93

5.4. Protecting Apps from Users

Sometimes administrators need to restrict the users who can make changes to files in an area. For example, the system administrator may need to manage the whole machine, but there are certain files that you only want to allow certain users to access. A good example would be Web server configuration files.

To restrict access to a specific set of data:

1. In the SCSP manager make a copy of the core or strict policy

2. Expand Global Policy Options.


4. Expand Read-Only Resource Lists.

5. Enable and expand Block modifications to these files.

6. Enter the following path in the resource field C:\Inetpub\wwwroot\html\*

7. In policy tree in left pane, click My Custom Programs.

8. Click New.

9. Enter a Display Name (Administrator Launched Notepad can access restricted)

10. Choose This Program is Interactive.

11. Enter an Identifier with no spaces (e.g. notepad_restricted)

12. Choose Settings and Expand the Rule.

13. Select Specify Interactive Programs with Custom Privileges and expand.

14. Add a new Value. In the Program Path field type C:\WINDOWS\system32\notepad.exe. In the User Name field enter admin


16. Expand Writable Resource Lists.

17. Enable and expand Allow modification to these files.

18. Enter the same path from the earlier example C:\Inetpub\wwwroot\html

19. Click OK.

20. Enter comments if desired, and then select Submit.

21. Reapply the Policy

To test the Policy

1. Open Windows Explorer and attempt to create a file in C:\Inetpub\wwwroot\html

2. Open Notepad create a file and save it to this directory.

5.5. Configuring connections to and from an agent computer

The following examples illustrate how to use the Network Controls option to block inbound network connections from known IP addresses. To restrict specific IP addresses from making inbound connections to an agent computer, you block the inbound connection to any program listening on a potential target port. Make sure you modify the policy settings in

94

the Global section of the policy. Because global rules are always evaluated after group and specific rules, the denials will hold only if there are no contradicting groups or specific rules. For example, a network rule for the DNS service that is specified under the DNS process set options and allows inbound connections from all IP addresses on the DNS port will allow a bad IP address to make inbound connection on the DNS port even though it is denied in the Global options

To block inbound network connections from known IP addresses:

1. In the management console, click Prevention View.

2. In the management console, click Policies.

3. In the Workspace pane, select a prevention policy, and then right-click Edit Policy.

4. In the policy editor, click Global Policy Options > Network Controls > Inbound > Inbound network rules, and then enable the rule.

5. In the policy editor, click List of rules to control connections into this system.

6. Click Add.

7. Specify the rule parameters as follows:

a. Action: Select Deny.

b. Protocol: select Both TCP and UDP.

c. Remote IP: Specify the remote IP address.

d. Logging: Select Log to log an event when a connection attempt

e. Re-order the list of rules if necessary.

8. In the policy editor, click OK.

9. Apply or reapply the policy to the agent.

5.6. Allowing granular access to files, devices, and registry keys

The following example globally blocks all access to File X, but allows User A and User B read access using Program App1 and Program App2,and User C and Group D write access using programs that are located in remote share patch\\filesvr\trusted\.

To allow granular access to files, devices, and registry keys:



3. In the Workspace pane, select a Windows prevention policy, and then right-click Edit Policy.

4. In the policy dialog, click Settings.

5. Click Global Policy Options > Resource Lists > No-Access Resource Lists, enable the option Block all access to these files, and then add File X.

6. Click Interactive Program Options > Default Interactive Program Options > Resource Lists > Read-only Resource Lists, enable the option Block and log modifications to these files as trivial, and then add File X with program path*\app?.exe for User A.

7. Click Interactive Program Options > Default Interactive Program Options > Resource Lists > Read-only Resource Lists, enable the option Block and log modifications to these files as trivial, and then add File X with program path *\app?.exe for User B.

95

8. Click Interactive Program Options > Default Interactive Program Options > Resource Lists > Writable Resource Lists, enable the option Allow but do not log modifications to these files, and then add File X with program path \\filesvr\trusted\*.exe for User C.

9. Click Interactive Program Options > Default Interactive Program Options > Resource Lists > Writable Resource Lists, enable the option Allow but do not log modifications to these files, and then add File X with program path \\filesvr\trusted\*.exe for Group D.

10. Click OK to save your changes.

5.7. Blocking access to USB devices

To block access to USB devices:



3. In the Workspace pane, select a Windows prevention policy, and then right-click Edit


5. Click Global Policy Options > Resource Lists > No-Access Resource Lists, enable the option Block all access to these files, click List of Files that should not be accessed, and then add the following files:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\DeviceClasses\*\*USBSTOR*Disk*

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Control\DeviceClasses\*\*USBSTOR*Disk*

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceClasses\*\*USBSTOR*Disk*\

device\harddisk*\DP*\*

6. Enable the option Block all access to these registry keys, click List of Registry keys that should not be accessed, and then add the following keys:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\DeviceClasses\*\*USB*

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Control\DeviceClasses\*\*USB*

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceClasses\*\*USB*

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\DeviceClasses\*\*USBSTOR*

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Control\DeviceClasses\*\*USBSTOR*

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceClasses\*\*USBSTOR*

5.8. Giving a program access to a specific resource set

Sometimes a program that requires access to a set of resources is denied access by the out-of-the-box prevention policies. While the prevention policies provide per-process resource control for default programs, you should create custom program options if there are more than a few resources or if more than one program requires the custom rules. Policy options let you assign a selected program to this custom options group to define rules for it that do not apply to all the default programs. By doing this, you can allow programs assigned to the custom options group to access resources that are not accessible to other programs.

To give a program access to a specific resource set:



3. In the Workspace pane, select a prevention policy, and then right-click Edit Policy.

4. In the policy editor dialog, click My Custom Programs, and then click New.

96

5. Type a name and identifier for the custom program options, select a category, and then click Finish.

6. Under My Custom Programs, click Settings.

7. Enable the option Specify interactive programs with custom privileges, and then add the custom interactive programs to the list.

8. (Optional) Adjust the remaining options.

9. Click OK to save the policy changes.

5.9. Giving a program wide access to resources

If a critical program generates policy violation events for many resources, and you want to allow the program accessing all the denied resources, you may want to consider elevating the privilege level for this program. If the program already has a BCD, then you can change the privilege level for this program using the specific Alternate Privilege Options group.

For example, to give the DNS Server safe privileges, enable Service Options > Core OS Service Options > DNS Server >Advanced Options > Alternate Privilege Level > Run with safe service privileges.

Sometimes a program does not have a specific BCD. An example for this scenario might be antivirus software that is not recognized by the out-of-the-box prevention policies. Policy options allow you to add security software to an already pre-defined host security process set. This is set using Global Policy Options > Host Security Programs > Basic Options > Additional host security programs installed. Add the path to your security programs in list of other host security programs.

If the program does not have a BCD, and it is not a security program, you can give it safe or full privileges using the Alternate Privilege Level option, under the General Group options.

To give alternate privilege level to a service, enable Service Options > General Service Options > Alternate Privilege Lists.

To specify an interactive program with safe or full privilege, use Interactive Program Options > General interactive Programs > Alternate Privilege Lists. Allowing diagnostic programs to access process data A policy option in the UNIX Protection policy allows diagnostic programs to access process data via the /proc file system.

To allow diagnostic programs to access process data:


2. In the management console, click Policies, and then click the Unix Policies filter.

3. In the Workspace pane, select the Protection prevention policy, and then right-click Edit Policy.


5. Click Interactive Program Options > Root Program Options > System Admin Options.

6. Allowing diagnostic programs to access process data

7. Enable the option Allow tools, such as truss and gcore, to access process data.

8. Click OK to save the policy changes.

5.10. Preventing Zero Day Attacks

SCSP can be used to prevent zero day attacks against the system. It does this by containing the outcome of the attack and preventing access to resources on the system.

To demonstrate how SCSP protects against zero-day attacks:

97

1. Connect to http://www.metasploit.com/ and download Metasploit or Metaspolit Express. Metasploit Express is much easier to use and can run on Windows.

Optionally download Nexpose to perform vulnerability scanning against the system. Nexpose and Metasplot can work together in this example, where Metasplot will use the scan results of Nexpose to launch exploits at the system.

Note: There is a Metasploit Vmware linked on SymIQ that can be used for this exercise. Attacks are located in the home/symc/attacks folder. The attacks include and MSQL Stuxnet and the Print Spooler Service Vulnerability

2. In the SCSP management console, apply a Null policy to server.

3. On a separate machine, launch the mssql_cmdshell_stuxnetbackup file. The outcome of the attack should

leave you at a command prompt on the server

4. Apply a Strict Policy Enabled to the server and allow all inbound traffic.

http://www.metasploit.com/

98

5. Launch the Stuxnet attack again.

6. On the Asset tab, look at recent events.

99

5.11. White listing

White-listing is a way to control what applications you want to allow running on the system. This can prevent a malware or unauthorized application from getting installed. There are two ways to approach this with Critical System Protection. There is an out of the box policy called Limited Execution Policy. This policy by default denies Interactive programs from being executed but allows background services to run. Within this policy you have to modify the policy to allow which interactive programs you want to allow to run.

100

You can check Allow Specific Interactive Programs to start and go specify the ones you want to allow. This policy is good for systems that are dedicated to running only certain applications like POS or ATMs. If an application is running on the box as a background service it would not be affected.

If within the Limited Execution policy you wanted to control services that run in the background that should never start this could be done under the Service Options. You can click on Specify Services that should not start and create a list. If you are going to be using this list on multiple systems you can save time by exporting the policy and importing it into other servers. You can also create a custom list of services or applications that you would not want to start. This list can be referenced in the Specify Services that should not start.

101

The Limited Execution Policy has the same network restrictions as the Strict Policy as well changes the admin of anybody in the admin group rights down to a normal user.

Another way to approach white-listing is to use the Strict or Core Policy. With these policies they allow everything to run on the box, so you have to specify what you don’t want to run

102

The execution of a program that is in the list will prevent it from running.

Custom List can be created and reference in a policy. In this case a list can be created with a list of applications that you want to prevent from starting.

103

Once the list is created it is referenced in the policy.

104

There may be times where you want to blacklist a product but allow only certain users or group to launch it. This can be accomplished by putting the user or group in the list as an authorized person to launch it. This can be done when defining any sort of resource restrictions.

5.12. Virtualization Protection

Symantec Critical System Protection provides prevention and detection capabilities in an ESX guest and host environment and the guest environment on ESXi. Protecting the ESX host is as important as protecting any critical system on the network.

The ESX host (hypervisor) is a Red Hat OS that allows local and remote login, and represents the same security risk as normal Red Hat OS. It also contains configuration files and can also contain the guest OS files. Changes to these configuration files or access to these guest OS files by someone who is not authorized can cause havoc to an environmenti.1

The prevention piece of CSP can be used to lockdown the configuration files and guest OS files, preventing access and changes that could be disruptive or destructive to the environment. Using the firewall component of SCSP, you can control which systems can access the ESX host remotely. This can be used to control connections from systems who are trying to access the web console or to control connections from VCenter.

On ESXi, installing the agent within the hypervisor is not possible today. ESXi can be embedded in firmware as an appliance purchased from a vendor or as an installable that uses proprietary OS that does not have the same security risk as ESX did. It is still important on ESXi to protect the guest OS and to lock down the system running Vcenter.

1See http://searchvmware.techtarget.com/news/1378347/How-to-steal-a-virtual-machine-and-its-data-in-3-easy-steps for more information.

http://searchvmware.techtarget.com/news/1378347/How-to-steal-a-virtual-machine-and-its-data-in-3-easy-steps

105

Out of the box,SCSP has a prevention policy that can be deployed on the ESX host. The policy has to be imported in before it can be used.

Once the policy has been imported into SCSP it can be viewed under the Prevention View. The policy comes built out of the box and ready to deploy to an ESX server. The policy does not require any customization before deploying on an ESX server.

The policy comes with some pre-defined tables that are referenced in the policy. One of the tables is a critical file list. This contains a list of files that are specific to ESX and its operation. The prevention policy will prevent anyone from making modifications to these files unless they are given privileges.

106

Once the policy has been deployed on the ESX server activity violations can be viewed using the Monitors tab.

Other list contain inbound and outbound list that will control access to and from the ESX system.

The prevention policy puts containment around the ESX dameons and CLI tools that are running on the system. This protects these while running on the system and grants them access to resources that they need to properly run.

107

Another component is the Detection Policy.

This policy is written to monitor OS and ESX logs and configuration files. This will monitor log files looking for changes and login activity on the system. This will monitor changes to the guest or host configuration files as well as changes to allow unnecessary traffic to and from the host.

108

6. Configuration, Reporting and Monitoring

Once you get your policies configured to be deployed the next step is configuration. Configuration allows you to determine agent communication and how events are handled at the agent level.

For the most part the default settings should be fine for a POC. When you get into full deployments there are definitely changes that you would want to make here. The Technical FAQ document can go into more details regarding this.

Make sure that you have a good understanding of how bulk logging works vs real-time. During a production roll-out the customer might want to implement. The Default Prevention Parameters allow you to define which events generated by the prevention policy will be sent in real-time vs bulk log. For a POC it is better to leave everything to real-time but explain to the customer the benefit to bulk log and what it can be used for.

109

In SCSP you can configure the agent to send a small number of events up in real-time, for recording in the database and immediate display on the Console. But if they have a large amount of data that is only being recorded for future analysis or regulatory compliance, they can configure that data to be recorded to files on the agent system, and when the files fill up, the entire file can be compressed and transferred to the management server. This bulk log transfer is much more efficient than sending each record over the network individually. Plus, the bulk logs are not entered in the database at all (reducing database maintenance costs). The product contains a command line tool that can load a bulk log into the database, if you want to, for example if a regulatory audit wants to view some of the data.

The Default Detection Parameters allows you to control how which detection collectors are enabled. For the file collector you can specify polling interval of how often it will poll files for changes. The search depth will determine how many directories deep from the parent directory it will monitor files.

110

Q: Why are “Monitor Checksums” and “Monitor Access Times” in both the policy options and the Detection Parameters object? Which should I use?

A: The settings in the Detection Parameters object are obsolete and should no longer be used. They have been replaced by the corresponding policy options. Using the options in the policy gives you greater granularity in using these options. Both options do have performance impact and we do not recommend using them for all files without careful consideration. Rather, we recommend using these options on a selected subset of the files you monitor that warrant the extra monitoring.

The Default Detection Parameters allows you to also specify which detection events you want to send in real-time versus Bulk Log

111

Depending on what you are monitoring on the system from a detection point can generate a lot of traffic. BulkLogis good fordetection events that are a low to no risktothecompany.One thing to note is when doing bulklogginganyevent thatwas sentin real-time will beloaded againwhen abulklog isinserted into the database.

6.1. Alerting

Alerting lets you setup filters to trigger an alert when the conditionsare met. Beforein configuration, you can setup log rules to determine when a condition is met to send those events in real-time versus bulk log. When the event is received by the SCSP manager an alert can be sent out viaSMTP, SNMP or logged to a file.

112

6.2. Monitoring

The monitoring tab allows you to view events and use the event wizard to tune policies. When events are sent from the agent to the manager they are inserted into the database. The monitor tab allows you to view and search across these events.

113

The Event wizard can be used to adjust the rule to allow an action to take place that the policy might be blocking that should be allowed.

6.3. Searching and Real-time monitors

To search across the events that are stored in the database, use the Monitor Tab. You can specify the conditions down to a word in the specific event that you want to search for.

114

Real-Time monitors can be created based on a condition that looks for events that match the monitor definition and displays them when accessed

115

7. POC Tips

This section provides some tips to ensure that you conduct a successful POC

1. Plan ahead as much as possible.

a. Understand what the customer use cases are and make sure that you are able to do them before going on site

b. Gather as much information about the system that you will be installing the CSP agent on

c. If you are going to be deploying to an OS that you are not familiar with or comfortable with ask for assistance

d. If deploying in a production environment be familiar with what ports need to be open for communication between components

2. Always start off with the prevention policy disabled and monitor the activity to see what it would block.

a. Be very familiar with what each policy does before deploying

b. Remember by default inbound traffic is set to deny

3. Stick to the use cases and do not go off course.

a. If the customer is only interested in detection stick with those use cases. Prevention can be overwhelming

b. If there is a better way of doing the use case with prevention than talk about it

c. Read the Technical FAQ document for information on common questions.

4. When troubleshooting, consider the following process

5. After Installation

a. Update Policy Packs.

b. Make sure the agent appears under the Asset tab.

https://symiq.corp.symantec.com/departments/pm/Security/es/CSP/Library/Forms/AllItems.aspx?RootFolder=%2fdepartments%2fpm%2fSecurity%2fes%2fCSP%2fLibrary%2fFAQs&FolderCTID=&View=%7b93B0FC44-5281-4D33-959C-4B6C361E2D01%7d

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. Our software and services

protect against more risks at more points, more

completely and efficiently, enabling confidence

wherever information is used or stored. 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 website. 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 (800) 721 3934

www.symantec.com

i

http://www.symantec.com/

best practices for critical system protection proof of ... best practices for pocs... · best...

Documents