Security and Sandbox

It’s time to go beyond using sandboxing as a standalone capability in order to get the most out of it. You need a more robust malware analysis tool that fits seamlessly into your infrastructure and can continuously detect even the most advanced threats that are environmentally aware and can evade detection.

There are three typical ways that organizations purchase and deploy sandbox technology.

1. A stand-alone solution designed to feed itself samples for analysis without dependency on other security products. This has the most flexibility in deployment but adds significant hardware costs and complexity to management and analysis, especially for distributed enterprises.
2. A distributed feeding sensor approach, such as firewalls, IPS, or UTMs with built-in sandboxing capabilities. These solutions are usually cost effective and easy to deploy but are less effective in detecting a broad range of suspicious files including web files. They can also introduce bandwidth limitations that can hamper network performance and privacy concerns when a cloud-based solution is the only option.
3. Built into secure content gateways, such as web or email gateways. This approach is also cost effective but focuses on web and email channels only and also introduces performance limitations and privacy concerns.

Arcsight Threat Tracking Method

This Activate Method is used to track attackers and target system state and their progression through the attack life cycle. It consists of a set of rules that update the attacker and target threat scores as well as their progression and indicator and warning frequency within the attack life cycle. All this information is tracked in a set of lists with varying TTL for the entries.

For this to work efficiently, indicators and warnings have predetermined categorization requirements. For example, an IDS reporting shellcode over the wire is tagged with Category Custom Format Field = "/Attack Life Cycle/Delivery". The rules look for these conditions populate attacker and target information in the appropriate lists as well as the threat score tracking information.

Attack Life Cycle

The Attack Life Cycle lists are very straight forward. There is one list for each phase of the attack life cycle and the rules for getting attackers and targets into the lists follow two simple laws:

• Attackers and Targets can live in multiple list at the same time
• Only Activate rules will populate the lists

NOTE:

• Custom Category Format Field will be used to move data into the appropriate list
• All content is stored under:
  /All /ArcSight Activate/Use Cases/Threat Tracking/Attacke Life Cycle/ System Perspective/

Lists	Description
Phase 1 Reconnaissance	Will track attackers and targets that are conducting research and identification of targets. If the attacker's target can be derived from the event/analysis, then the target will also be tracked. Typically, these indicators and warnings and found by monitoring NIDS, HIPS, firewall ACLs, and web analytics.
Phase 2 Weaponization	Weaponization is not normally 'viewable' as the attacker normally creates weaponized packaged on systems that we are not in control of. This category will be used for file analysis tools that detect known IOC. (Mandiant, STIX, Tripwire)
Phase 3 Delivery	Indicators and warnings that intercept the transmission of executable code to a target. NIDS/HIPS/Proxies/in-line AV events are sources capable of detecting these events.
Phase 4 Exploitation	Execution of the attackers code. This list will track when code is executed either by the user or by exploiting a particular vulnerability. Indicators are warnings are detected at the OS/HIDS level. (SRP/ASLR/DEP)
Phase 5 Installation	Installation of remote access code. This can be detected at the OS/HIDS/AV
Phase 6 C2	Track attackers and hosts that are displaying beaconing characteristics. These are often detected by NIDS/FW acl/Honeypots/DNS, and detection can be enriched with external intel data
Phase 7 Objectives	Post "pawnage" activities (data exfil, corruption, destruction, pivots).

Arcsight Alert Suppression System

Suppression System

Analysts frequently need a method to suppress rules from firing until misconfigurations are resolved or point solutions are tuned. To support this activity a set of active lists will be maintained so the analysts can suppress correlation rules and data monitor alerts.

There are two sets of active lists. The first set is writable by all analysts and will have a TTL of 24 hours. These lists will be stored in "/All Active Lists/ArcSight Activate/Core/Suppression Lists". The second set of lists is only writable by L2 analysts and the TTL will be '0'. These lists will be stored in "/All Active Lists/ArcSight Activate/Core/Suppression Lists/Static".

NOTE: lists should have no more than 100 or so entries.

All logic used to compare new events to the suppression lists are stored in a filter under "/All Filters/ArcSight Activate/Core/Suppression List Filters". Should the need arise, simply create more lists and/or filters and document the hooks below.

To create more suppression lists, simply

1. Add an L1 list with 24hr TTL, "/All Active Lists/ArcSight Solutions/Administration/Suppression Lists"
2. Copy the list to the static directory and change the TTL to 0, "/All Active Lists/ArcSight Solutions/Administration/Suppression Lists/Static"
3. Change the appropriate filter, "All Filters/ArcSight Solutions/Administration/Suppression List Filters"
4. Update the documentation below

Hooking into the methodology

• Include the appropriate filter from "/All Filters/ArcSight Activate/Core/Suppression List Filters"
  • For network based events where all network based lists should take affect use: "All Network Based Suppression Lists"