1
Symantec Security Information Manager (SSIM)
Technology Overview
July 2010
2
Table of Contents
Overview ............................................................................................................................................................. 3
Architecture ........................................................................................................................................................ 4
Scalable Architecture for Unlimited Performance and Capacity ............................................................................ 5
Incidents, Conclusions, and Events (ICE)............................................................................................................... 6
Agent-based and Agent-less Collection ................................................................................................................ 7
Symantec DeepSight Global Security Intelligence Service ..................................................................................... 8
Asset Values, CIA Values, and Asset Vulnerabilities .............................................................................................. 9
Event Normalization, Classification and EMR Properties .................................................................................... 10
Rule-based Correlation Engine, and Rule Patterns ............................................................................................. 11
High Speed Event Storage, Maintenance, and Query Capability ......................................................................... 12
High Availability and Fail-over ............................................................................................................................ 13
3
Overview
Symantec Security Information Manager (SSIM) enables IT organizations to
Identify, prioritize, investigate, and respond to security threats and compliance violations in
real-time. Combining real-time correlation of security issues with Symantec’s trusted
global intelligence network, delivers effective incident response ensuring the integrity of
your business information assets.
SSIM ensures the integrity and security of the network and critical assets by delivering the
following capabilities:
• Captures, filters, normalizes, and reports on security events from a
myriad of Symantec and leading 3rd
-party security and network products
(anti-virus, firewall, intrusion detection/prevention, vulnerability Management, policy compliance, etc.) enabling IT to identify critical
breaches in a heterogeneous or complex network environment.
• Correlates security events, in real-time, helping IT to transform logs into
intelligence and to focus resources on solving the most serious problems
first.
• Tracks security incidents and related response activities throughout
their lifecycle from ticket creation to closure, helping IT to quickly and
effectively remediate problems.
• Integrates into the enterprise infrastructure including the existing
management and ticketing systems so that IT can leverage their legacy
investments and processes.
• Reports key security incident metrics enabling businesses to visualize
and refine the effectiveness of their security processes and posture.
• Delivers best-in-class functionality within a high-performance appliance
that is easy to deploy, use, and manage.
4
Architecture
SSIM is built on architecture and platform and complying with industry standards-based
specifications. It embeds and uses Symantec’s next generation common services along with
SSIM specific correlation and incident handling services. The architecture and common
services form a directory enabled distributed system whose administration model is based
on the DMTF Common Information Model (CIM), and its CIM-LDAP mappings. Event
services provide SSIM its underlying event schema, event collection, forwarding and routing
channels, detailed event storage, event level access control, preferred language event
display, and query services. The event services uses the CIM-XML protocol, as well as a
highly efficient compressed CIM-XDR binary protocol, over HTTPS. SSIM adds a custom
event service router to feed events to its correlation engine in near real time.
SSIM stores events in compressed archives that are XDR binary encoded. These archives
can located on the SSIM system or located off-box on a SAN/DAS or NAS. Each archive has a
checksum and is digitally signed using SHA1. The archives is checked at time of access to
ensure that it has not been tampered with. Archives are created on a 2 hour interval with
separate index files for best performance when searching the data.
Multiple archive repositories can be crated allowing for events to be split off between them
based on a defined filter. Each repository can have different retention periods for how long
the data is stored in them, as well be located on different mount points.
Alerting and notification services provide multiple channels of communication
to users and service desk systems based on rules and schedules. Service desk
channels are bidirectional. SSIM can send out SNMP, SMTP, Syslog or Pager notifications.
SSIM uses a published API to talk with third party ticketing systems. Out of the box SSIM
provides support for Remedy and HP Service Desk.
Directory services provide authentication, user white pages, roles-based access
control, service access point location, and multi-domain organizational
management for a trusted federation of multiple appliances with single sign-on
capabilities.
Policy configuration services provide centralized configuration of many SSIM appliances
and collectors. Failover of manager components, and directory services enable a high
availability enterprise system. A statistics service monitors the health and liveness of
system infrastructure components, and monitors event and rule processing in real time.
5
Scalable Architecture for Unlimited Performance and Capacity
Multiple SSIM appliances can be federated, allowing for extremely high event
loading, collection, and storage capabilities into a single directory which makes them all
available from a single console with delegation of duties. For example each correlation
node can achieve 25,000 events per second (EPS) sustained, while each collection node can
achieve 12,000 EPS.
Events can either be stored directly on the correlation node, or stored at the collection
node if there is enough storage available
In a large scale deployment the location of where the events are stored can be distributed
across multiple collection nodes. From one single console multiple archive nodes can be
queries across.
By using off box collectors can help in distributing the load of events and provide more
flexibility where a collection node might be too much.
Correlation Node Correlation Node
Collection Node Collection Node
Off box collector Off box collector
Off box collector Off box collector Off box collector
6
Incidents, Conclusions, and Events (ICE)
Incidents are the primary object of interest to the analyst and can be
prioritized, assigned, and remediated using Global Security
Intelligence information, and bi-directional service desk ticketing workflow.
SSIM collects events and analyzes them in near real time using rule-based
correlation on the normalized event stream. When a rule fires, a conclusion is
created, containing abbreviated fingerprints of the events that caused the rule
to fire, and references to the detailed events in the event archive. Conclusions
are then correlated into incidents that contain one or more conclusions. This second tier of correlation, tying related conclusions into appropriate incidents,
is based on many possible strategies. Examples include conclusions from
the same rule within a time range, or conclusions that share events with the
same target addresses.
SSIM can also continue to track subsequent events that match tracking rules.
For example, once an IP address is suspicious due to it’s causing a rule to fire,
the address can be tracked and the associated event fingerprints added to the
conclusion until a threshold is reached, after which tracked events are
aggregated with an event count increment.
7
Agent-based and Agent-less Collection
SSIM uses collectors written for specific devices when collecting events.
Collectors can be agent-based using the SSIM Agent or agent-less running
remotely on any SSIM appliance. The SSIM agent is built on a manager-provider
architecture and supplies providers that facilitate using the common services for
multiple applications on the host. For event collection, the agent includes a logging
provider that queues and securely forwards using HTTPS. The SSIM agent also
supports sending event in an unencrypted manner via port 10012. Sending events
through unencrypted manner supports a higher EPS.
When we say agent-based collection, the agent does not need to be installed on the
source of where the events are being collected. The agent could be installed along
with the collector on a different system. The collector is configured to talk with the
device. The value of using an agent based collector is that the information can be
encrypted in transit. This is important when customers do not want to send data
across a VLAN or different network segments in the clear. Agents will create status
events and send to the SSIM manager reporting that they are alive, and receiving
events from the device they are monitoring.
Collectors translate data from the vendor into fields that map to our event schema.
The collector could be configured to perform event filtering and aggregation on the
data. The collectors passes the translated events to the agent which sends the
events conforming to the event service schema to the event service server.
Each SSIM appliance includes a local agent and collectors that support remote
collection. In this way, effective agent-less collection is provided for, without
the need to install remote agents or agent proxies. Additional collectors can be
installed on the appliance to support more agent-less collection.
Agent Port Agent v4.5 Agent 4.7
Maximum EPS Throughput 3850 10000
Windows Agent 443 3300 3500
Windows Agent 10012 NA 6500
Linux 443 3300 3850
Linux 10012 NA 10000
Solaris 443 2550 2579
Solaris 10012 NA 4900
The chart above is agent performance numbers based on pushing 10000 EPS using two collectors installed on a single agent. The
test was performed using the syslog generation tool. The collectors used in the testing was Netscreen and Generic Syslog.
Communication on Port 10012 is new to the 4.7 agent, when used the traffic is sent unencrypted.
8
Symantec DeepSight Global Security Intelligence Service
Perhaps one of the most powerful and unique capabilities of SSIM is its ability
to consume and serve security information via the Global Security
Intelligence Service (GIN). SSIM includes a service that acts as a client to the
DGSIS web services, and reflects that information as a local web service to
Symantec security applications; SSIM is a real time consumer of this
information.
In SSIM, some of this intelligence is user facing as interfaces
showing the global threat level (ThreatCon), articles about recent
vulnerabilities and exploits, a window into the DeepSight Analyst’s Watch, etc.
Just as important, behind the scenes the local DGSIS retrieves up to the minute
attack signatures in normalized form, and associated Bugtraq and CVE vulnerability
and exposure references, which drive the semantic normalization of security events
in real time, rather than periodic updates which can be significantly out-of-date.
The data that are pulled down by this service is used to provide remediation
guidance in an incident or workflow in a ticket. This is one of the unique values of
SSIM over the competition. Most of the competitors either provide links to websites
that a customer has to dig through or their data is out-of-date.
One of the other values of this real-time feed is the update to an IP Watchlist with
an active list of offending IP addresses that traffic is compared to.
The watchlist is composed of three separate lists generated by the Global
Intelligence Network:
• BotNet Watchlist
• Malicious IP Watchlist
• Worm IP Watchlist
In order for an IP to appear on the IP Watchlist at all, four or more sensors in the
Global Intelligence Network have to have detected malicious activity in the past 48
hours originating from the IP.
� Bots - A list of IPs that have been seen by more than 5 companies
firewalls in an identical pattern.
� Malicious IPs - A list of IPs that have been seen by at least 5
companies with IDS traffic which flags the traffic as “malicious”.
� Worm List - A list of IPs that the Global Intelligence Network has
seen attack 2, or more, IDSs with a worm propagation attempt.
9
Asset Values, CIA Values, and Asset Vulnerabilities
Not all events are attacks, and not all attacks are equally significant. For
example, certain servers, or assets, within an organization are considered vital
to business operations, or contain confidential and sensitive information that
cannot be compromised. Also, attacks often try to exploit vulnerabilities or
exposures in operating system and application software installed on those
assets. If the vulnerabilities don’t exist, or the operating system or application
service type doesn’t match the exploit, the attack is not worrisome in and of
itself.
Therefore, SSIM incorporates its own asset tables. The asset table can be populated
using vulnerability scanning tools, manual or through an import. Once the asset has
been populated values can be assigned to them. Assets that are important in
regulatory compliance audits can also be marked as such. These values assigned to
an asset can be used in rules to trigger against.
Vulnerability scans can record their results as vulnerability events, and to corresponding SSIM assets that are deemed vulnerable to exploits are updated to reflect the vulnerabilities or exposures via Bugtraq and CVE identifiers. Vulnerability scans also populate what services are running on the asset. This information is used during the correlation process determines if a machine is susceptible to an attack. For example if there is a DNS exploit attack targeting a system that does not have port 53 running, this would be a false positive. There are several out of the box rules that use asset table information.
SSIM incident urgency and prioritization is calculated based on the following factor
CIA values, regulatory compliance tagging, and vulnerability and exposure results
from recent scans. Assets that are deemed valuable or sensitive, are vulnerable to
the particular attack, or are regulated assets receive higher prioritization.
Within the asset table you can group assets together based on values. You can also
view the current open incidents on these critical assets and ticket information.
Queries can be created to report on risk associated with assets.
10
Event Normalization, Classification and EMR Properties
The event services provides detailed and extensible event schema for multi-
vendor and multi-device event normalization, both for analysis as well as for
reporting and forensics.
Structural normalization places all events into the correct event classes and
uses the same property names across vendor and device type variation. There
are even classes for data integrity violations such as viruses, spam detection,
network events, IDS events, VA events, firewall events, audit events, etc. Multi-
stage time stamping and time correction between hops allows time series
analysis against the event stream, and allows for better forensic investigation.
On top of this structural and temporal normalization, SSIM semantically
normalizes certain event values, such as attack signatures, and classifies them
with higher level categories using the real time DeepSight Global Security
Intelligence Service built into SSIM.
Although event categories have been used by other vendors in existing
products, including those from Symantec, they typically are somewhat
arbitrarily defined, and are proprietary to the vendor’s implementation.
SSIM now adopts a new proposed-standard classification scheme based on a
detailed study of security exploits, review and input from several leading
technology companies in an open standard process within the DMTF
Using EMR properties, events are classified via an orthogonal set of multi-
valued properties termed Effects, Mechanisms, and Resources, The DeepSight event
dictionary carries EMR property values for each attack identifier that SSIM
consumes.
By classifying events using these attack vectors makes it less obtrusive for the end
user to write rules. The end user does not need to be a security expert to write a
rule, or have detailed knowledge about multiple vendor products and their
signatures. By writing a single rule using these values can cover many different
vendors products. EMR is not product or vendor specific.
Most SIM/SIEM vendors would have to have many rules written to cover these
attack vectors, our rule set is kept down to a minimal.
11
Rule-based Correlation Engine, and Rule Patterns
SSIM implements an ultra high speed rule-based correlation engine and
delivers a set of system rules that can be used out of the box, or customized for
a particular environment. System rules are updateable via Symantec’s
LiveUpdate services. Based on its distributed architecture, cross-product,
multi-appliance correlation can be performed on a very large scale.
At the time of this writing, a single rule engine correlation node operates at
25,000 events per second (EPS) including storage of incidents, conclusions, and
event fingerprints.
A powerful but easy to use rule editor allows the end user to create custom rules
based on a set of rule patterns that carry out complex rule relationships, allowing
the user to concentrate on simpler Boolean operations and parameterization
characteristics of a custom rule. Without rule patterns, the end user would either
be forced to use system rules, or would need to spend time creating very complex rule
logic prone to error, and difficult to understandand maintain.
Example rule patterns are: activity from one source address to many distinct
targets, many sources to a single target, symmetric activity from one source to
one target, and then reciprocating back to the source, one event following
another, transient and propagation activity, etc.
Another SSIM feature that greatly eases the creation of custom rules is the use
of EMR properties for security event classifications. Often, rule
predicates using higher level categories avoid placing the details of event field
values such as IDS signatures, or event dictionary identifiers in the rule
predicate. A user simply selects a rule pattern, and creates a simple Boolean
expression using EMR properties, and possibly environment centric parameters
such as target address, subnetwork, port number, etc.
There are lookup tables that come pre populated with data as well as new lookup
tables can be created. A lookup table contains information that triggers on. An
example to this is a user watchlist table that can be populated with users and the
date they left the company. There is a pre built rule called the departed user rule
that looks at this table to determine if use activity is being detected from one of
these users.
Lookup tables can be used in queries to pull the content out of the archives based
on the values entered in the table.
12
High Speed Event Storage, Maintenance, and Query Capability
SSIM leverages the event service data archives for its detailed event storage. Due
to its distributed architecture, correlated events may actually reside in one of
many archives federated by the system. Event discriminators and event
forwarding allows for specific types of event data to be stored in different data
archives.
For example, events from one organizational unit or domain may be stored
regionally. Another example separates events physically based on event producer, for example AV products may be managed by separate personnel, and
seldom queried or reported on with firewall activity.
Regardless of how a system may be distributed, SSIM cross-correlates all event
types and event producers from any region independent of event detail storage.
SSIM also incorporates its own purpose built data store for its event
fingerprints, conclusions, incidents, workflow, assets, vulnerabilities, etc. This
database is highly optimized, built on an enterprise class database
server embedded into the appliance. Given that each appliance has a fixed
amount of storage capacity, SSIM can store data at very high speeds while at
the same time removing the oldest data to keep a system running indefinitely at
sustained performance levels. Backup and restore capabilities are also
included.
Storage performance of event fingerprints, conclusions, and incidents is 25,000
EPS sustained. Storage for event details is greater than 10000 EPS sustained.
Query performance has been highly tuned, making use of state of the art
indexing techniques and novel approaches to summary reporting that
minimizes disk I/O.
SSIM provides over 400 of the box queries that covers a wide range of product
specific to compliance related. These queries can be grouped together and placed in
reports.
Pre-built template are created for quick access to data based on the definition of
the template. New templates can be created called parameter queries that prompt
at the time of execution. This cuts down the time of having to edit the query
parameters when you want to make changes to it. Other vendors require
knowledge of scripting or SQL to write event based queries.
13
High Availability and Fail-over
SSIM provides fail-over at different levels. There are several different ways that SSIM can
be deployed and configured. SSIM has several components
1. Offbox Agent
2. Correlation device
3. Collection device
4. Archiving device
5. All in One
6. Combination of some of the above
Agent Level
SSIM supports fail-over at the agent level . An agent can be configured with a primary and
secondary manager. One the primary is not reachable, it will fail-over to the secondary.
Once the primary comes back on-line it will fail back. This is a configurable setting
Correlation Device
SSIM does not support synchronization of the Incident database. You can have a
collection device sending the events to multiple correlation systems or configured to fail
from one to another. You would have the identical incidents on both correlation systems.
You would need to close them on both devices. If the events are stored on the
correlation device, you would have identical events on both systems. If you were
configuring a collection/archiving or archiving box to forward to the correlation system
the events would be present only on that single box
Collection Device
An agent can fail-over between multiple collection devices. A collection device can
forward events to two other devices in a active active or active passive mode. In a active
active mode, you would have the same set of events being forward to another SSIM box
for archiving or correlation and archiving. In a active passive mode, if the active would to
go down, it would fail-over to the secondary SSIM device. The fail back is a manual
process.
14
Archiving Device
In this mode the box is only set to archive events that are being forwarded to it from a
collection device or offbox agent. The archiving box will than forward the events to a
correlation system. . The archiving device can forward events to two other devices in a
active active or active passive mode. In a active active mode, you would have the same
set of events being forward to another SSIM box for archiving or correlation and
archiving. In a active passive mode, if the active would to go down, it would fail-over to
the secondary SSIM device. The fail back is a manual process. When Incidents are created
the incident has a GUID that it uses to tie back to the event stored in the archive.
All in One
In this mode the box is setup to do correlation, archiving and collection. For redundancy
there might be two boxes that are setup in case one goes down. Offbox agents should be
configured to fail-over to both of the boxes. You will not get the same events on both
system, as the agent is only sending to one at a time. You could configure the other one
as a cold standby with the same name, IP, etc. You could restore the backup from the first
one to the second to have a functional system with the same data. In the case where you
had two systems and once goes down and the other one takes over, there is no way to
synchronize the incidents from one to another. You can move the archives over, and the
system would recognize the events.
LDAP
SSIM stores configuration information in the LDAP. You can have a primary and secondary
directory configured and synchronized. In the case the primary goes down, it will fail to
the secondary where you will have an exact copy of the configuration information.