Townsend Security Data Privacy Blog

IBM i, PCI DSS 3.2, and Multi-Factor Authentication

Posted by Luke Probasco on Aug 16, 2016 10:48:05 AM

With the recent update to the Payment Card Industry Data Security Standard (PCI DSS) regarding multi-factor authentication (also known as Two Factor Authentication or 2FA), IBM i administrators are finding themselves faced with the requirement of deploying an authentication solution within their cardholder data environments (CDE). Prior to version 3.2 of PCI DSS, remote users were required to use two factor authentication for access to all systems processing, transmitting, or storing credit card data. With version 3.2 this is now extended to include ALL local users performing administrative functions in the CDE.

Here is an excerpt from section 8.3: (emphasis added)

8.3 Secure all individual non-console administrative access and all remote access to the cardholder data environment (CDE) using multi-factor authentication.

IBM i, PCI DSS, & Multi-Factor Authentication I recently was able to sit down with Patrick Townsend, Founder & CEO of Townsend Security, and talk with him about PCI DSS 3.2, what it means for IBM i users, and what IBM i users can do to meet the latest version of PCI DSS.

Thanks for taking some time to sit down with me, Patrick. Can you recap the new PCI-DSS version 3.2 multi-factor authentication requirement? This new requirement seems to be generating a lot of concern.

Well, I think the biggest change in PCI DSS 3.2 is the requirement for multi-factor authentication for all administrators in the cardholder data environment (CDE).  Prior to 3.2, remote users like contractors and third party administrators, had to use multi-factor authentication to login to the network.  This update extends the requirement of multi-factor authentication for ALL local, non-console users.  We are seeing businesses deploy multi-factor authentication at the following levels:

  •      Network Level - When you first access the network
  •      System Level – When you access a server or any system with the CDE
  •      Application Level – Within your payment application

The requirement for expanded multi-factor authentication is a big change and is going to be disruptive for many merchants and processors to implement.

Yeah, sounds like this is going to be a big challenge.  What does this mean for your IBM i customers?

There are definitely some aspects of this PCI-DSS update that will be a bigger challenge on the IBM i compared to Windows or Linux.  First, we tend to run more applications on the IBM i.  In a Windows or Linux environment you might have one application per server.  On the IBM i platform, it is not uncommon to run dozens of applications.  What this means is, you have more users who have administrative privileges to authenticate – on average there can be 60 or more who can sometimes be a challenge to identify!  When merchants and processors look at their IBM i platforms, they will be surprised at the number of administrators they will discover.

Additionally, the IBM i typically has many network services exposed (FTP, ODBC, Operations Navigator, etc).  The challenge of identifying all the entry points is greater for an IBM i customer.

You say it is harder to identify an administrative user, why is that?

On the IBM i platform, there are some really easy and some really difficult administrative users to identify.  For example, it is really easy to find users with QSECOFR (similar to a Windows Administrator or Linux Root User) privileges.  But it starts to get a little more difficult when you need to identify users, for example, who have all object (*ALLOBJ) authority.  These users have almost the equivalent authority of QSECOFR.  Finding, identifying, and properly inventorying users as administrators can be a challenge.

Additionally, with a user profile, there is the notion of a group profile.  It is possible for a standard user, who may not be an administrator, to have an administrative group profile.  To make it even more complex, there are supplemental groups that can also adopt elevated authority.  Just pause for a minute and think of the complex nature of user profiles and how people implement them on the IBM i platform.  And don’t forget, you may have users on your system who are not highly privileged directly through their user profile, but may be performing administrative tasks related to the CDE.  Identifying everyone with administrative access is a big challenge.

Townsend Security has a multi-factor authentication solution for the IBM i.  How are you helping customers deal with identifying administrators?

From the beginning, we realized this would be a problem and we have taken some additional steps, specifically related to PCI DSS 3.2 to help IBM i customers identify administrators.  We made it possible to build a list of all users who have administrative access and then require them to use multi-factor authentication when logging on.  We have done a lot to help the IBM i security administrator identify highly privileged users and enroll them into a two factor authentication solution, and then periodically monitor/update/audit the list.

What are some of the other multi-factor authentication challenges that IBM i customers face?

Some of them are pretty obvious.  If you don’t have a multi-factor authentication solution in place, there is the effort of evaluating and deploying something on the IBM i server.  You’ll find users who may already have a multi-factor authentication solution in place for their Windows or Linux environments, but haven’t extended it to their IBM i.  Even if they aren’t processing credit card numbers on the IBM i, if it is in the CDE, it still falls within the scope of PCI DSS.

Aside from deploying a solution, there is going to be administrative work involved.  For example, managing the new software, developing new procedures, and putting governance around multi-factor authentication.  Further, if you adopt a hardware-based solution with key FOBs, you have to have processes in place to distribute and replace them, as well as manage the back-end hardware.  It has been really great seeing organizations move to mobile-based authentication solutions based on SMS text messages where there isn’t any hardware of FOBs to manage.  Townsend Security’s Alliance Two Factor Authentication went that route.

Let’s get back to PCI DSS.  As they have done in the past, they announced the updated requirements, but businesses still have a period of time to get compliant.  When does PCI DSS 3.2 actually go into effect?

The PCI SSC always gives merchants and processors time to implement new requirements.  The actual deadline to meet compliance is February 1, 2018.  However, what we are finding is that most merchants are moving rapidly to adopt the requirements now.  When an organization has an upcoming audit or Self Assessment Questionnaire (SAQ) scheduled, they generally will want to meet the compliance requirements for PCI DSS 3.2.  It never is a good idea to wait until the last minute to try and deploy new technology in order to meet compliance.

You mentioned earlier that you have a multi-factor authentication solution.  Tell me a little bit about it.

Sure. Alliance Two Factor Authentication is a mature, cost-effective solution that delivers PINs to your mobile device (or voice phone), rather than through an expensive key FOB system. IBM i customers can significantly improve the security of their IBM i systems through implementation of proven two factor authentication.  Our solution is based on a non-hardware, non-disruptive approach.  Additionally, we audit every successful or failed authentication attempt and log it in the security audit journal (QAUDJRN).  One thing that IBM i customers might also be interested in, is in some cases, we can even extend their existing multi-factor authentication solution to the IBM i with Alliance Two Factor Authentication.  Then they can benefit from the auditing and services that we supply for the IBM i platform.  Our goal was to create a solution that was very cost-effective, rapid to deploy, meets compliance regulations, and doesn’t tip over the IT budget.

Download a podcast of my complete conversation here and learn more about what PCI DSS 3.2 means for IBM i administrators, how to identify administrative users, challenges IBM I customers are facing, and how Townsend Security is helping organizations meet PCI DSS 3.2.

Podcast: IBM i, PCI DSS, and Multi-Factor Authentication

 

Topics: 2FA, IBM i, PCI DSS

PCI DSS 3.2 and Two Factor Authentication (2FA)

Posted by Patrick Townsend on Apr 28, 2016 9:14:00 AM

Capturing administrative credentials as a path to stealing sensitive credit card data is becoming a more common method used by cybercriminals. It is not surprising, then, that the PCI Security Standards Council would address this rising threat in the new version of the PCI Data Security Standard (PCI-DSS). For some time now the PCI council has been telling merchants, service providers, and banks that it would more aggressively respond to emerging threats, and version 3.2 of the PCI-DSS standard reflects this.

Two Factor Authentication IBM i White Paper One of the most effective ways of countering this threat is to implement two factor authentication (2FA or TFA). This is also sometimes call multi-factor authentication (MFA), and the two terms are used interchangeably. If you use Google, Facebook, Yahoo, or any number of other Internet services you are probably already aware of two factor authentication as a security mechanism. With two factor authentication you no longer just provide just a password to login as an administrator of an account, or to make administrative changes to your systems. You must supply a 5 or 6-digit PIN code to complete the login sequence. The PIN code is generated separately from your signon prompt and thus is harder for cybercriminals to capture.

A password is something you know, so the second factor for authentication must be something you have such as a cell phone or token, or something you are such as a fingerprint or iris image. Secret questions don’t qualify as as second factor as they are also something you know, like the password. A general description of two factor authentication can be found here.

Prior to version 3.2 of the PCI Data Security Standard, remote users were required to use two factor authentication for access to all systems processing, transmitting, or storing credit card data. With version 3.2 this is now extended to include ALL local users performing administrative functions in the cardholder data environment (CDE). This makes sense as user PCs can be infected with malware that leads to the compromise of administrative credentials. It hardly matters anymore if the user is local or remote.

Why is this a big deal?

First, many companies processing credit card data do not have remote workers, and 2FA will be new technology. Even if you have remote administrators, they are probably authenticating with 2FA via a VPN session which will not work with internal administrators. This means evaluating new 2FA solutions, deploying them in all of your CDE environments, training employees on how to use the technology, and implementing new HR procedures to manage employees and access to 2FA.

Second, many 2FA solutions require deployment on hardware servers that must be deployed and maintained. There may be impacts on the company network and firewalls, and it means a new technology ramp-up. This includes addressing hybrid environments that may encompass traditional IT data centers, virtualized environments, and cloud applications. If the 2FA solution is based on hardware tokens that employees have to carry, you will have to manage the distribution, revocation, and replacement of tokens.

Third, many merchants have complex cardholder data environments and a 2FA project can be daunting. Think about a large box store retailer. Besides the normal check-out Point-of-Sale systems, they might have pharmacy, optical, automotive, and many other departments under the same roof. The CDE might be complex and extensive and the 2FA effort may be large depending on how much administrative work is performed locally.

Last, it is not enough to deploy a 2FA solution. It must be properly monitored in real time. An attacker may attempt to guess or brute-force attack the PIN code. A good 2FA solution will log both successful and unsuccessful PIN validation requests. The logged failures should be monitored by a SIEM solution so that the security team can react to the threat quickly.

Here at Townsend Security we provide a solution to IBM i (AS/400, iSeries) customers that is based on mobile, voice, and optional email delivery of PIN codes. Alliance Two Factor Authentication integrates directly with the global Telesign network to deliver PIN codes. A customer who needs to deploy two factor authentication can install, configure and verify a 2FA PIN code sequence in less than 30 minutes. There is no hardware to install or maintain, and there are no individual tokens to distribute and manage. We think that this solution will help many IBM i customers quickly achieve compliance with version 3.2 of PCI-DSS and PA-DSS. More information here:

In future blogs I will talk more specifically about our solution.

Patrick

White Paper Two Factor Authentication on the IBM i

Topics: 2FA, two factor authentication

Making a Case for Two Factor Authentication

Posted by Michelle Larson on Nov 4, 2014 12:50:00 PM

Taking Security Beyond Usernames and Passwords

Security professionals understand that passwords alone are just not good enough protection, and the on-going flood of data breach reports just confirms this on a daily basis. Enterprise IBM i users aren’t going to stop using passwords to login to their IBM i platforms, and hackers aren’t going to slow the flood of attacks any time soon. But now, we can take a giant security step forward by implementing two-factor authentication (2FA) to dramatically reduce the risk of a security breach. Two Factor Authentication IBM i White Paper

Compromised email, social media, online gaming, ecommerce, financial services and other types of cracked accounts continue to threaten both personal and corporate interests. Out of all the threats that face individuals and companies, account compromise stands out as one of the most easily addressed with available and mature security technologies.

Historically, companies used physical tokens to provide authentication on the IBM i beyond username and password. Even if someone hacked a user’s password, they still could not login without the physical token. Tokens represent another layer of protection, which is a step in the right direction. Unfortunately, tokens increasingly do not make fiscal sense for Enterprise IT departments who have to deploy, manage, and troubleshoot large numbers of tokens. There is a better way for organizations to quickly and cost-effectively roll out two-factor authentication to a large and sometimes global user base. Solutions that leverage the mobile phone as a reliable means of authentication have become readily available for the IBM i platform. For example, instead of tokens, businesses can simply send an SMS or voice message that contains a one-time authentication code to the individual user’s phone. This means cyber criminals cannot log into the IBM i without physical control of the actual phone.

Mobile phones and landlines present key advantages for verification and authentication regimes:

    • They possess unique identifiers – phone numbers, electronic identifiers and account numbers
    • They remain in the possession of users or near at hand most of the time
    • They are difficult to spoof
    • If stolen or otherwise misappropriated, they are easy to disable
    • Their association with actual individuals is verifiable through the operators that provide phone service

While none of these attributes alone are sufficient, together they provide a compelling basis for verification and authentication. The goal is to reduce fraud and actual theft of sensitive information by implementing something much harder to defeat than a login password. Combining something the person knows with something they have, or something they are, which can then be used for two factor authentication.

1. Something you know - a password. Even “strong” passwords can still be fairly weak from an attacker's point of view. With malware that easily detects them, passwords alone are a weak defense in relation to log-in security if that's all you have.

2.  Something you have - a mobile phone. It is now becoming quite common for companies to leverage what everyone already has in the way of the mobile phone or standard phone, and use that device as a mechanism for two factor authentication.

3. Something you are biometric authentication options.  Physically scanning for an iris pattern or fingerprint.

By using 2 of those 3 things you can authenticate more securely to the system.

Here are a couple examples of things that are not two factor authentication:

    • Requiring two passwords: using one factor twice is not 2FA!
    • Using shield questions of which are actually fairly easy in our social world to determine.

The IBM i platform has a well-earned reputation for security, but security is only as strong as the weakest point in the enterprise network. User PCs, internal and external web servers, and network applications represent points of attack. These systems are not safe from:

    • Memory scraping
    • Keyboard logging
    • Stolen vendor credentials
    • Stolen user passwords from external web services

Due to the nature and the extent of these security threats on the IBM i, two factor authentication has become a viable solution for meeting compliance regulations and safeguarding the vast amount of data and numbers of users with access to sensitive information on the IBM i. We're seeing Google, Facebook, Yahoo, and almost all large commercial banking websites implementing a two factor authentication system based on SMS text and or voice verification to give additional security to their users accounts and IBM i users now have an affordable solution for their platform. Find out more by downloading this white paper:

White Paper Two Factor Authentication on the IBM i

Topics: Data Security, 2FA, IBM i, Best Practices, White Paper, Alliance Two Factor Authentication

Two Factor Authentication: A Step to Take for Better IBM i Security

Posted by Patrick Townsend on Jul 23, 2014 1:39:00 PM

Security can be hard, expensive, complicated, aggravating, confusing, and did I mention expensive?

Two Factor Authentication IBM i White Paper

As a security company, we hear this perception from new customers all the time. But there is one thing you can do for your IBM i that breaks all of these stereotypes. You can get an immediate boost in system security without much expense and without a big headache. And your users are already using this security technique on their favorite web sites.

Increase Security with Two Factor Authentication (2FA)

Almost every day a phishing email gets through our spam filters and lands in my inbox. Some of these emails are very nicely crafted and look like the real thing. The graphics are professional, the English is excellent and matches my expectations. The terminology is appropriate. Really nice work. And the links in the email are pure poison. Just waiting for that unsuspecting click to start installing malware on my PC to capture my IBM i user profile and password information.

Yup, that’s how it started at Target.

The great thing about Two Factor Authentication is that it gives businesses a lot of additional security for very little upfront cost. The aggravation factor has almost gone away. You no longer need large, expensive servers and tokens that always seem to get lost at just the wrong time. Your IBM i can do exactly what Google, Yahoo, Facebook, your bank, and many other Internet companies are doing to make security better. And your users already have the device they need - their mobile phone!

Alliance Two Factor Authentication uses the same network services and infrastructure that the big boys use for 2FA. This security solution leverages the Telesign global network to deliver PIN codes right to your mobile phone. No servers to rack up and maintain. No lost tokens.

I know, you have some reservations:

I don’t always have signal to my cell phone.

That’s OK, just send the PIN code to your voice phone. A nice lady will read you the code.

I’m in a hurry, I can’t wait for a PIN code.

PIN codes are often delivered in under a second. If you’ve got a mobile provider with a slow network, just have the PIN code delivered to your mobile phone as a voice call.

I left my cell phone home!

Right, just use one of your One Time Codes. No phone of any kind needed!

My IBM i is in Restricted State, it won’t work for me.

Alliance Two Factor Authentication does work in restricted state with a couple of steps.

I don’t want to have to enter a PIN code every time I log on, that’s just way too much work.

Don’t worry, your security administrator can configure Alliance Two Factor Authentication to only ask you once a day to authenticate, or at a user-defined interval. And if an attacker tries to access the IBM i from another device or IP address, they will have to authenticate. And that’s going to be hard to do when you have your mobile phone in your possession.

We’ve made Alliance Two Factor Authentication easy to evaluate and deploy on your IBM i. You can request a free 30-day evaluation from our web site and be up and running within an hour. You can start slowly with a few users, and then roll it out to everyone in your organization. They’ll get it right away.

You don’t have to be the next Target. Get cracking (so to speak).

Patrick

White Paper Two Factor Authentication on the IBM i

Topics: 2FA, IBM i, two factor authentication

Two Factor Authentication: Secure and Strengthen Access to your IBM i

Posted by Michelle Larson on Jul 16, 2014 12:44:00 PM

Because passwords can easily be compromised, they are considered to be a weak layer of security if used alone.

Request the Two Factor Authentication Resource Kit Now! The use of two factor authentication (2FA) provides an added layer of security beyond just standard username and password credentials. Almost all connections to the IBM i platform are over a network (LAN or WAN), and they are rarely hardwired connections. Because networks are so susceptible to snooping attacks, even LAN connections should be treated like remote access. Remote access to networks containing critical payment, patient information, or financial records can be protected with two factor authentication using your mobile phone to receive SMS and voice verification authentication codes with an easy to deploy, cost effective 2FA solution for the IBM i platform!

Protecting access with two factor authentication adds identity assurance and significantly reduces risk of unauthorized access in industries covered by PCI DSS, HIPAA/HITECH, and GLBA/FFIEC compliance regulations.

  • PCI DSS section 8.3 requires two factor authentication for remote access to systems containing credit card information.

  • HIPAA/HITECH act recommends two factor authentication to mitigate the risk of lost or stolen personal health information.

  • FFIEC guidance also calls for the use of two factor authentication to strengthen systems in the financial industry and strengthen banking websites against a financial fraud.

Although there are varying levels of enforcement, it is clear that two factor authentication plays a growing and critical security role in both compliance and following best practices.

Since launching Alliance Two Factor Authentication in January, we have had a number of questions about the product and thought we would share them here (along with the answers!)

Q: Does Two Factor Authentication integrate into my already existing Single Sign On (SSO) environment?
A: Yes!  Because the authentication process takes place after the login is complete, it will help strengthen the security around SSO.

Q: In which countries is 2FA available?
A: Two Factor Authentication is a global product. We are partnered with Telesign, which has a network of over 120 countries and the ability to work with 90+ languages to support generation of SMS messages.

Q: What profile security is required to run 2FA?
A: As a native IBM i solution, you assign normal security controls during installation.  End-users have to have use-authority to the library to use the services.

Q: Does your 2FA solution require a mobile app (like Google does) to generate the authentication codes?
A: Since our solution is fully self-contained and installed on the IBM i platform, it does not require a mobile application. The 2FA solution talks over a secure connection to the Telesign service, resulting in a pincode delivered to your mobile device as a SMS text message, or to your standard phone as a voice message.

Q: What if I don’t have access to a phone?
A: In case you don't have a mobile phone, or are in a location where you can't get cell service, your IBM i system administrator can record up to four additional voice phone numbers per user. This gives you a lot of flexibility for putting in phone numbers for home, work, cell with either the text or voice option. In the rare chance you may be someplace without access to any type of phone, Alliance 2FA provides up to 5 one-time codes for use when the phone services are not available. These are randomly generated numeric PIN codes a user has access to, that gives them the ability to authenticate even if they don't have a phone with them at the time.

Developers are also able to improve the security posture of IBM i platforms at the application level as well as during the log-in process with Application Program Interfaces (API). Alliance Two Factor Authentication does full logging of authentication and configuration changes into the IBM security audit journal QAUDJRN. For anyone running our Alliance LogAgent solution to capture information from QAUDJRN into your SIEM solution or your log collection server, this will automatically integrate 2FA in that environment. Developers can use two factor authentication for certain critical functions in the application environment such as sensitive operations about patient information, specific financial transactions, critical system functions (like powering down the system or doing a restore) that you might want to protect with 2FA. We provide a complete API set to our IBM i customers so that they can use a simple structure to initiate a two factor authentication sequence within the application. IBM i web applications can use Java, RPG, or other web languages to call the APIs and fully implement web-based 2FA within the context of the IBM i system where our two factor authentication application is running. The APIs then return to the program the result of the two factor authentication request as either succeeded or failed, and you can take actions at the level of the application to record the event or to deny or allow a particular operation.  

For more information, request our 2FA Resource Kit!

Request the Resource Kit on Two Factor Authentication

If you have additional questions about 2FA, add a comment below… we would like to hear from you!  


Topics: Data Security, 2FA, IBM i, Resource Kit, Alliance Two Factor Authentication

Two Factor Authentication on the IBM i - Webinar Q & A Recap

Posted by Michelle Larson on Feb 7, 2014 8:10:00 AM

Two Factor Authentication (2FA) adds a critical layer of security to protect user accounts and prevent fraudulent access that goes beyond password logins.

Have you made time to watch our most recent webinar on Two Factor Authentication? If not, click here to learn more about how 2FA enables companies to increase their security without the high cost of hardware & software integration by using a technology that is already a part of every user’s life, offering a better user experience with little-to-no training required. Also by leveraging your mobile phone as an authentication device, Alliance Two Factor Authentication improves the security of user account access while reducing operating costs typically associated with traditional multi factor authentication methods.   Two Factor Authentication on the IBM i

Here is a summary of the questions asked after the 2FA webinar:

Q: Does two factor authentication integrate into an already existing single sign-on environment?

A: Yes, you can deploy two factor authentication in a single sign-on environment. Alliance Two Factor Authentication runs natively on the IBM i platform, which allows you to use a SSO solution in the IBM i environment and still deploy two factor authentication to the end-user. We implement the second factor authentication on the IBM i platform, which means that we’re not linked to the actual SSO application that might be running on Windows or using an LDAP or active directory implementation. This provides you with better security for those users who are accessing your IBM i platform as it is not possible to then hijack the authentication requests in a PC environment.

Q: What company did you partner with to deliver 2FA messages?

A: Having customers all over the globe, we were very selective in choosing to partner with another company familiar with terms of network availability of two factor authentication. We chose the TeleSign Corporation. Their infrastructure has the ability to detect when SMS text messages may not be delivered, and they will fail-over to other options and take action in other routes. With guaranteed enterprise-level uptime and industry-leading deliverability rates, TeleSign has conducted more than 2.5 billion phone-based authentications and voice verifications around the globe.

Q: In which countries is two factor authentication available?

A: Our partner TeleSign has a strong, mature infrastructure in the European zone, Latin America, Asia, and delivers authentication codes to over 200 countries and that supports 87 languages. They are constantly testing network connections and performance and they've had time to build this very powerful global infrastructure for our Alliance Two Factor Authentication solution.

Q: How long does it take to deploy Alliance Two Factor Authentication?

A: We suggest you test drive our Alliance Two Factor Authentication solution which is available to download from our website. We typically turn around requests for an evaluation license very quickly and can have you up and running the same day. With our complimentary trial, we also provide TeleSign credentials so that customers can actually evaluate two factor authentication on their own systems. We provide you a fully functional 30-day evaluation, yet proof of concept for this application can be done very quickly.

Request your complimentary 30-day evaluation here

Alliance Two Factor Authentication (2FA) 30-day evaluation

We look forward to hearing about how our 2FA solution works for you!

Topics: Data Security, 2FA, Webinar, Alliance Two Factor Authentication

Defeat Unauthorized Access with Two Factor Authentication

Posted by Michelle Larson on Feb 3, 2014 10:55:00 AM

Defend your data by adding another step to your security process!

With increased losses of sensitive data from websites, retailers, and covered entities in the medical segment, we are hearing about data breaches on an almost daily basis now.  Are we as concerned as we should be, or are we getting jaded to the inevitability of data loss? When it seems like everyone is getting hacked, what kind of things can we do to help prevent access to our sensitive data? Two Factor Authentication on the IBM i

After the recent Target data breach (and a number of other ‘holiday’ breaches), more information is surfacing on how attacks happen through unsecured websites, phishing emails, memory scraping, and keyboard logging malware that can get installed on individual user PCs. Once the hackers have usernames and passwords they can work their way through a network to where the sensitive information is stored.

For those of you on the IBM i platform, it might interesting to note that the IBM i is not immune from attacks and data loss. IBM i has a well-earned reputation as a secure platform, yet we are seeing keyboard logging attacks get past that great security as users log-in to the IBM i from their PC. IBM i platforms are typically great reservoirs of sensitive information; credit card numbers, social security numbers, personally identifiable information of all types make the IBM i platform a clear target for attackers.

In addition to the basics: encrypting your data and properly managing your encryption keys, you can immediately improve your security posture in relation to log-in security, as well as application level security by using two factor authentication (2FA) to prevent unauthorized access.  

The goal is to reduce fraud and actual theft of sensitive information by implementing something much harder to defeat. Combining something the person knows (password) with something they have, or something they are, which can then be used for two factor authentication.

  • Something you know - a password

Security administrators can set system values for rules on passwords, require certain length passwords, characters and numbers, uppercase characters... but end-users are quite adept at creating passwords that can be easily remembered, yet meet the criteria of the strong password from the systems point of view. Even “strong” passwords can still be fairly weak from an attacker's point of view. With malware that easily detects them, passwords alone are a weak defense in relation to log-in security if that's all you have.

  • Something you have - a mobile phone

Mobile phones that support SMS text or voice verification are something we all have and carry with us. It is now becoming quite common for companies to leverage what everyone already has in the way of the mobile phone or standard phone, and use that device as a mechanism for two factor authentication. There are some immediate benefits to this technology:

      • Companies don't have to buy expensive additional servers and hardware
      • Users generally have a mobile phone already, and even if they replace their mobile phone, their phone number remains the same
      • Reduced cost of administrative expenses
  • Something you are - biometric authentication options (iris pattern or fingerprint)

By using 2 of those 3 things you can authenticate more securely to the system.

Here are a couple examples of things that are not two factor authentication:

  • Requiring two passwords: using one factor twice is not 2FA!
  • Using shield questions of which are actually fairly easy in our social world to determine (Just the other day I received a message on a social media site that said “Hey!  We might be related… what is your mother’s maiden name?”)

We're seeing Google, Facebook, Yahoo, and almost all large commercial banking websites implementing a two factor authentication system based on SMS text and or voice verification to give additional security to their users accounts.

Cell phones that support SMS text or voice verification are something we all have and carry with us. It is now becoming quite common for companies to leverage what everyone already has in the way of the mobile phone or standard phone, and use that device as a mechanism for two factor authentication. There are some immediate benefits to this technology:

Earlier this year we introduced Alliance Two Factor Authentication for the IBM i, which fully implements 2FA using SMS text or a voice verification call to your mobile phone.  In case you don't have a mobile phone, or are in a location where you can't get cell service, we allow the user or system administrator to record up to five mobile and voice phone numbers per user. This gives you a lot of flexibility for putting in phone numbers for home, work, cell with either the text or voice option. In the rare chance you may be someplace without access to any type of phone, Alliance Two Factor Authentication provides up to 5 one-time codes for use when the phone services are not available. These are randomly generated numeric PIN codes a user has access to, that gives them the ability to authenticate even if they don't have a phone with them at the time.

Developers are also able to improve the security posture of IBM i platforms at the application level as well as during the log-in process with Application Program Interfaces (API). Alliance Two Factor Authentication does full logging of authentication and changes to the configuration files into the IBM security audit journal QAUDJRN. For anyone running our Alliance LogAgent solution to capture information from QAUDJRN into your SEIM solution or your log collection server, this will automatically integrate 2FA in that environment. Developers can use two factor authentication for certain critical functions in the application environment such as sensitive operations about patient information, specific financial transactions, critical system functions (like powering down the system or doing a restore) that you might want to protect with 2FA. We provide a complete API set to our IBM i customers so that they can use a simple application program interface (API) structure to initiate a two factor authentication sequence within the application. IBM i web applications can use Java, RPG, or other web languages to call the APIs and fully implement web-based 2FA within the context of the IBM i system where our two factor authentication application is running. The APIs then return to the program the result of the two factor authentication request as either succeeded or failed, and you can take actions at the level of the application to record the event or to deny or allow a particular operation.

For a more in depth technical discussion, please check out this great webinar on two factor authentication by security expert Patrick Townsend:

Two Factor Authentication on the IBM i

Topics: 2FA, IBM i, Webinar, Alliance Two Factor Authentication

The Target Data Breach: Could Two Factor Authentication Have Prevented It?

Posted by Patrick Townsend on Jan 30, 2014 2:09:00 PM

Today we learned that the Target data breach may have started when hackers used stolen vendor credentials to access a Target web site or application. The application and vendor is not known at this point, but there are some lessons we can learn from this breach:

Podcast - Two Factor Authentication on the IBM i You should be sure that your vendor applications do not have fixed administrative passwords or backdoor passwords. Talk to your vendors and get their responses in writing. Don’t deploy any vendor solution that has fixed passwords that can’t be changed.

You should change any default passwords on installation of vendor solutions.

  • Use strong passwords and regularly change them
  • Use Dual Control and Separation of Duties for any highly privileged users such as system and security administrators
  • Add additional security methods to protect against this type of attack (read on)

Is there anything we can do to mitigate this type of attack?

Yes, the use of Two Factor Authentication (sometimes called Multi Factor Authentication) authentication can go a long way towards preventing this type of attack. We know that passwords alone are a poor means of authenticating a user and providing protected access to applications. Passwords are easily guessed, are often very weak, and can be stolen from our systems or a from a third-party system. Two Factor Authentication (2FA) makes it difficult to use a stolen password to access a sensitive system.

How does Two Factor Authentication work?

Two Factor Authentication adds something new to your authentication process. In addition to providing a password (something you know) to access a system, you must also authenticate with something you have (such as a mobile phone or hardware token) or something you are (fingerprint or iris scan). By adding an additional authentication method that is not readily accessible to a hacker, you get much more security.

Mobile phones are ubiquitous and have become a common way to implement 2FA. After providing a password to a web site or application, a PIN code is sent to your phone via an SMS text message or voice phone call. You have to provide the correct PIN code in order to continue. This is the method that Google and Yahoo offer, and is a common feature in on-line banking web sites. A hacker may steal password credentials, but it is much harder to take control of your phone.

In recognizing the need for better access security we recently released our new Alliance Two Factor Authentication solution for the IBM i platform. It is intended to mitigate exactly this type of attack using mobile-based 2FA.

Podcast - two factor authentication on the IBM i

Topics: 2FA, Data Breach, two factor authentication

Introducing Alliance Two Factor Authentication for the IBM i

Posted by Michelle Larson on Jan 14, 2014 2:20:00 PM

Because usernames and passwords are no longer good enough!

To protect sensitive data, businesses need another layer of security and are often turning to two factor authentication (2FA). Most of us are now familiar with online banking websites that implement 2FA; after you put in your username and password, you get a text or a voice call with a pin code to enter, in order to authenticate yourself. Two factor authentication is a well recognized method of strengthening the authentication of the user and improving the security of access to mission-critical systems. 2FA is described as taking “something you know” (your username and password), and adding “something you have” (a hardware token, ATM card, or mobile phone), or it can even be “something you are” with expensive biometric (fingerprint or retina) scans, to strengthen your security defenses. Podcast - Two Factor Authentication on the IBM i

In today's world you have to be aware that system attacks can be very intelligent. For example, a user on a PC can open up a document or PDF file and their PC can become infected with malware that does keyboard logging when they remotely log in to the IBM i. When this type of attack happens, the keyboard logging software collects user IDs and passwords and then someone uses this information to access networks beyond that PC. The IBM i platform has a well-deserved reputation for being a good solid secure platform, yet it is just as susceptible to a keyboard logging attack as any other platform. Two factor authentication is really designed to help prevent this type of malicious access, where an attack is initiated outside of the IBM i platform by using credentials that are already known to the attacker. In traditional IBM i shops, when a user logs in to the IBM i platform they provide their user ID and a password, that single factor password is “something you know”, and would get access to the system. There are a lot of system values that a security administrator can set to enforce the use of strong passwords, but adding a mobile text or voice message with a pin code (adding “something you have”) to the mix is one example of how a two factor authentication can really help strengthen the security of the IBM i platform.  Hardware tokens such as key fobs or even ATM cards have been a traditional means of 2FA, but can be costly and time-consuming  to generate (and replace) in comparison to using SMS or voice messaging via mobile phone.

By deploying a 2FA solution, organizations can easily enhance their security in a cost effective way, as well as meet compliance regulations:

  • PCI Security Standards Council has said they will continue to change and evolve compliance regulations over time as the attacks change. PCI DSS section 8.3 requires two factor authentication for remote access to systems (almost all connections to the IBM i platform are over a network, they are not generally hardwired connections or network connected devices).

  • HIPAA/HITECH act recommends two factor authentication to mitigate the risk of lost or stolen logons or passwords.

  • FFIEC guidance also calls out the use of two factor authentication to strengthen systems in the financial industry and strengthen banking websites against a financial fraud.

In the past deploying a 2FA solution on the IBM i has been costly and complex.  Townsend Securitys new Alliance Two Factor Authentication product is taking a different approach and implementing a solution that is very cost-effective on the IBM i platform. Leveraging mobile phones, the cell phones that users already carry, our new solution is strictly a software implementation. There are no expensive administrative access controls, hardware servers or hardware tokens that users carry around with them, and we think this helps control the cost. You won't incur the expense of replacing tokens and reprogramming them, it's a very straightforward install, software only solution that talks over the Internet to the SMS text or voice delivery gateway with our partner Telesign. Telesign has quite a mature implementation and infrastructure, able to deliver authentication of messages to over 200 countries in the over 80 languages worldwide. With over 2 1/2 billion accounts active today, we found them to be a great partner in bringing mobile and text-based two factor authentication to our customers on the IBM i platform.

We are pretty excited about our new “no hardware, no hardware tokens, strictly a software implementation” Alliance Two Factor Authentication solution.  Please download our latest podcast to hear more about:

  • Different methods for two factor authentication with their pros and cons
  • How businesses can meet compliance requirements with 2FA
  • Ways 2FA is helping organizations to improve the security of their core business applications
  • How we provide a full set of APIs that IBM i developers can use to enable application controls using two factor authentication
  • How you can still get the benefits of two factor authentication if you are out of cell range
  • And a number of additional security features built into the product...

Podcast - two factor authentication on the IBM i

Topics: 2FA, Podcast, Alliance Two Factor Authentication