IBM I Security – Best Practices
Total Page:16
File Type:pdf, Size:1020Kb
Session: 500050 Agenda Key: 24FG IBM i Security – Best Practices Jeffrey Uehling IBM i security development [email protected] © 2015 International Business Machines Corporation 1 Best Practices - Outline Physical Security Staying Current on Fixes System security levels System value settings Security audit journal Resource security Network security © 2015 International Business Machines Corporation 2 Physical Security © 2015 International Business Machines Corporation 3 Physical Security – a Necessity • Physical Security, Server • Front panel • Power, cabling • Racks/Storage devices • Physical Security, Networking • Firewalls, routers, switches, cabling, power • Prevent configuration changes and sniffing equipment • Wireless poses a challenge, secure networks are necessary (WEP, WPA, WPA2 etc) • Physical Security, Peripherals • Tape drives/cartridges, Printers/output, Fax, etc. • SAN attached DASD • Mobile Devices © 2015 International Business Machines Corporation 4 Staying Current on Fixes © 2015 International Business Machines Corporation 5 Security Vulnerabilities Many security vulnerabilities are being reported… Heartbleed, Bash/Shellshock, Poodle, Ghost, Freak, Bar Mitzvah plus many, many more! What’s happening and why so many? Numerous independent researchers Lots of open source so easy to review code and look for issues Common OS in many products (Linux, Unix, Windows) – So when a vulnerability is found, it’s likely to be everywhere Tools are available to exploit technology (look for holes) – Hacker tools, penetration testing tools, code scanners High use technology, like Java, SSL, OpenSSL, is scrutinized Vendors are doing more penetration testing thus finding bugs © 2015 International Business Machines Corporation 6 Security Vulnerabilities – IBM i IBM i technology areas with multiple (recent) reported vulnerabilities Java (quarterly updates, you need to stay current) OpenSSL Web and Application Servers Samba Networking technology and (infrequently) cryptographic algorithms IBM i OS Typically, Apply the PTF/Fix/Product Update and the vulnerability is fixed, But, not always as additional actions may be required © 2015 International Business Machines Corporation 7 Security Vulnerabilities – Not just the OS Staying Current on Fixes – not just a client and server problem The vulnerabilities affect most everything in your enterprise IBM i OS, LIC and Products VIOS, IBM i, AIX, Linux partitions HMC & Firmware 3rd party (vendor) applications SAN/Storage, Tape, Printers Networking Switches, Firewalls & Routers Each and Every Server, Client (including mobile) and HW component in your Enterprise – Nearly everything includes an OS and/or FW (where there is code, a vulnerability is a possibility) © 2015 International Business Machines Corporation 8 Poodle & Bar Mitzvah – Vulnerabilities with no fix What are the Poodle/Bar Mitzvah Vulnerabilities SSLv3 contains a vulnerability that has been referred to as the Padding Oracle On Downgraded Legacy Encryption (POODLE) attack , which is a man-in-the-middle attack affecting Web browsers/applications. Bar Mitzvah is similar in that it is present when the RC4 Algorithm is used in SSL & TLS. There is NO fix for SSLv3 or for RC4. Customer must move to TLS and away from RC4 Applications connecting via SSLv3 to servers are exposed to the POODLE attack. As applications, servers, and browsers disable the use of SSLv3, many applications will fail because they don’t support the more secure and latest technology called TLS (Transaction Layer Security) or the app is written directly to SSLv3. Same with RC4. © 2015 International Business Machines Corporation 9 IBM Security Process - PSIRT Product Security Incident Response Team Global IBM Core Team (including IBM i representatives) xForce (IBM Wide Security Team, vulnerability assessment) – CVSS (vulnerability Scoring) Industry Affiliations – Vulnerability Reporting ICASI (Industry Consortium for Advancement of Security on the Internet) FIRST (Forum of Incident Response and Security Teams) IT-ISAC (Information Technology - Information Sharing and Analysis Center) FS-ISAC (Financial Services - Information Sharing and Analysis Center) PSIRT Process Output: • PTFs/Fixes • Security Bulletin – customer notification of problem and fix © 2015 International Business Machines Corporation 10 Security Fixes IBM i Security PTF Group Not all PTFs/Fixes can be added to the Security PTF Group because of installation requirements! Java updates iAccess Web and Application Servers Lotus etc. And fixes for areas such as HMC, FW, VIOS, Networking Equipment, Peripherals, Other Platforms, etc. © 2015 International Business Machines Corporation 11 Customer Awareness of Security Issues The “Press” IBM Support Center Typically after a public announcement of a vulnerability PSIRT publication of Security Bulletin URLs My Notifications (Customer Subscription) Security Bulletins Technotes The support for IBM i subscription via “My Notifications” for security bulletins is available. © 2015 International Business Machines Corporation 12 IBM i Server Security © 2015 International Business Machines Corporation 13 System Security Levels System Value: QSECURITY © 2015 International Business Machines Corporation 14 Security levels, why run at a high security level System security level 50... Good reasons to run there. 1. Object Domain Checking 2. Hardware storage protection 3. Parameter validation NOTE: System security level controlled via QSECURITY system value © 2015 International Business Machines Corporation 15 Security Level 30 – Not a secure environment • System interfaces perform appropriate authority checks but security exposures exist on this security level (examples will follow) • *USE required by DSPDTAARA • *CHANGE required by CHGDTAARA Security level 30 is NOT a secure security level! User written programs, running at security level 30, can gain “write” access to objects with minimal authority © 2015 International Business Machines Corporation 16 Object Domain attributes - Object integrity Every object: *CMD, *FILE, *PGM, etc. has a “domain” Every program has a “state” (*SYSTEM or *USER) Program state is compared against object Domain Program run state: *SYSTEM or *USER (DSPPGM/DSPSRVPGM) Object Domain: *SYSTEM or *USER (DSPOBJD) Programs running *SYSTEM state can access both *USER and *SYSTEM domain. Programs running *USER state can only access *USER domain objects. • Security level 30 ALLOWS access regardless of state/domain combination • Security level 40 and 50 enforce domain checking © 2015 International Business Machines Corporation 17 Object Domain, Program State Object Domain Program State © 2015 International Business Machines Corporation 18 Hardware Storage Protection (HSP) - Object integrity Program state is compared against object HSP to determine allowable access. Every object has a HSP value. Object HSP attributes: − Allow access from any state (no protection, *USRSPC, *USRQ, *USRIDX) − Read only in any state (*PGM, *SRVPGM) − No access in user state (Setting for most objects, 5.3 and prior) − Enhanced storage protection (5.4 and beyond) • Security level 30 ALLOWS access regardless of state/HSP combination • NOTE: Some HSP violations can occur on all security levels • Security level 40 and 50 enforce HSP checking © 2015 International Business Machines Corporation 19 Object attributes – Integrity Protection required MI object overview Encapsulated MI Object header, available to LIC –Object domain (Most objects are *SYSTEM domain) –Object owner –Public authority LIC Only –Hardware storage protection setting –Encapsulated object data Associated space, byte addressable area for use by above MI (user and OS) programs. The associated space is used to store operating OS & LIC system and user data for objects, i.e. *CMD, *DTAARA, *JOBD, *USRSPC, *USRPRF, etc. Encapsulated Data Segment, *FILE, *STMF, etc John Smith 111-33-5555 LIC Only Jeff Uehling 222-44-6666 © 2015 International Business Machines Corporation 20 Authority checking and integrity support at level 40 & 50 User written programs, running at security level 40 or 50, MUST use system interfaces (commands and APIs) to gain access to the objects. – Authority checking is enforced by the system interface – Parameter Validation is performed – Object Domain checking is performed – Object Hardware storage protection is performed Direct access by user programs to system objects is not allowed at Security level 40 and 50 due to domain and hardware storage protection attributes. © 2015 International Business Machines Corporation 21 Disclaimer This presentation contains programming examples ("Sample Code"). IBM grants you a nonexclusive copyright license to use the Sample Code to generate similar function tailored to your own specific needs. The Sample Code is provided by IBM for illustrative purposes only. The Sample Code has not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of the Sample Code. The Sample Code contained herein is provided to you "AS IS" without any warranties of any kind. THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGMENT ARE EXPRESSLY DISCLAIMED. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO THE ABOVE EXCLUSIONS MAY NOT APPLY TO YOU. IN NO EVENT WILL IBM BE LIABLE TO ANY PARTY FOR ANY DIRECT, INDIRECT, SPECIAL OR OTHER CONSEQUENTIAL DAMAGES FOR ANY USE OF THE SAMPLE CODE INCLUDING, WITHOUT