Best Practices for Preventing and Recovering from Ransomware
Syncsort
77 views
51 slides
Jul 09, 2024
Slide 1 of 51
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
About This Presentation
You need to implement a ransomware prevention strategy to protect your IBM i. While prevention is the first and potentially most effective step, what happens if you do get compromised? What if you could restore back to a point before the ransomware attack occurred?
Join us to learn more about how a ...
You need to implement a ransomware prevention strategy to protect your IBM i. While prevention is the first and potentially most effective step, what happens if you do get compromised? What if you could restore back to a point before the ransomware attack occurred?
Join us to learn more about how a Prevent-Detect-Recover strategy can be a powerful solution by using a combination of storage and replication technologies to effectively recover in the event of a malware attack.
During this webinar, we will explore key topics such as:
Understanding ransomware prevention strategiesPreventing most common ransomware vulnerabilitiesHow to get back to a point before the ransomware attack
Size: 8.63 MB
Language: en
Added: Jul 09, 2024
Slides: 51 pages
Slide Content
Ransomware Defense Prevention, Detection and Recovery Gavriel Meir-Levi | Sales Director - Security Products Barry Kirksey | Principal Sales Engineer
Session Overview Prevention Detection Recovery 2
Session Overview Prevention: Keep it Off The IBM i Detection: Limit The Blast Radius Recovery: Continuous Data Protection (CDP) 3
Prevention What? Why? How? Keep it off the IBM i
Prevention What are we securing? Why are we securing it? How are we securing it? What are we securing?
You can’t secure what you don’t understand We’re securing the IBM i against ransomware... Prevention What are we securing? Meaning what?
Prevention How does ransomware reach the IBM i ? Ingress Command and Control Encryption Compromise ! Tunneling Burrowing Anatomy of a Ransomware Attack
Ransomware Business Model Ransomware Target 3 rd Party Partners Ransomware Software Developer 10-30% 70% 70% Raa $ Business model
Ransomware Business Model Ransomware Target 3 rd Party Partners Ransomware Software Developer 10-30% 70% 70% Raa $ Business model Point of Network Ingress Ingress happens when the network is compromised by 3 rd Party Ransomware partners. It’s the partner’s job to get the ransomware software onto the network.
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
Classic Wintel Ransomware Contamination Advanced Threats that Specifically Target the IBM i Prevention What are we securing?
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 Malware enters the system from an infected workstation to a mapped drive (that is, IBM i ) via a file share on 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.
The Case of the Contaminated Network Ingress Command and Control Encryption Compromise ! Tunneling Burrowing IFS Classic mapped drive ransomware scenario
Network Contamination A tale of betrayal and redemption The Human Element Security Sue Admin Andy Malicious Maxine End User Ellen THE USUAL SUSPECTS:
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
The Contaminated Network Point of ingress Malicious Maxine End User Ellen Security Sue Admin Andy
The Contaminated Network Lateral movement Malicious Maxine End User Ellen Security Sue Admin Andy
Malicious Maxine End User Ellen Security Sue Admin Andy The Contaminated Network RED ALERT: IBM i is in danger Network Share
The Contaminated Network RED ALERT: IBM i is in danger Malicious Maxine End User Ellen Security Sue Admin Andy
The Contaminated Network Rewind prewind : Planning starts before contamination Security Sue Admin Andy End User Ellen Collaboration IFS Access Network Segmentation Exit Point IFS Security MFA
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 Collaboration
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 Collaboration Segmentation Illumio Guardicore Etc.
Zero Trust Adaptive MFA End User Ellen IFS Access Network Segmentation Exit Point IFS Security Security Sue Admin Andy Collaboration Segmentation Illumio Guardicore Etc. Zero Trust Microsoft365 Okta Etc. MFA
Next Gen Tools API calls are your friend End User Ellen IFS Access Network Segmentation Exit Point IFS Security Security Sue Admin Andy Collaboration Segmentation Illumio Guardicore Etc. Zero Trust Microsoft365 Okta Etc. MFA API Calls CrowdStrike SentinelOne Pal Alto Networks, Qradar , Etc.
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 Collaboration 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.
Congratulations Sue and Andy! They kept the ransomware off the IBM i … or did they? End User Ellen IFS Access Security Sue Admin Andy Collaboration Malicious Maxine Rats!
Audit: Security Must Be Demonstrable Test For Failure Limit The Blast Radius Detection Limiting the blast radius
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 Collaboration Welcome to the Audit Layer Endpoint Telemetry | Network Activity | MFA Logs | Exit Point Traffic | IFS Object Changes QAUDJRN | IFS Object Journals
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
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 Collaboration 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
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 ?!?
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… Collaboration
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! Collaboration
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
Malware Written for The IBM i Rare Insider Threats 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
Recovery
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
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)
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
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
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
“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 P oints High Quality snapshot Low Quality snapshot Journal Receivers System Corrupt Normal LPAR A: !
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
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 P oints LPAR A: High Quality snapshot Low Quality snapshot
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
Multi-LPAR CDP Readiness Topology A - Primary B - Backup Real-time HA/DR A - Recovery B - Recovery Journal Receivers Journal Receivers Journal Receivers must be retained. Protect them from deletion by replicating them to another separate LPAR
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
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
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