And not just alive and able. They might be unwilling, such as in a California earthquake where a sysprog's family has a much higher priority.

On 4/9/2025 4:11 PM, Seymour J Metz wrote:
I wouldn't expect to get away from needing a systems programmer, but in a real 
disaster there's no guaranty that the entire team is still alive, much less 
able to work. It's essential to ensure that there is no single point of failure.

I once had a colleague in a coma for years after a racing accident. It's rare, 
but a DR plan has to allow for unilkely contingencies.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר



________________________________________
From: IBM Mainframe Discussion List on behalf of Tom Brennan
Sent: Wednesday, April 9, 2025 6:46 PM
To: [email protected]
Subject: Re: WORM backup tapes block ransomeware attacks?


External Message: Use Caution


Congrats on a successful test.

I was keeper of the written procedures and also watched over shoulders
at each test.  All had issues, but basically every test was smoother
than the one before.  The original goal was to get things so smooth that
anyone could do the work - manager, security guard, new hire.  We never
really approached that and I kind of conceded that we would always need
a systems programmer, at least on call.

On 4/9/2025 4:39 AM, Jay Maynard wrote:
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




----------------------------------------------------------------------
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


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to