Best Practices for Multi-Factor Authentication on IBM i
Download as PPTX, PDF0 likes213 views
The webinar discussed best practices for multi-factor authentication (MFA) on IBM i, emphasizing the limitations of complex passwords and the need for additional security layers. It outlined various MFA methods, regulatory requirements, and implementation tips, highlighting the importance of customizable solutions that integrate with existing systems. Attendees were encouraged to consider evolving regulations and best practices to improve overall security.
Best Practices for Multi-Factor Authentication on IBM i
- 1. Bill Hammond | Product Marketing Director Dawn Winston | Product Management Director Best Practices for Multi-Factor Authentication on IBM i
- 2. Housekeeping Webinar Audio • Today’s webinar audio is streamed through your computer speakers • If you need technical assistance with the web interface or audio, please refresh your browser window – Chrome is recommended Questions Welcome • Submit your questions at any time during the presentation using the Q&A box Recording and slides • This webinar is being recorded. You will receive an email following the webinar with a link to the recording and slides
- 3. Today’s Agenda • What true multi-factor authentication really is • Authentication options and tradeoffs • Tips on implementing multi- factor authentication for IBM i 3
- 5. Complex Password Issues • Should we add more complexity to passwords? Not really. • Why not? Because we write them down! • Complex password increase costs and introduce weaknesses: • Management is complex • Management is expensive • Impacts productivity (re-enabling users, password changes, etc.) • Reliance on passwords alone puts all your eggs in the same basket! NIST’s latest Digital Identity Guidelines at https://pages.nist.gov/800-63-3/ recommend against complex passwords 5
- 6. Multi-Factor Authentication Adds a Layer of Login Security Multi-Factor Authentication (MFA), sometimes called Two- Factor Authentication (2FA), uses two or more of the following factors : • Something you know or a “knowledge factor” • E.g. user ID, password, PIN, security question • Something you have or a “possession factor” • E.g. smartphone, smartcard, token device • Something you are or an “inherence factor” • E.g. fingerprint, iris scan, voice recognition Typical authentication on IBM i uses 2 items of the same factor – User ID and password. This is not multi-factor authentication. 6
- 7. Examples of MFA This is Not MFA Two things the user knows and no other factor is not MFA A combination of things the user knows, has or is provides MFA 7
- 8. Why Is Multi-Factor Authentication Required? • MFA supports the requirements of numerous industry and governmental regulations • Multi-Factor Authentication is required by • PCI-DSS 3.2 • 23 NYCRR 500 • FFIEC • MFA is mentioned or the benefits of MFA are implied for: • HIPAA • Swift Alliance Access • GDPR • Selective use of MFA is a good Security practice. You may be required to use it tomorrow, if you’re not already using it today. • SOX • GLBA • And more 8
- 9. Why Adopt Multi-Factor Authentication? • Regulations are evolving to require or recommend MFA. Consult the latest documentation for the regulations that impact your business! • MFA avoids the risks and costs of: • Weak passwords • Complex passwords • MFA is a good security measure when: • It is customizable and simple to administer • End users adoption is easy • MFA can support internal strategy and legal requirements • BYOD (Bring Your Own Device) vs COPE (Corporate Owned, Personally Enabled) • Multi-Factor Authentication is the direction! 9
- 11. Password Management Basics Passwords alone are weak. The frequency of breaches due to stolen or guessed passwords and brute- force attacks requires an additional layer of user authentication security. Basics Benefits System Value for security level QSECURITY (10,20 & more) Makes passwords required System Values for Signon attempts QMAXSGNACN & QMAXSIGN Protects from guessed password & brute force attacks System Value for Password Level QPWDLVL (0,1,2,3) Strengthens passwords Additional System Values for Password management QPWD* Strengthens passwords Single Sign On & EIM Simplifies password management SSL, TLS Encrypts passwords These measures provide basic password security. How do you take the next step in password security? 11
- 12. Authentication / Verification UserID Password Passcode Logged in Single Step SUCCESS FAILUR E Multi-Step vs. One-Step Authentication Multi-Step Authentication • Two authentication steps are presented separately • If authentication fails, the user knows which step failed One-Step Authentication • Multiple authentication factors presented at the same time • All factors must be validated before granting access • If authentication fails, user doesn’t know which factor failed Authentication Verification User ID & Password Passcode Logged in Step 1 Step 2 SUCCESS SUCCESS FAILURE FAILUR E Not understanding which authentication factor failed is frustrating for end users, but it is required by regulations such as PCI. 12
- 13. Authentication Options 13 Authentication services* generate codes delivered to the user. For example: • RADIUS compatible (RSA SecurID, Entrust, Duo, Vasco, Gemalto, and more) • RFC6238 (Microsoft Authenticator, Google Authenticator, Authy, Yubico, and more) • Others (TeleSign, and more) Use of SMS for Authentication – PCI DSS relies on industry standards, such as NIST, ISO, and ANSI, that cover all industries, not just the payment industry. While NIST currently permits the use of SMS authentication for MFA, they have advised that out-of-band authentication using SMS or voice should be “restricted” as it presents a security risk. Authentication options, beyond the basic factor that the user knows, are delivered by: • Smartphone app • Email • Phone call • SMS/text message (see box) • Hardware device such as fobs or tokens • Biometric device * Not all Authentication Services are supported in Assure Security
- 14. Key Features to Look for in an IBM i MFA Solution • Option to integrate with IBM i signon screen • Ability to integrate MFA with other IBM i applications or processes • Multiple authentication options that align with your budget and current authenticators • Certification by a standards body (e.g. RSA, NIST) • Rules that enable MFA to be invoked for specific situations or user criteria such as: • Group profiles, Special authorities • IP addresses, Device types, Dates and times • And more • Real risk-based authentication policy (integrated with access control and elevated authority management capabilities) 14
- 16. Notes on IBM i Authentication Process • Can be used to protect not only the signon screen, but also to protect application use • Users can be registered individually or globally (through group profiles, or any other user attribute) • Can identify different populations of users and challenge them using different methods • Use existing authenticators as much as possible • Options for one-step or two-step authentication 16
- 17. Tips and Questions to Consider 17 • It’s better to check more than just one authentication server, in case some are not reachable • What should be done if communication cannot be established with any of the authentication servers? • What should be done if the user provided is QSECOFR? • What should be done if the user is connected from the console? • What should be done if the user provided an incorrect IBM i password ? The initial program won’t be called… • What should be done with the QMAXSIGN & QMAXSGNACN system values? The end user should not know why his logon has failed. Text of these messages can be changed with a neutral message such as "Access denied". These messages are in the QCPFMSG message file.
- 18. More MFA Implementation Tips • The coding must be very robust in order to not let users finding weaknesses. • The coding must not leave any trace of the process in the joblog or anywhere else. • Access to journal(s) should be protected, but this is true anyway for any security policies in place • Changes to the MFA configuration need to be strongly audited and access by administrators should be prevented (using exit points) 18
- 19. Additional Uses for MFA on IBM i 19 • Enables self-service profile re-enablement and self-service password changes • Supports the Four Eyes Principle for supervised changes • Protects access to certain commands like DFU, STRSQL, STRSST, etc… • Real risk-based authentication policy (integrated with access control and elevated authority management capabilities)
- 21. 21 Assure Security addresses the issues on the radar screen of every security officer and IBM i admin Compliance Monitoring Gain visibility into all security activity on your IBM i and optionally feed it to an enterprise console Access Control Ensure comprehensive control of unauthorized access and the ability to trace any activity, suspicious or otherwise Security Risk Assessment Assess your security threats and vulnerabilities Data Privacy Protect the privacy of data at-rest or in-motion to prevent data breaches
- 22. 22 Choose the full product Choose a feature bundle Or select a specific capability Assure Security Assure Data Privacy Assure Encryption Assure Secure File Transfer Assure Monitoring and Reporting Assure Db2 Data Monitor Assure Access Control Assure System Access Manager Assure Elevated Authority Manager Assure Multi-Factor Authentication Assure Security Risk Assessment Assure Compliance Monitoring
- 23. Q&A
Editor's Notes
- #9: To improve Security Passwords alone are insufficient to protect your systems from attack Multi-step is still better than just one step Verizon 2018 Data Breach Investigations Report : “Use two-factor authentication Phishing campaigns are still hugely effective. And employees make mistakes. Two-factor authentication can limit the damage that can be done if credentials are lost or stolen.” To comply with regulations and laws HIPAA doesn't explicitly mention MFA, but due to password expiration reinforcement and updates to NIST guidance (800-63), it becomes a very reasonable solution to meet something like section 164.312d Financial companies doing business in the state of New York have to comply with the New York Department of Financial Services Cybersecurity Regulation (23 NYCRR 500). Section 500.12 (b) states that “Multi-Factor Authentication shall be utilized for any individual accessing the Covered Entity’s internal networks from an external network, unless the Covered Entity’s CISO has approved in writing the use of reasonably equivalent or more secure access controls.” To comply with regulations and laws FFIEC recommends MFA: The agencies consider single-factor authentication, as the only control mechanism, to be inadequate for high-risk transactions involving access to customer information or the movement of funds to other parties. Account fraud and identity theft are frequently the result of single-factor (e.g., ID/password) authentication exploitation. PCI-DSS version 3.2 requires companies to secure all administrative access to the CDE (Cardholder Data Environment) using MFA by January 2018 - Check document « Multi-Factor Authentication » – February 2017 - Check Requirement 8.3.
- #10: To improve Security Passwords alone are insufficient to protect your systems from attack Multi-step is still better than just one step Verizon 2018 Data Breach Investigations Report : “Use two-factor authentication Phishing campaigns are still hugely effective. And employees make mistakes. Two-factor authentication can limit the damage that can be done if credentials are lost or stolen.” To comply with regulations and laws HIPAA doesn't explicitly mention MFA, but due to password expiration reinforcement and updates to NIST guidance (800-63), it becomes a very reasonable solution to meet something like section 164.312d Financial companies doing business in the state of New York have to comply with the New York Department of Financial Services Cybersecurity Regulation (23 NYCRR 500). Section 500.12 (b) states that “Multi-Factor Authentication shall be utilized for any individual accessing the Covered Entity’s internal networks from an external network, unless the Covered Entity’s CISO has approved in writing the use of reasonably equivalent or more secure access controls.” To comply with regulations and laws FFIEC recommends MFA: The agencies consider single-factor authentication, as the only control mechanism, to be inadequate for high-risk transactions involving access to customer information or the movement of funds to other parties. Account fraud and identity theft are frequently the result of single-factor (e.g., ID/password) authentication exploitation. PCI-DSS version 3.2 requires companies to secure all administrative access to the CDE (Cardholder Data Environment) using MFA by January 2018 - Check document « Multi-Factor Authentication » – February 2017 - Check Requirement 8.3.
- #13: Multistep Versus Multifactor The PCI requirement became simpler but more restrictive, since all factors must be verified prior to the authentication mechanism granting the requested access. Furthermore, no prior knowledge of the success or failure of any factor should be provided to the individual until all factors have been presented. If an unauthorized user can deduce the validity of any individual factor, it doesn’t really matter if a different factor is used for each step. Let’s say that a CDE administrator is trying to log in to a system by Secure Shell (SSH) using a username and password. Once successfully validated, the console prompts him or her for a second factor, such as a one-time password (OTP) token. This process would be considered multistep authentication. To be considered multifactor, the administrator should be able to provide the username, password and token at the same time. If access is denied, the system should do so without disclosing which factor was entered incorrectly.