A title that should strike fear into the hearts of all readers! Nah! I really hope not! This month, I wish to run through the parts of DORA that impact the Db2 for z/OS world mostly…
What is DORA?
Dora is the Digital Operational Resilience Act and it was created on the 14th of December 2022 with an enablement date of 17th January 2025, giving us all over two years to read it, understand it, action the requirements from it, and accept it fully into our computing culture.
How many of those things have you accomplished in the last two years? You mean you had a day job as well?
Not just Born in the USA!
DORA is valid for the whole wide world, not just businesses within the EU. If you do *any* sort of financial trading within the EU you are under the remit of DORA, just like you are with GDPR!
PCI SSC DSS new update!
As well as DORA, there is a “new” version of Payment Card Industry Security Standards Council Data Security Standard 4.0.1. It comes into force on the 31st March 2025 and it contains a lot of overlap with “our” DORA here in the EU! Here’s a link to their website.
What is the Aim of DORA?
The idea is to bring together all the disparate EU regulations into one new regulation for nearly every financial trading house (FINTEC), apart from a few exclusions e.g. microenterprises, thus simplifying the requirements and easing audit and control.
Is it Just a New Level of Audit?
Most definitely not! As the name suggests, Digital Resilience is all about surviving an attack, or a disaster, and being back and processing data (money) as soon as possible. Included within is indeed a bunch of auditable things, but I will get to them later in this newsletter.
What does DORA Cover then?
Security, Operations, Recoverability and Test. Not only these, but these are, at least for me, the biggies. The last of them – Test – is incredibly important in what they mean by “Test”. They mean Performance Test, Reliability Test and Vulnerability Test. These are not all new for us but some are. We all remember GDPR and friends, where types of data had to be “respected” otherwise you got a hefty fine. Now, with DORA, the way you work, run, update and check your systems must all be proven and reported. If you do not deliver you get – guess what? – hefty fines!
Who’s the Boss?
You might have read about this, or seen a presentation, but the absolute “boss” for this regulation is the English PDF version here:
All other versions are translated and so may have errors.
Just the Facts, Ma’am
Well, no, I am not actually going to list all the facts of DORA here, but the highlights for me are the following opening paragraphs:
46 Mandates vulnerability testing
48 Maintained systems (Current release/PTF/APAR etc.)
49 & 50 Recoverability and RTO
56 Performance, Testing and Scanning
This is a brave new world for lots of us! One of the buzzwords is ICT which is basically IT.
Book, Chapter and Verse
Chapter 2 Section II Article 6 ICT risk management framework Paragraphs 2, 4 & 6
This is all about risk management and covers unauthorized access, segregation of duties and regular internal audits.
Chapter 2 Section II Article 8 Identification Paragraphs 1, 3 & 7
Hammers home the requirement for regular updates and risk assessments after major changes.
Chapter 2 Section II Article 9 Protection and prevention Paragraphs 1, 2, 3 & 4
This is pure audit: Monitor continuously what is happening, get tooling and policies in place. Make sure that all data is secure at rest, in use and in transit. Validate authenticity and guarantee strong authentication.
This is the most important part for me – It means encrypt at rest, use SSL for *all* things remote, do not use technical user ids with passwords, use Certificates and/or use Trusted Contexts and implement at least MFA for all users. The “in use” part is a bit crazy, especially for Db2, but I am pretty sure that the Bufferpool is “trusted” and so we, as z/OS users, can ignore this part for now…
Chapter 2 Section II Article 10 Detection Paragraphs 1 & 3
Detect whether weird stuff is happening and monitor user activity!
Chapter 2 Section II Article 11 Response and recovery Paragraphs 1 & 3
Make sure you have the ability to recover quickly, and in a timely manner, making sure you have response and recovery plans all ironed out.
Chapter 2 Section II Article 12 Backup policies Paragraphs 1 & 2
Guarantee that your image copies are enough and available to minimize downtime and limit disruption. These must be regularly tested!
Chapter 4 Article 24 Testing Paragraphs 1 & 2
Test! Test and test again – at least yearly!
Chapter 4 Article 25 Testing of ICT tools and systems Paragraphs 1 & 2
Performance Testing, Penetration Testing and Vulnerability Testing.
Chapter 4 Article 26 Advanced testing and TLPT Paragraphs 1, 2 & 6
More advanced testing including a Thread-Led Penetration Test on live production systems at least every three years! All must be documented of course…
Chapter 5 Article 35 Powers of the Lead Overseer Paragraphs 1, 6, 7 & 8
Lead Overseer – I get this mixed up with Supreme Leader all the time…
The Lead Overseer is the DORA God in a given country and can simply ask for any of the details I have just listed. Failure to deliver the goods within 30 days (Calendar days, not working days!) will result in fines…
I am Fine!
Well, the fines are pretty nasty… The Lead Overseer can fine any firm up to 1% of the average daily turnover from the previous financial year. This is then compounded by the fact that the Lead Overseer can levy this fine *every* day for up to six months!!! Ouch!!!
An Example Calculation
Taking a large bank as an example, just to show the math. The turnover in 2023 was nearly 60 billion euros. Divided by 365 gives us 164 million euros per day. Taking 1% of this (worst case) gives 1.64 million euros. Assuming the Lead Overseer is being especially nasty and levels the fines for 182 days leads to around 298 million euros in fines.
I, for one, do *not* want to be the first firm in Europe getting this… and it is all in the public domain which is then a massive image loss as well!
What can I do?
Well, first up, make sure all data is encrypted at rest – This should be a no-brainer due to modern disks/SSDs anyway.
Then, make sure that *all* remote access is using the SECPORT and is being encrypted in flight – again, this should be easy but remember to then set the PORT to be the same as the SECPORT which then forces all of this. Do not forget to check your TCP/IP ALIASs!
Do a full recoverability test to guarantee that you have all the Image Copies, Logs, Archive logs that you require to actually do a full recovery. If you can also meet your RTOs here then even better! Here our RealTime DBAExpert (RTDX) software can really help out, with timely Image Copies and a verification of complete recoverability.
Audit your Db2 Systems!
Do a Vulnerability Test on your Db2 Systems!
Audit?
I have done a lot of blogs and Webinars just about Audit, so I will spare you the details, but you must actually get it done. You will almost certainly require an external auditor who does a final check/validation that your audit is good to go and then you are done. Here, our excellent WLX Audit product can suddenly become your best friend!!!
Feeling Vulnerable Today?
The Center for Internet Security (CIS) has released a document for Db2 13 on z/OS:
CIS IBM Z System Benchmarks
It contains everything you should do for Audit and vulnerability checking and is well worth a read and then action the reports within.
Docu Docu Docu
All of these things must be performed, documented and repeated on a regular basis and sometimes even after a simple “change” has occurred.
The world is a bad place and DORA is here to help us really, but the start will, as always, be a hard climb!
TTFN,
Roy Boxwell