Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Security Audit on the Mainframe (v1.0 - 2016)


Published on

In this session Rui Miguel Feio will draw on his experience as a mainframe security expert to advise on how to perform a security audit on the mainframe. Rui will address what to consider before, during and after a security audit and the value and importance a company can expect from it.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Security Audit on the Mainframe (v1.0 - 2016)

  1. 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. 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. 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. 4. How secure is the mainframe?
  5. 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. 6. Mainframe hacking in the news
  7. 7. Mainframe hacking in the news
  8. 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. 9. Security Audit
  10. 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. 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. 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. 13. Let the security audit begin!
  14. 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. 15. It’s a balance
  16. 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. 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. 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. 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. 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”
  21. 21. 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!
  22. 22. Examples of recent security audits
  23. 23. 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
  24. 24. 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
  25. 25. 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
  26. 26. What does this mean?
  27. 27. Beyond the audit
  28. 28. What about all the other stuff? • Subsystems (CICS, IMS, DB2, MQ, …) • Scheduler • Automation • All the ISV products you have… • Internal applications
  29. 29. 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
  30. 30. Conclusion
  31. 31. Questions?
  32. 32. Rui Miguel Feio, RSM Partners mobile: +44 (0) 7570 911459 linkedin: Contact