This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

L1-Malware Monitoring Indicators and Warnings

This is the official forum for discussing the ArcSight Activate L1-Malware Monitoring - Indicators and Warnings package, as described in the Activate Wiki

  • I'm installing "L1-Malware Monitoring - Indicators and Warnings v1100" on Activate Base 1.1.0.0. When I install this package, I see that a number of the Rules are in an invalid state. How can I fix this? Thanks.

    Untitled.png

    Untitled1.png

  • Hi Steve,

    Docs don’t seem real clear here, but please move up to at least Activate Base 2.5.0.0.

    Steve

  • Hi, I have installed the package active base 2.5.2, and when install the package of malware all the filters have the condition false

    false.png

    What is the error??

  • You need to hook in Product Packages in to the Solution packages. Instructions for doing this are on the Wiki.

  • We have been looking into some issues with the correlated events in the L1-Malware package and have noticed some odd inconsistencies in the aggregation. Can anyone provide any insight into these choices or are some of these things that need to be corrected? Here are just a couple of examples:

    • Multiple Unsuccessful Scans have been Detected in Host aggregates only on destinationAddress and not destinationHostName as all of the other rules in the package
    • Multiple Unsuccessful Scans have been Detected in Host  is also the only one that does not include deviceVersion, deviceAction, and deviceEventClassId
    • Use of deviceSeverity, destinationUserName, deviceHostName is limited to half the rules (different combinations)
    • Unresolved Malware includes a number of the source fields whereas Resolved does not.  

    I've included a spreadsheet with the information that I pulled for analysis. As an aside, I think this information would be extremely valuable in the Wiki documentation as an indicator of what fields should be tested when implementing the rules. 

    Jeff

     

    L1 Malware Aggregation.xlsx.zip
  • I noticed that the correlation events produced by the malware package have parameters in the name field with information like the virus name and the address of the infected host. Normally I recommend leaving parameters out of the name field because they make reporting on different event types difficult. This is in keeping with the advice from the CEF guide which says:

    Name is a string representing a human-readable and understandable description of the event. The event name should not contain information that is specifically mentioned in other fields. For example: “Port scan from 10.0.0.1 targeting 20.1.1.1” is not a good event name. It should be: “Port scan”. The other information is redundant and can be picked up from the other fields.

    The message field is the better place for plain-text descriptions of what happened. Did the best practice change on this?

  • Looking through the rules in the L1 malware package, I see they track based on the destination address and not the hostname. Why is that? The address can be changed and reused through DHCP, leading to both false positves and negatives. It seems like the hostname would be more predictable.