Migrating to Security Analytics (SA) should be approached as an opportunity to improve your security monitoring, threat detection, and investigative capabilities. Many customers begin the migration process without taking the opportunity to revise or improve upon the core components of their SIEM program such as their asset on-boarding policy, what level to log, and importantly, how to detect and respond to potential logs or sets of logs which are likely indicators of compromise. Not to mention the extra level of visibility that comes with moving to a platform which also leverages full network packet capture and session reconstruction. This blog entry will highlight critical attributes involved in migrations to improve your overall monitoring program, primarily from a log point of view as this is where all RSA enVision customers currently sit.
Improving the visibility requires mature log management. What logs do you need? Are you receiving the right logging levels? Create a spreadsheet first, then list what you currently receive in RSA enVision and at what level. Next, determine what additional logs would provide increased value. Many implementations involve asset lists that appeared in an audit years ago. Revisiting the in-scope log sources should be a quarterly occurrence. Why collect what you don’t need, while not collecting what you do.
Determining the content (reports & alerts) to migrate has been challenging for many organizations. Traditional SIEM use cases are not as relevant to today’s threat actor’s. Targeted reconnaissance, weaponization, and delivery (think kill chain) of threat actors will bypass most traditional SIEM-based detection approaches. Your Active Directory (AD) could be compromised resulting in the threat actor successfully authenticating and using the VPN to access your organization’s crown jewels. There are no multiple failed logins in this case, so looking for those won’t help your detection efforts
Take the migration from enVision to SA as an opportunity to evaluate how many alerts from your SIEM detected an actual attack or were a precursor event. Evaluate historical attacks for what indicators can be developed into an alert, report, or feed. Discuss this with your asset owners, conduct workshops, and develop new detective approaches to add to your migration. These efforts should lead to a “content migration workbook." What content is targeted to migrate, what is new, and what watchlists need to be turned into SA feeds. Most importantly, for each report or alert designated key stakeholder should be defined. Who cares about each alert or report? And do you have a response procedure to follow when that alert fires?
To properly architect your migration it is critical to define areas such as authentication and authorization, disaster recovery, business continuity, and overall systems sizing. How are my security tool engineers going to authenticate to the underlying operating system, application, and data? What is my acceptable log loss tolerance in the event of a site outage? Each disaster scenario should be carefully evaluated and receive the signoff from the key stakeholders.
Lastly, execute the design and ensure the intelligence, analytics, and business information gets in the right hands. Many organizations have excellent log analysis and alerting, however, they do not get it into the hands of the asset owners or the proper security analysts in timely manner. For example, an alert could indicate that a piece of malware is on a host, and the issue is sent to the help desk for the system to be reimaged without extracting artifacts to analyze and categorize in the organization’s intelligence database. Starting a migration with these principles built-in ahead of time will increase the success rate of your enVision migration – or for that matter any monitoring program.
David Bruskin is an Advisory Consultant with the Advanced Cyber Defense Practice.