1. Delivering the best in z services, software, hardware and training.Delivering the best in z services, software, hardware and training.
World Class z Specialists
Security Audit on the
Mainframe
Rui Miguel Feio – Senior Technical Lead

2. Agenda
Conclusion
Summary of what
was discussed and
key points to
remember
Questions
Ask away any
questions that you
may have!
Beyond the audit
Is the audit the “final
frontier”? Things to consider
besides doing a security
audit
Real Life Examples
Some recent examples of
security audits performed on
the mainframe and their
results
Security Audit
Key points to consider
when auditing the
mainframe. What should
you audit?
How secure is it?
Is the mainframe really
secure? Can it be
hacked?

3. Who Am I?
RUI MIGUEL FEIO
• Working with RSM since 2010
• Working with mainframes for the past 17 years
• Started with IBM as an MVS Sys Programmer
• Specialises in mainframe security
• Experience in other platforms
Bio:
SENIOR TECHNICAL LEAD

4. How secure is the
mainframe?

5. Can a mainframe be hacked?
• The mainframe is highly securable but not secure by default.
– You need to invest time and resources to make it secure.
• Can the mainframe be hacked?
– Not only it can be hacked but it has already been hacked!
• Most mainframe hacking cases are not reported.
• “I could give you more examples but… I can’t” (NDA agreements)
• But there are cases that have come to public…

6. Mainframe hacking in the news

7. Mainframe hacking in the news

8. Mainframe security at risk
– Ignore the security of the mainframe and you’re up for a treat…
and not a good type of treat!
– Consider the impact for your organisation if your mainframe
was compromised…
• Financial impact
• Image
• Publicity
– Conclusion? You MUST take security on the
mainframe SERIOUS!

9. Security Audit

10. What is a security audit?
• In a very simplistic way, it’s the exercise of analysing and reviewing
the security and recommending improvements
• Each security risk identified has a category level (e.g. high, medium,
low)
• Should be done periodically (every 6 months or every year)
• Shouldn’t be seen as a ‘tick in the box’ exercise
• Shouldn’t be seen as something evil or bad

11. Challenges
• Lack of cooperation or interest from the affected teams
• Audit is some times seen as a requirement; a ”tick in a box”
• Want it done asap with minimum investment
• IT systems (or part of them) have been outsourced. Can lead to:
– Lack of cooperation and access to information and resources
– Wanting to control the Security audit and it’s outcome

12. Opportunities
• To make it official the security problems the team knows that exist
• To lead to the remediation of security problems
• To review security processes and procedures
• To justify more investment in the security mainframe area:
– To hire more staff
– For training and conferences

13. Let the security audit begin!

14. Define the scope of the audit
• How many, and which mainframe systems will be audited?
• How many RACF databases (ACF2, TSS) will be audited?
• Subsystems in scope?
• ISV products in scope?
• Internal applications in scope?
• Physical security in scope?

15. It’s a balance

16. Typical security audit
• The duration is directly dependent on the scope of the audit
• Typically:
– 3 to 5 days to audit 1 single system with one RACF DB:
• RACF (users, groups, profiles, settings, controls, DB security)
• Technical z/OS controls
• Unix System Services (USS) controls
• Communications settings and data transfer methods
– 5 days to analyse results and write report
– Total 8 to 10 days

17. Technical requirements
• Let’s take the most of the time we have and get ready before the
audit begins:
– Desktop/laptop with access to the network
– Provide security documentation
– TSO userid with system audit attribute and OMVS segment
– Ability to issue SU command in USS
– Ability to issue display commands
– Access to config files (e.g. parmlibs, proclibs, etc)
– Allow upload of code (REXX, JCL, …) to help with the audit
– Allow download of documented findings

18. Performing the audit
• Auditors may require additional access to some resources
• Auditors may need to get answers to specific questions
• At the end of the audit, all reports generated by the audit code will
be downloaded to feed on the final report
• After the audit, the documentation collected will be analysed and a
final report produced

19. Audit report
• Will describe the tests made and what was verified
• Enumerate and detail the vulnerabilities
• Classify each vulnerability by level of importance (high, medium,
low)
• Client should review the report
• A meeting should be organised to go through the report

20. After the audit
• The security audit is complete; now what?
• Well, if security vulnerabilities were identified they need to be
addressed. And addressed as soon as possible!!
• Sometimes we hear:
– “We’ll address only the high priority ones”
– “We don’t have the resources to fix the problems”
– “We’ll talk with Risk department and get a dispensation for this year”
– “We’re being outsourced; we’ll let the outsourcer deal with it”

22. Reality check
• I’ve asked you before and I ask you again: ”What would be the
impact for your organisation if your mainframe was compromised?”
– Financial impact
– Image
– Publicity
– Would your jobs be secured?
• Oh, and if you think the outsourcer will fix your security problems,
just make sure you get that in writing; otherwise you’re up for a
treat!

23. Examples of recent
security audits

24. Bank
• Recently performed a mainframe security audit at a financial
institution in Europe (51 risks identified)
• Large number of users with READ access to a daily backup copy of
the RACF database, Network controls not properly protected,…
Classification Score
High 11
Medium 23
Low 17

25. Energy company
• Mainframe security audit at a large energy company in the US this
summer (72 risks identified)
• Network controls not defined
• READ access to sensitive data!!
Classification Score
High 27
Medium 30
Low 15

26. Government agency
• Security analysis of a production RACF DB at a government agency
in the UK
• 33 security problems identified in the RACF DB
• SERVAUTH class not active!!
• Large number of users with ALTER access to Master Catalog
• All OPERCMDS profiles in Warning mode including JES2.* and
MVS.*
• RACF Databases with UACC of READ and several users with ALTER
and UPDATE access

27. What does this
mean?

30. Beyond the audit

31. What about all the other stuff?
• Subsystems (CICS, IMS, DB2, MQ, …)
• Scheduler
• Automation
• All the ISV products you have…
• Internal applications

32. Other controls
• It’s not just about mainframe security controls
• It’s about your end-to-end security posture
• It’s about the all ecosystem: mainframe, other platforms and
devices
• Consider doing regular mainframe penetration testings and
vulnerability scannings

33. Conclusion

35. Questions?

36. Rui Miguel Feio, RSM Partners
ruif@rsmpartners.com
mobile: +44 (0) 7570 911459
linkedin: www.linkedin.com/in/rfeio
www.rsmpartners.com
Contact