Difference: ContentMigration (r4 vs. r3)

How to Migrate Your Existing Content to Activate

If you already have ArcSight ESM content, you have choices as to how much effort you need to expend to get things working with Activate.

Migration Options

  1. Uninstall all the legacy content and only install Activate content.
  2. Install the Activate content, then evaluate the legacy content
    1. Retire a given legacy use case (no longer valid or better implementation in Activate)
    2. Rewrite a given legacy use case (still valid, but not well implemented, not yet implemented in Activate)
    3. Migrate a given legacy use case (still valid, maybe reasonably implemented, but a rewrite would take too much effort, if it?s not yet implemented in Activate). To do this for each rule:
      1. Update the event annotation stage
      2. Update the DEC field (DEC is " Device Event Category").
      3. Update the CCF field (CCF is " Category Custom Format", where we set the value for the ! ArcSight Attack Life Cycle).
      4. validate the Category Significance and Category Outcome fields [you very rarely ever want /Compromise and /Success!], for proper use in the System & Entity State Tracking method.
  3. All new use cases are implemented using the Activate Framework?

Software Development Life Cycle (SDLC)

Migration option 2 is effectively playing catch-up with your content's development life cycle, but all content, whether Activate or not, should be under some form of SDLC. Here are some basic ideas for you to consider.

Content Repositories

Content is packaged using the ArcSight package resource. This is the minimal repository artifact, but not necessarily the best. Ideally, you would extract the XML file from the package and store that in the repository. Of course, you will need a way to rebuild the package. We have a make file that will perform this action (see attachments, to be posted as soon as we can). If you are sharing (or selling) your content on the ArcSight Marketplace, you might be interested in the Activate Script Generator tool to build your installation and update scripts.

Content Review

We recommend that you review all your use cases, regardless of origin, at least once a year. You probably have many use cases, so we recommend that you divide up your use cases into monthly digestible chunks, so that by the end of the year, you will have reviewed all your use cases.

Evaluating Legacy Content

The attached spreadsheet, Use_Case_Analysis_of_pre-Activate_Rules.xlsx, can be used to track the necessary changes to your legacy rules. It looks something like this:

Note that column G is a formula... Whatever you type into columns B-F will be reformatted into column G.

The idea is to look at each rule and decide where it fits in the DMiD, the DFM, the I&W Category, and which Use Case and User Story applies to it, and that builds our DEC field. Then we figure out which phase in the ArcSight Attack Life Cycle the rule covers, and that goes in the CCF. Finally, we look at the Category Significance and Category Outcome fields and decide how these should be set (they may already be set...you may opt to change them).

After all that is decided, the last thing to decide is how the alerts should be handled in the workflow process. See the Real Time Workflow Method for details, but the gist of it is that if you want an analyst to look at it, set the Event Annotation Stage to Triage. If the rule is for building baselines, etc., set the Event Annotation Stage to System Monitored. Of course, while rules are in the development and testing phase, you should set the Event Annotation Stage to Testing instead of Triage.

-- PrenticeHayes - 05 Feb 2018

Use_Case_Analysis_of_pre-Activate_Rules.xlsxxlsxUse_Case_Analysis_of_pre-Activate_Rules.xlsxmanage 11.8K 05 Feb 2018 - 12:10PrenticeHayes Useful spreadsheet for reviewing rules and figuring out what changes might need to be made to make legacy rules Activate-friendly.

View topic | View difference side by side | History: r4 < r3 < r2 < r1 | More topic actions
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