One good practice is the trainee or alternate does all the work using the documented instructions. Any additions during the exercise are recorded and added to the instructions for next time.
On Wed, Apr 9, 2025 at 6:37 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 > -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
