 |
|
|
Symantec Enterprise Security Manager 5.1 Symantec Enterprise Security Manager (ESM) provides a combination of Vulnerability Assessment (VA) and security policy enforcement. Its main task is to scan machines throughout the corporate network – Windows NT, several variants of Unix, NetWare and Open VMS platforms are supported - report on vulnerabilities, and aid in bringing systems into conformance with a standard corporate security policy. In common with other Symantec products, ESM employs a three-tiered architecture for maximum flexibility and scalability. The ESM Agent is the workhorse of the ESM system, gathering and interpreting data that pertains to a system’s security. It does this periodically under the control of an ESM Manager. Security modules in the Policy analyse the configuration of the workstation, server, machine node where the Agent resides or the system where the Agent acts as a proxy and return the data to the Manager which initiated the request. The Manager then stores the data in its local database ready to be accessed by the Enterprise Console. In addition to information gathering, the Agent is also capable of storing and maintaining snapshot files of system-specific and user account information. An ESM Agent on a NetWare server can optionally run security checks on the entire NDS tree or just a portion of the tree. Each Agent is made up of a number of ESM Modules, the actual executable programs that do the checking at the workstation or server level. Modules can be customised by enabling or disabling individual Security Checks, changing the name lists associated with the checks, and by editing related Template files. Security Modules assess a particular aspect of system security, such as user accounts and authorisation, network and server settings, or file systems and directories. Query Modules, on the other hand, gather general information that does not necessarily relate to security policies, information that could help in general systems administration. A Query Module could thus list all users in a particular group, or users with administrator privileges. A number of Security Modules make up a Security Policy, each module addressing a different aspect of system or network security. These Policies can then be mapped to ESM Domains, which are groups of Agents. Initially, ESM creates a number of Domains based on host operating system, but additional ones can be created to facilitate queries and policy application to specific groups of computers – perhaps by location (UK, USA, etc.), department (finance, admin, etc.) or function (Web server, mail server, etc.). Each ESM Manager controls a number of Agents. It controls and stores policy data, and passes the data to an ESM Agent or the ESM Console as required. It also gathers and stores security data from one or more Agents and passes this to the ESM Console on request. The ESM Manager comprises several components, including the CIF Server (which controls access to Control Information Files containing data about Manager access, Domains, Agents, Policies, policy runs and templates), the Job Starter (which executes policy runs), the Net Server (which provides CIF Server, local file and Agent server access to remote systems), and the Command Line Interface (CLI – which provides an alternative method of executing ESM command other than via the Console). The Enterprise Console is the primary means for the administrator to interact with ESM. The Console receives input for the administrator and sends requests to the other ESM components. As data returns, the ESM Console formats the information for display, creating spreadsheet reports, pie charts and bar charts. In any distributed system of this kind, installation needs care and thoughtful planning, but providing the excellent Installation Guide is followed, things are very straightforward. The basic idea is to install ESM Manager and Agent software on each machine that will be designated as an ESM Manager (these components can be installed on NT, OpenVMS, or Unix hosts, and the Agent only can be installed on NetWare hosts). The next job is to install the Console (which works on Windows 9x and NT/2000 systems only) which can then use any of the installed Managers to do remote Agent installations on the remaining NT systems (only) on the network. Other Agents can be installed from the CD, and the installation program will automatically attempt to register a new Agent with an existing Manager. The documentation is excellent, and in addition to the Installation Guide, there is also an extensive User Manual, and both are provided as hard copy as well as electronic formats. Most of the interaction with ESM will be via the Enterprise console, which provides a three-pane interface that will be fairly familiar to users of other products in the Symantec security suite. The ESM Console has a separate console account and user environment for each user allowing different levels of administrative access. Each Manager also has its own set of user account information, so the “super user” of each Manager can restrict other users to certain Agents, Policies, Domains, Templates, and so on. No security information can be accessed until the Console is connected to one or more Managers. By specifying connections to all Managers, it is possible to make the Console function enterprise-wide, whilst by limiting the number of ESM Manager connections on a per-user basis it is possible to create different environments for specific areas of responsibility. Where many Managers are accessed from a single Console, it is possible to cache the user names and passwords of each Manager, and these are encrypted and stored under the Console user name and password combination.
The left-hand pane contains the familiar hierarchical “Enterprise Tree” display. Summary chart information is shown in the right-hand pane, whilst more detailed data is displayed in a spreadsheet grid format in the lower pane. In the Enterprise Tree, there are four main branches – Summary, Policies, Policy Runs and Templates. The Summary Branch contains details of all the Managers and Agents accessible from the Console under the current user name. Any number of Regions can be created in order to group Managers together logically if required. Under each Manager is a list of Domains, and this is populated automatically by ESM when Agents are installed, based on the host operating system. So to start with, you will have one Domain for each OS you have on your network (providing it has an Agent installed) and one called “All Agents”. It is possible to create as many additional Domains as required in order to logically group Agents in any way you like – perhaps by region, or function, for instance – and Agents can be dragged and dropped between Domains (it is possible for an Agent to exist in more than one Domain at a time, if required). As we saw in the Architecture section, an ESM Policy is made up of a number of Security Modules, each of which contain individual checks that are specific to the operating system against which the Policy will be applied.
Creating new Policies is as simple as right-clicking under the Policies branch and then selecting the Security Modules to make up the Policy. These can be chosen from an extensive list (not all of which are available under every operating system) including:
Each and every System Module contains a number of Security Checks (specific to each OS) that can be enabled or disabled by selecting the appropriate check box. For example, the Password Strength module contains such checks as:
As you can see, the combination of Security Modules and Security Checks provides the means to create some incredibly comprehensive and complex Security Policies, as well as Policies that allow incredibly fine-grained control over your corporate security stance. Luckily, Symantec has provided a number of default Policies out of the box that provide an excellent start in ensuring your corporate network is not wide open to attack :
These policies correspond to the increasing levels of security that you can apply to your systems. Policies are applied to Agents by simply dragging and dropping the entire Policy (or an individual Security Module) onto the appropriate point on the Summary branch, thus creating a Policy Run. There is also a Policy Run Wizard to take you step by step through creating a new Policy Run from scratch, and Policy Runs can be scheduled to run regularly and automatically. The scope of the run is determined by the point on the Summary branch at which the Policy is applied. For instance, dragging a policy to an individual Agent runs the Policy against that machine alone, whilst applying the Policy to the branch named NT Agents or All Agents creates Policy Runs across multiple machines. Which modules are applied is obviously determined by the host operating system of the Agent matching the OS-specific modules within each Policy. All of this is completely automatic – all the administrator needs to do is to decide that he wants to run a minimum password length check against every machine on his network, and drag the appropriate Module or Policy to the appropriate point on the Summary branch. The Console transmits the appropriate instructions to the various Managers, which in turn instruct the Agents under their control to run the specified security checks. Once a Policy Run has completed, the
Agents return the data to the Managers, and this is immediately accessible
via the Console in a uniquely numbered folder underneath the Policy Runs
branch. This basically represents a “snapshot” of the current security
profile of the target machine. Double-clicking on the appropriate entry
will bring up a window showing the current state of the Policy Run, and
the Agents to which it was applied. Clicking on any of the Agents allows
the administrator to view exactly which Security Modules were run by each
Agent. Details of each Policy Run are also stored automatically in the Summary branch beneath each applicable Agent, and each applicable Region. It thus does not matter how the administrator chooses to browse the Enterprise Tree within the ESM Console, the relevant information is always quickly to hand. We found the ESM user interface to be the most intuitive of all the Symantec products, despite the underlying complexity. Against each Policy run the Console shows the Security Modules that were carried out and the results are presented in a “drill down” interface that allows the administrator to navigate quickly through different levels of charts and text displays. The end result is spreadsheet-style grid report containing a list of the individual Security Checks with a red, yellow or green “flag” against each one to highlight the status of the test, together with more detailed information on what was found.
The severity and number of the flags is taken into account when applying an overall rating to the Policy Run, and an appropriate coloured flag is raised against the Policy branch above it. ESM repeats this process, rolling level and rating information up from Policy to Agent, from Agent to Domain, and onwards all the way up the Enterprise Tree. This provides an immediate visual indication of where the security problems lie when viewing the ESM Console at any level. ESM does more than just report on security problems, however, it can also help you bring your system into conformance with your chosen security policy. This is done via a context menu accessible from the grid report. One option is “Correct”, which allows the administrator to correct ownerships, permissions and user privileges of certain files (or Registry settings) on an Agent system. When such changes are made, any previously-taken Snapshots can be updated with the change, and there is also an “undo” option available. Should the administrator decide that the reported variance in policy is acceptable, it can be marked as “suppressed” so that it will not appear on future reports. Finally, if ESM finds a system that is capable of hosting an ESM Agent, but which currently isn’t, it will provide the option to perform a remote install. When an ESM Module runs on an Agent, it looks for exceptions to the security policy determined by the administrator. Exceptions can either be as a result of non-compliance to the policy or differences between the baseline Snapshots of the system (as established by the administrator and stored in the ESM database), and the current system state when the policy is run. Some ESM Modules use Templates to determine non-compliance to policy. A Template is simply a list containing definitions of objects (files, OS patches, Service Packs, etc.) and their expected state. This provides ESM with the totally flexible means to compare current state of any part of the network against expected state and thus report on any deviations from policy. Snapshots are simply “special” Templates that are produced automatically by ESM as a result of scanning the system, and which contain a “picture” of the system state at any given point in time, against which future runs can be compared. There are a limited number of reports included within ESM, producing a standard HTML report of information included in the Console grid and chart views. Unfortunately, there is no means to print any of these reports (unless you count printing from the browser, which is far from satisfactory for Internet Explorer users prior to release 5.5), and if you need to produce customised reports, it is necessary to import ESM’s Summary Database into third-party reporting applications such as Crystal Reports or Microsoft Access. The following standard report types are available:
Each report contains the following sections:
The body of the report is certainly detailed, and the built in reports will suffice for most organisations. It would be nice to have the ability to print a report from within ESM, however. Enterprise Security Manager goes far beyond most VA and auditing tools to provide a complete environment for defining, auditing and ensuring conformance to a corporate security policy. Whilst is does not cover exactly the same ground as “hacker in a box” active VA tools such as NetRecon, that would be too much of a duplication in functionality, given that Symantec already has such a product in its arsenal. Instead, ESM opts for integration with NetRecon, incorporating all vulnerabilities found by NetRecon into its own security analysis. Our only criticism of the product would be the lack of a printed report option within ESM itself, but apart from that there is not much with which we can find fault. The user interface is very clear and intuitive, and the idea of rolling security ratings from the individual Policy Runs all the way up the Enterprise Tree to give an instant visual indication of conformance is excellent. Policy definition is simple to do, and applying Policies and running security checks is just as easy, whether for a single check on a single machine, or a whole range of checks across the entire network. Policies can be incredibly complex and provide extremely fine-grained control of security, but the excellent documentation provides a complete reference of every single Security Module and Check. Cross platform support is also extensive, and it is hard to see how any organisation can do without a tool like this. Company name:
Symantec Technologies, Inc. Tel:
+1 (301) 258-5043
Click here
to return to the Symantec ESM Results |
Security Testing |
Send mail to webmaster
with questions or
|