Best Practices for Preventing and Recovering from Ransomware
Download as PPTX, PDF0 likes77 views
The document outlines a comprehensive strategy for ransomware defense focused on prevention, detection, and recovery processes specifically for IBM i systems. It emphasizes the importance of understanding ransomware vulnerabilities, establishing continuous data protection mechanisms, and conducting thorough audits to limit exposure. Best practices for maintaining security and effective recovery plans are also discussed, highlighting the need for collaboration and leveraging advanced tools to ensure resilience against attacks.
Best Practices for Preventing and Recovering from Ransomware
- 1. Ransomware Defense Prevention, Detection and Recovery Gavriel Meir-Levi | Sales Director - Security Products Barry Kirksey | Principal Sales Engineer
- 2. Session Overview 1. Prevention 2. Detection 3. Recovery 2
- 3. Session Overview 1. Prevention: Keep it Off The IBM i 2. Detection: Limit The Blast Radius 3. Recovery: Continuous Data Protection (CDP) 3
- 4. Prevention 1. What? 2. Why? 3. How? Keep it off the IBM i
- 5. Prevention 1. What are we securing? 2. Why are we securing it? 3. How are we securing it? What are we securing?
- 6. You can’t secure what you don’t understan d We’re securing the IBM i against ransomware... Prevention What are we securing? Meaning what?
- 7. Prevention How does ransomware reach the IBM i? Ingress Command and Control Encryption Compromise ! Tunneling Burrowing Anatomy of a Ransomware Attack
- 8. Ransomware Business Model Ransomware Target 3rd Party Partners Ransomware Software Developer 10-30% 70% 70% Raa$ Business model
- 9. Ransomware Business Model Ransomware Target 3rd Party Partners Ransomware Software Developer 10-30% 70% 70% Raa$ Business model Point of Network Ingress Ingress happens when the network is compromised by 3rd Party Ransomware partners.
- 10. Most Common Point of Ingress Internet Router Domain Controller NAS/Backup Storage Telephony Devices Firewall/ VPN Gateway Managed Laptops Managed Workstations Managed Servers End-of-life (EOL) Products “Under the Radar” Exploitation Source: CrowdStrike 2024 Threat Report Unmanaged network appliances – particularly edge gateway devices – remained the most routinely observed initial access vector for exploitation during 2023 Target/Unmanaged Asset Sensor Managed Asset
- 11. 1. Classic Wintel Ransomware Contamination 2. Advanced Threats that Specifically Target the IBM i Prevention What are we securing?
- 12. Keeping It Off The IBM i • The IBM i OS ‘proper’ – is generally not the target • IBM i can be affected by malware in the IFS in two ways: • An infected object is stored in the IFS IFS • Malware enters the system from an infected infected workstation to a mapped drive (that is, IBM (that is, IBM i) via a file share on the IFS the IFS Integrated File System The integrated file system is a part of the IBM i operating system that supports stream input/output and storage management similar to personal computer and UNIX operating systems, while providing an integrating structure over all information stored in the system.
- 13. The Case of the Contaminated Network Ingress Command and Control Encryption Compromise ! Tunneling Burrowing IFS Classic mapped drive ransomware scenario
- 14. Network Contamination A tale of betrayal and redemption The Human Element Security Sue Admin Andy Malicious Maxine End User Ellen THE USUAL SUSPECTS:
- 15. The Case of the Contaminated Network An AI tale of betrayal and redemption THE USUAL SUSPECTS: The Human and AI Element Security Sue Admin Andy Malicious Maxine End User Ellen WITH SPECIAL GUEST: AI Artemus
- 16. The Contaminated Network Point of ingress Malicious Maxine End User Ellen Security Sue Admin Andy
- 17. The Contaminated Network Lateral movement Malicious Maxine End User Ellen Security Sue Admin Andy
- 18. Malicious Maxine End User Ellen Security Sue Admin Andy The Contaminated Network RED ALERT: IBM i is in danger Network Share
- 19. The Contaminated Network RED ALERT: IBM i is in danger Malicious Maxine End User Ellen Security Sue Admin Andy
- 20. The Contaminated Network Rewind prewind: Planning starts before contamination Security Sue Admin Andy End User Ellen Collaboratio n IFS Access Network Segmentation Exit Point IFS Security MFA
- 21. Don’t Forget The “Why” Here comes the “how” End User Ellen IFS Access Network Segmentation Exit Point IFS Security MFA Don’t Forget The “Why” – Because End User Ellen’s access to the IFS is critical to the business. And if it isn’t… Security Sue Admin Andy Collaboratio n
- 22. Lots of Great Tools Some of which your organization already uses End User Ellen IFS Access Network Segmentation Exit Point IFS Security MFA Security Sue Admin Andy Collaboratio n Segmentation Illumio Guardicore Etc.
- 23. Zero Trust Adaptive MFA End User Ellen IFS Access Network Segmentation Exit Point IFS Security Security Sue Admin Andy Collaboratio n Segmentation Illumio Guardicore Etc. Zero Trust Microsoft365 Okta Etc. MFA
- 24. Next Gen Tools API calls are your friend End User Ellen IFS Access Network Segmentation Exit Point IFS Security Security Sue Admin Andy Collaboratio n Segmentation Illumio Guardicore Etc. Zero Trust Microsoft365 Okta Etc. MFA API Calls CrowdStrike SentinelOne Pal Alto Networks, Qradar, Etc.
- 25. Tried And True IFS Security No external tool can replace good native IFS security End User Ellen IFS Access Network Segmentation Exit Point IFS Security Security Sue Admin Andy Collaboratio n Segmentation Illumio Guardicore Etc. Zero Trust Microsoft365 Okta Etc. MFA API Calls CrowdStrike SentinelOne Pal Alto Networks, Qradar, Etc. Best Practices Journal IFS Objects Restrict QSYS.LIB Change to *Public *Exclude No Shares to Root Directory Etc.
- 26. Congratulations Sue and Andy! They kept the ransomware off the IBM i… or did they? End User Ellen IFS Access Security Sue Admin Andy Collaboratio n Malicious Maxine Rats !
- 27. 1. Audit: Security Must Be Demonstrable 2. Test For Failure 3. Limit The Blast Radius Detection Limiting the blast radius
- 28. On The Audit Trail Demonstrate success… and test for failure End User Ellen IFS Access Network Segmentation Exit Point IFS Security MFA Security Sue Admin Andy Collaboratio n Welcome to the Audit Layer Endpoint Telemetry | Network Activity | MFA Logs | Exit Point Traffic | IFS Object Changes QAUDJRN | IFS Object Journals
- 29. The Case of the Contaminated Network An AI tale of betrayal and redemption THE USUAL SUSPECTS: The Human and AI Element Security Sue Admin Andy Malicious Maxine End User Ellen WITH SPECIAL GUEST: AI Artemus
- 30. The AI Layer Use your audit data to train the AI End User Ellen IFS Access Network Segmentation Exit Point IFS Security MFA Security Sue Admin Andy Collaboratio n The Audit Layer Becomes The AI Layer Endpoint Telemetry | Network Activity | MFA Logs | Exit Point Traffic IFS Object Changes | QAUDJRN | IFS Object Journals AI Artemus
- 31. Andy is losing it Yet another job?!?! Admin Andy I already have a day job, managing the IBM i. Now they want me to become the CISO for the i AND the AI engineer for the i ?!?
- 32. Sue’s Got It She’s already ai-ready Admin Andy Thank God Sue is here!!! Security Sue Hey Andy, we’re looking at some cool AI tools for security and I want IBM i data in the mix… Collaboratio n
- 33. ALL AI-READY Sue’s AI-Ready And now so is Andy Admin Andy I have waited for this day!!! Security Sue I want your input! Collaboratio n
- 34. Advanced Detection Limit the blast radius Security Sue Admin Andy AI Artemus Collaboration Red Team Ruby End User Ellen PROD HA FTP Endpoint Scanning CDP Recovery Prevention Cloud Scanner Storage The AI SecOps Layer Endpoint Telemetry | Network Activity | MFA Logs | Exit Point Traffic | IFS Object Changes | CIS Benchmarks| I/O Activity QAUDJRN | IFS Object Journals | Cloud Scanning | FTP Endpoint File Scans | Red Team Activity | Remote CDP Journals | Pen Testing
- 35. 1. Malware Written for The IBM i • Rare • Insider Threats 2. Advanced Persistent Threats that Target the IBM i • Live Off The Land (LOTL) • Insider-Like • Example: Involved SSH Keys accessed via AIX Advanced Threats Limiting the blast radius
- 36. Recovery
- 37. The system is corrupt! What now? • You must have a Continuous Data Protection (CDP) recovery plan! • Execute the plan • Recover to an acceptable point prior to the corruption
- 38. Planning: Maintain known good starting points Regular SAVEs Pros: • Allows for the most granularity (file, library) Cons: • Restore time • Not suitable for IFS Directories Flash copy/Snapshot image Pros: • May be faster than restore • Suitable for IFS Directories and Stream files Cons: • Quality of snapshot questionable • Requires restore of Journal Receivers Journal Receivers • Needed for rolling forward from start point • Immutable • Must be retained (protected from deletion)
- 39. Planning: Requirements for CDP Apply Journal Change: Method to roll forward (apply) the journal entries from the known good point. Logical Replication Software: Software to roll forward (apply) the journal entries from the known good point. Start Point: Point in the journal receiver chain of the chosen known good point to Roll Forward from. Recovery Point: Point in the journal receiver chain where logical replication should stop. This is typically before the point of corruption. Final Readiness Process: • Typical Unplanned Switch Procedure to prepare the Database for normal operations (i.e. commitment control, triggers referential constraints, etc). • Final User validation
- 40. Planning: Snapshot Quality State of Production LPAR at Time of Flash Open Commits All user data written to storage Known Transaction Point Quality of snapshot Requires outage Powered down No Yes Yes ⭐⭐⭐⭐⭐ Yes Restricted State No Yes Yes ⭐⭐⭐⭐ Yes Applications down No Yes Yes ⭐⭐⭐⭐ Yes Quiesced applications No Yes Yes ⭐⭐⭐⭐ Yes Application running with FORCE WRITE action performed No In doubt No ⭐⭐ No Application running with FORCE WRITE action performed Yes Unlikely No ⭐ No Application running No In doubt No ⭐ No Application running Yes Highly unlikely No ⭐ No
- 41. Known Recovery Point IBM I Vol 01 IBM I Vol .. IBM I Vol .. IBM I Vol .. IBM I Vol 88 ID 23100915 ID 23100915 ID 23100915 ID 23100915 ID 23100915 ID 23100915 ID 23100915 ID 23100915 ID 23100915 ID 23100915 ID 23100915 ID 23100915 ID 23100915 ID 23100915 ID 23100915 ID 23100915 ID 23100915 ID 23100915 ID 23100915 ID 23100915 ID 23100915 ID 23100915 ID 23100915 ID 23100915 ID 23100915 ID 23100915 ID 23100915 ID 23100915 Production Data Immutable Snapshots – Every Hour GOOD WARNING FAIL Validated Immutable Snapshots Known Recovery Point and Recovery Times
- 42. “Be Prepared” for CDP Recovery -168 HR -144 HR -120 HR -96 HR -72 HR -48 HR -24 HR Snapshots Full Backup Incremental Backup Known Good Points High Quality snapshot Low Quality snapshot Journal Receivers System Corrupt Normal LPAR A: !
- 43. CDP Recovery: from SAVE -168 HR -144 HR -120 HR -96 HR -72 HR -48 HR -24 HR Full Backup Incremental Backup Known Good Points Journal Receivers System Corrupt LPAR A: Recovery Operations Recovery Point Start Point • System restore • Libraries • Files • Objects Normal LPAR B: Roll Forward Restore offers granularity to the object level, but will be slower to complete
- 44. CDP Recovery: from SNAPSHOT -168 HR -144 HR -120 HR -96 HR -72 HR -48 HR -24 HR Journal Receivers System Corrupt Recovery Operations Recovery Point Start Point • IPL Snapshot Normal LPAR B: Roll Forward Snapshots Known Good Points LPAR A: High Quality snapshot Low Quality snapshot
- 45. CDP Recovery at the LPAR level A A Roll forward Restore Roll forward IPL Snapshot Recovery Point Recovery Point Roll Forward Recovery: from SAVE Roll Forward Recovery: from SNAPSHOT
- 46. Multi-LPAR CDP Readiness Topology A - Primary B - Backup Real-time HA/DR A - Recovery B - Recovery Journal Receivers Journal Receivers must be retained. Protect them from deletion by replicating them to another separate LPAR
- 47. Example Event Timeline - NORMAL Timestamp Event LPAR Comments Sunday 0100 Database SAVE A or B Media should be available to B system Regularly Remote Journal Receiver SAVEs B Receivers are required for roll forward recovery - should be changed regularly and saved expeditiously
- 48. Example Event Timeline – Cyber Attack Timestamp Event LPAR Comments Thursday 1400 Cyber attack – Rogue database changes occur A Rogue record changes are replicated to B Thursday 1415 Production isolated and offline A B is online, but not available to users. Thursday 1700 Decision to perform a roll forward recovery
- 49. Example Event Timeline - Recovery Timestamp Event LPAR Comments Thursday 1730 CLRLIB completed, RESTORE started B Affected libraries Friday 1300 RESTORE completed B Affected libraries Friday 1315 Initialize Data Groups for restart B Set Data Group Recovery Point Friday 1330 Replay forward from SAVE Point B Start Data Groups from SAVE point in journal receivers. Recovery Point – 1 Reach Recovery Point B Stop Data Groups Recovery Point – 2 Perform final readiness B Switch Procedure to close commit control cycles, prepare database Recovery Point – 3 Present recovered database B
- 50. Questions
- 51. Thank You