Activate Framework Best Practices

Introduction

The Activate Framework is an end-to-end security monitoring framework. Everything starts with the log-generating devices. If your devices are not logging the information needed to address your security use cases, you will never be able to address them; you will effectively be blind to those events. Next on the list is collecting the logs that are generated and sending them to your correlation, in our case, ArcSight ESM. After that is where the Activate Content comes into play. But all of this is moot if you don't have a workflow for dealing with what the system is telling you is bad. A basic workflow is the next step that covers the basic operations. Finally, refining your installation's resources and workflow will keep your security team on top of your network's exposure and risks. There are many dynamics involved here, from an ever changing and evolving community of bad guys trying to get into your network, to the fact that enterprise networks are not static. We will go a bit deeper into the various topics that the Activate Framework covers to give you some guidance on how to make the most of your ArcSight environment, the Activate Framework, your security devices, and your security team.

Activate Framework Deployment

The most basic mistake we see with Activate deployments is the rush to get everything installed. If you download all the Activate content and install it on your ESM, without planning and testing, you are going to be very disappointed in your results. As stated before, if your devices are not configured properly, you're not going to collect the information you need to properly monitor your network. If you don't have your content properly configured, specifically, if you haven't configured your product packages, your rules will not work.

The Installation and Configuration page lays out some high-level step-by-step instructions for planning an Activate Framework deployment. Some careful planning will save you a lot of frustration and make your security team successful much more quickly.

Device Settings

Connector Settings

The following standard connector settings have been tabled for discussion:
  • Port/Service Mapping
  • Uppercase Username
  • Lowercase host/domain
  • Username splitting
  • Filename/path splitting

Content Deployment

We would love to tell you that simply installing the Activate packages will solve all your security monitoring problems, but nothing is ever that simple. The best practices around content deployments focus on deploying a single package at a time, and observing the changes in the system, as well as the correlation events produced by the package's rules. We recommend that you deploy content on a test environment and observe it with your environment's events to fully understand what is going on with the system and the content before deploying it into your production environment.

Deploying an L1 (Indicators and Warnings) solution package will usually not generate any significant output, until a supporting product package is installed and configured. If you have multiple products that support an L1 solution package, we highly recommend that you install and configure them one at a time and observe both the impact to your system and the correlation events that are generated. Make sure that the correlation events make sense. Issues with rules firing too often, or not firing at all, could be caused by misconfiguration of the connector or the device. There may also be some content tuning required.

Deploying an L2 (Situational Awareness) solution package may generate significant output, especially if your asset model is not very mature. Most of the tuning of the content at this level involves refinement of the network model or the asset model, sometimes both.

Modeling

Modeling your environment is critical for automating situational awareness. If you don't know what your defending, you cannot effectively defend it. For any L2 (Situational Awareness) solution package, you will need various levels of modeling. Some solution packages may require minimal modeling, usually a decent network model, but others will require a more robust asset model.

Network Model

The network model is the basic model for ArcSight ESM. It defines what is internal to your network, and therefore, what you should be monitoring and defending. Obviously, the RFC 1918 Address Allocation for Private Internets address space is internal to your network, but you also need to create zones for the IP addresses that are assigned to your network. This is a good place to start, but further refinement of your network model will pay benefits in the future. Whether your defining a zone for your DMZ, zones for your PCI DSS compliance requirements, or zones for your various business units, a good network model can help you prioritize events and guide how you react to unforeseen events.

Asset Model

The asset model identifies many things about the systems in your network. Having vulnerability scanners on your network provides some very good asset information, especially with regular and frequent scans. However, even without vulnerability scanners, basic asset categorization identifying DNS servers, e-mail servers, NTP servers, etc., is even more valuable. The L2-Perimeter Monitoring and L2-Network Monitoring packages rely heavily on this type of asset categorization.

Content Development

HowActivateBestPractices


Content Testing

Workflow

Process Refinement

-- PrenticeHayes - 14 Apr 2017
Topic revision: r4 - 16 Aug 2018, YunPeng


 


Activate Wiki 2.1.0.0

This site is powered by FoswikiCopyright &© by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback