Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > Author: Guy Williams

RSA NetWitness Platform

5 Posts authored by: Guy Williams Employee

Cisco Umbrella uses the internet’s infrastructure to block malicious destinations before a connection is ever established.  By delivering security from the cloud, not only do you save money, but also provide more effective security.  Cisco Umbrella observes your internet traffic, blocks any malicious destinations and logs the activities. Our Cisco Umbrella plugin is meant to collect these logs into the NetWitness Platform which helps the security analysts to analyze the different kinds of attacks, security breaches etc.

 

For more information please refer to:

https://umbrella.cisco.com/

 

Logs from Cisco Umbrella cloud can be exported to an AWS S3 bucket which can be managed by Cisco or the customer.  Cisco Umbrella plugin uses Amazon's API to fetch the logs from AWS s3 bucket.

 

 

 

 

Configuration Guide:  Cisco Umbrella Event Source Configuration Guide 

Collector Package on RSA Live: "Cisco Umbrella Log Collector Configuration"

Parser on RSA Live: CEF

Customers that use Azure cloud infrastructure require the ability to enable their Security Operations Center (SOC) to monitor infrastructure changes, service health events, resource health, autoscale events, security alerts, diagnostic logs, Azure Active Directory Sign-In and Audit logs, etc. The RSA Netwitness Platform is an evolved SIEM that natively supports many 3rd party sources like Azure Active Directory Logs, Azure NSG Flow Logs, and now Azure Monitor Activity and Diagnostic Logs for depth of visibility and insights to enable SOC analysts and threat hunters.

 

Azure Monitor Activity and Diagnostic Logs background:

 

The Azure Activity Log is a subscription log that provides insight into subscription-level events that have occurred in Azure. This includes a range of data, from Azure Resource Manager operational data to updates on Service Health events. Using the Activity Log, you can determine the ‘what, who, and when’ for any write operations (PUT, POST, DELETE) taken on the resources in your subscription. You can also understand the status of the operation and other relevant properties. The Activity Log does not include read (GET) operations or operations for resources that use the Classic/"RDFE" model.

 

Azure Monitor diagnostic logs are logs emitted by an Azure service that provide rich, frequent data about the operation of that service. Azure Monitor makes available two types of diagnostic logs:

  • Tenant logs - These logs come from tenant-level services that exist outside of an Azure subscription, such as Azure Active Directory logs.
  • Resource logs - These logs come from Azure services that deploy resources within an Azure subscription, such as Network Security Groups or Storage Accounts.

 

Azure Monitor Activity Logs: https://docs.microsoft.com/en-us/azure/monitoring-and-diagnostics/monitoring-overview-activity-logs?toc=/azure/azure-monitor/toc.jsonhttps://docs.microsoft.com/en-us/azure/monitoring-and-diagnostics/monitoring-overview-activity-logs?toc=/azure/azure-monitor/toc.json

 

Azure Monitor Diagnostic Logs: https://docs.microsoft.com/en-us/azure/monitoring-and-diagnostics/monitoring-overview-of-diagnostic-logs?toc=/azure/azure-monitor/toc.jsonhttps://docs.microsoft.com/en-us/azure/monitoring-and-diagnostics/monitoring-overview-of-diagnostic-logs?toc=/azure/azure-monitor/toc.json

 

Azure Monitor Active Directory Logs: https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/concept-activity-logs-azure-monitorhttps://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/concept-activity-logs-azure-monitor%20

 

Azure Monitor Activity, Diagnostic and Azure Active Directory Logs can be exported to an Event Hub. The RSA NetWitness Platform’s Azure Monitor plugin collects the logs from this Event Hub.

 

 

 

                                                                                                   *In Log Collection, Remote Collectors send

                                                                                                    Events to the Local Collector and the Local

                                                                                                    Collector sends events to the Log Decoder

 

Configuration Guide: Azure Monitor Event Source Configuration Guide

Collector Package on RSA Live: "MS Azure Monitor Log Collector Configuration"

Parser on RSA Live: CEF

I'm pleased to announce that we have qualified and now support the ability for our Virtual Log Collector 10.6 to be installed in Amazon's AWS infrastructure.  This will allow customers to deploy VLC in AWS in order to collect logs from currently supported event sources and protocols.  This includes Amazon's CloudTrail as well as other supported event sources, such as operating systems, applications, and other infrastructure sources.  These logs will then be compressed and encrypted to be sent back to a corporate instance of Security Analytics.

 

 

The RSA Security Analytics AWS Configuration Guide can be found here.


Security Analytics 10.6 has new feature that will allow you to significantly reduce your storage footprint for long term log retention on the Archiver.  Selective Log Retention allows you to create 'buckets' for your logs and specify differing retention periods for those buckets.  This will allow you to create a bucket, or collection, for your compliance logs to keep, for example, for years.  You could create a bucket for your security relevant logs to keep for six months.  You could create a bucket for copious, low value logs to keep for weeks.

 

Previously, if you needed to keep compliance logs for years you had to keep all logs for years, whether you needed them or not.  By aging out less valuable logs in shorter time frames if frees up space for your important logs allowing you to significantly extend the retention period for those logs without adding storage.  You still have the options for Hot, Warm, and Cold storage with individually configurable settings per collection.

 

ArcDrTb.png

 

The easiest way to set up Selective Log Retention is configure rules to separate out your compliance regulation logs, such as with Event Source Groups or Device IP (device.ip), and set the appropriate, required retention period.  Next, find the bulk of the low value logs by either Event Source Type (device.type) or Message ID (msg.id) and give those the lowest acceptable retention period.  Lastly, configure the retention period on the default collection, which will contain all of the remaining logs.  Further configuration refinement can optimize storage even more.

 

Let us know what you think and how it works for you!

 

More information can be found on RSA Security Analytics Documentation under Security Analytics 10.6 > Data Privacy Management > References > Data Retention Tab - Archiver or Security Analytics 10.6 > Host and Services Configuration Guides > Archiver Configuration Guide > Configure Archiver > Step 3. Configure Archiver Storage and Log Retention > Configure Log Storage Collections.

Security Analytics 10.6 has a new beta feature that will allow SA to monitor your event sources collection and alarm or notify you when an event source falls below or exceeds a rate that is normal for that event source.  The goal is to take away the need to manually determine which event sources have similar rates, group those event sources, and create monitoring policies to match, significantly reducing the burden on system administrators.  It is enabled by default to alarm but not send notifications.

 

It takes about 5 days to build the baseline and will then start generating alarms whenever a device deviates from that baseline.  In the case in the screenshot below, this cisco router normally generates 333 events during 6:00 PM to 7:00 PM but we haven't received any events, which is 2.657 standard deviations below the normal.  The alarm shows up on the Administration -> Event Sources -> Alarms page.

 

 

You can enable email, syslog, or SNMP notifications once you determine the alarms aren't giving you false positives.  You can also tweak the Low and High standard deviations settings in order to tune it better to your environment.  Raising the standard deviations will make it less likely for an alarm to be generated.

 

 

Let us know what you think and how it works for you!

 

More information can be found on RSA Security Analytics Documentation under Security Analytics 10.6 > Event Source Management > Procedures > Configure Automatic Alerting

Filter Blog

By date: By tag: