RSA envision to RSA Security Analytics Successful Migration in a Managed Environment
Nathan Sherlock, VP of Managed Services 2
Reasons to Migrate from envision to SA Easier to move from envision to RSA SA, as opposed to any other SIEM solution Ingest, integrate and correlate log and packet events within one platform RSA SA Investigate and analyze TB s of data using pivot tools RSA SA Take incident analysis capabilities to another level 3
Use an MSSP to Migrate from envision to SA MSSP (Managed Security Services Provider) can manage both platforms in parallel during the transition one stop shop for all phases of the project MSSP can manage the envision-to-sa integration, ensuring both platforms live side-by-side and complement one another. MSSP must leverage, monitor and maintain: SA s ability to pull reports from data which resides in the envision data structure, the IPDB. envision s ability to forward logs and events which it has collected directly to the SA platform for storage, analysis, and investigative support. 4
Use an MSSP to Migrate from envision to SA MSSP 24/7/365 Security Analysts must continue security monitoring uninterrupted during the migration should not be an issue if the MSSP s alert framework is applied to both platforms MSSP objective must be RSA SA Operational Readiness, going beyond technology migration MSSP will help set a deadline for envision to be decommissioned important milestone and must be realistic typically 3-6 months 5
High-Level Transition Checklist Stand up SA for Log Data and Network Data Collection The log decoder work effort is separate from setting up network decoders but both can be done in parallel. MSSP s 24/7/365 SOC can start monitoring for network-oriented attacks via network decoders while log decoders are being setup. Enable Z-Connector on envision to send all logs to SA. Copy of logs is still kept in envision Configure alerting/reporting framework on SA - transition legacy reports and alerts to SA that are still relevant Transition device log collection to SA. This can be done over time phased approach Confirm all requirements are met and decommission the envision appliances 6
Detailed Operational Readiness Checklist (ORC) What devices currently log to envision? Use this migration to log net new devices. Is there a NEW list of all devices/assets to be monitored by RSA SA? What alerts and reports were configured on RSA envision? What stays with the new RSA SA, what goes? Use this migration to purge useless reports/alerts/dashboards. Which net new devices are natively supported by RSA SA, and which ones require a custom parser? Is RSA SA required to meet some form of compliance (ex HIPAA, PCI, SOX)? Are the in-scope devices classified by criticality, compliance (ex HIPAA, PCI, SOX? 7
ORC continued. Regardless of any compliance requirements, which devices (new or old) are most critical and why? How are the monitored devices geographically dispersed? This affects the number and distribution of required log decoders. Is their a requirement to incorporate network data elements into RSA SA? This goes beyond logging/syslog. Network decoders are fantastic when positioned and used wisely. Any specific egress points in-scope for network data collection? This affects the number and distribution of required network decoders. Is the security monitoring escalation process documented and clearly defined? 8
THANK YOU