Amen to that. A DR drill that goes perfectly smoothly teaches you nothing. We just finished our first successful one in a few years, but it was anything but smooth.
On Wed, Apr 9, 2025 at 6:38 AM Seymour J Metz <[email protected]> wrote: > As with any DR scenario, you need good documentation and practice. I once > work on a contract where the boss on the government side would pull a tape > at random and say "this was lost" or point at a staff member and say "he's > dead"; both of these kept us on our toes and helped us tighten up our > documentation and procedures. I was grateful that he took that approach; > I'd rather have hassle in a drill than have things go pear shaped in a live > recovery. > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > > ________________________________________ > From: IBM Mainframe Discussion List on behalf of Timothy Sipples > Sent: Tuesday, April 8, 2025 10:41 PM > To: [email protected] > Subject: Re: WORM backup tapes block ransomeware attacks? > > > External Message: Use Caution > > > >A hypothetical IT department wants all tape systems, including > >z/OS, to turn on WORM (Write Once Read Many) so that the tapes > >are immutable. The reason is for prevention of ransomware attaches > >from altering backup data. > >My question is: how does this help? If an attacker has the access and > >authorization to update a tape, they also have the access and > >authorization to copy the tape data to a new tape with altered data. > >When we restore from a backup, we don't consult a post-it note that > >says "now mount volume T13439". We mount whatever volume the > >tape catalog system says contains the data set we need. > >What am I missing? > > With WORM tape previously written data cannot be altered. If there's > previously written data that's valid (uncorrupted) in business terms and > can be read back, recovery is possible. A pre-corruption immutable backup > is a necessary but not sufficient ingredient for recovery from a > catastrophic logical data corruption incident such as a ransomware attack. > You're hinting at other necessary ingredients. As examples... > > 1. You need a surviving "good team" (with the right tools, reliably > available) that can investigate the extent of the damage, evict the root > cause(s), block re-attacks, and quickly execute recovery procedures. If > enough actors are evil, or if you don't have proper separation of duties, > that'll be a problem. > > 2. You need fast detection of logical data corruption incidents to limit > the damage and recover more quickly. > > 3. A pre-corruption immutable backup is necessary. It must also be at > least recent enough to support a viable (or at least tolerable) recovery. > WORM tape is terrific stuff, but it takes time to write. Even if you have > fast detection is 24+ hour old backup data (for example) good enough? Or do > you need more recent uncorrupted backup data so that you can recover to a > more recent point in time? > > 4. You still need to cover some other bases, notably the backup storage > should be strongly encrypted (so it's not vulnerable to data breaches, not > in that way at least) and physically protected (immutable storage can still > be physically destroyed — a magnet does a great job destroying WORM tape, > for example). Physical protection involves having at least two separate > copies in at least two physical locations. > > I'd refer you to the IBM Z Cyber Vault literature for a more thorough > discussion of these considerations. Each implementation is a little > different since requirements vary, but it's a good recipe that keeps > getting better. > > https://www.redbooks.ibm.com/redpieces/abstracts/sg248511.html > > ————— > Timothy Sipples > Senior Architect > Digital Assets, Industry Solutions, and Cybersecurity > IBM Z/LinuxONE, Asia-Pacific > [email protected] > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- Jay Maynard ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
