Customizing Two-Factor Authentication to Protect your Information
The idea is that people who own the data are more likely to understand its sensitivity and level of protection required than the people who design systems. On the other hand, system designers have the necessary technical skills to implement robust protection mechanisms. Our framework allows for the optimal ‘separation of duties’ — we implement the best of breed 2FA mechanisms, and our users apply those where and when they think it makes sense.
3 August 2010
Last year, I wrote about the Intralinks vision for using enhanced two-factor authentication (2FA) to protect data in a SaaS-based environment. What I covered in that blog was used as a basis for designing a customized 2FA (or strong authentication) framework for the Intralinks platform. The most important feature of the framework is the adaptability it offers to users for their security policy requirements. The idea is that people who own the data are more likely to understand its sensitivity and level of protection required than the people who design systems. On the other hand, system designers have the necessary technical skills to implement robust protection mechanisms. Our framework allows for the optimal ‘separation of duties’ — we implement the best of breed 2FA mechanisms, and our users apply those where and when they think it makes sense.
The very first release with strong authentication capabilities that Intralinks delivered had pre-configured options to choose from. Data owners were required to either challenge the users when they tried to access certain information (Exchanges) or reward low risk behavior with no challenge. In risk-based authentication mode, information from the current session, as well as prior behavior, is used to calculate the risk score. That score will prompt a challenge only if it is over a certain threshold, which is set on the policy server.
Our framework also provides a selection for the challenge type: a challenge question, a one-time password, and a hybrid method. It ensures an escalation to a one-time password if the first three attempts to answer the challenge question were unsuccessful (this locks the challenge question and will always bring up a prompt for the one-time password).
These security options correspond to specific rules on the back-end policy engine provided by an RSA product called Adaptive Authentication (AA). By partnering with RSA, we benefit from the functionality and maturity of the solution, as well as from the independent security certifications that have been used for AA. We also benefit from RSA’s vast database, eFraudNetwork, which keeps a list of IP addresses and device fingerprints that have been previously used to commit fraud against any user of the system.
The capabilities described above satisfied the vast majority of our customers’ strong authentication needs. However, almost immediately after going live we started to get requests to make our 2FA framework more flexible. Customers wanted to have their own rules on the backend mapped to their Exchanges. With the latest enhancements to our platform, we can now fully meet these types of requests.
Customers can now request for custom risk-based authentication rules to be created for an Exchange, giving greater flexibility in designing how and when authentication rules will be applied. For example, if the customer has an Exchange where they want to restrict access from public networks, they can create a rule that “white lists” their IP addresses while declining access for all other requests. If the end user is on their corporate network, access is granted. If not, access is denied. They can setup the same rule to challenge for requests originating outside of own network and not challenge requests from within. Many more interesting scenarios, such as creating a rule that allows an Exchange to be available only on the days that a client’s company is open for business are possible to implement.
The evolution of 2FA technology has opened up new capabilities for product integration. Frameworks have transformed from being a pure security measure for restricting access to enabling technology that allows businesses to move more quickly to adopt cloud-based solutions. I am excited for the future as 2FA opens up the SaaS delivery model and look forward to the new challenges our customers’ security requirements will present.
Mushegh Hakhinian represents Intralinks at the Cloud Security Alliance SME Council, is a certified information systems security professional, and is a frequent contributor to industry publications. Prior to joining Intralinks, Mr. Hakhinian lead security functions at a multi-tenant online banking service provider and an international bank.