Monday, July 21, 2008

SecureAuth®, “Virtual Certificate Authority” Solution for Secure Authentication


By Garret Grajek, CISSP
COO, MultiFactor Corp.

A Deployable X.509 Authentication Solution for Networks and Web Applications

MultiFactor SecureAuth offers the enterprise the unique ability to utilize strong X.509 authentication without costly overhead.

The value of X.509 private/public key authentication is well known to security professionals, but it can be less intuitive to the security novice. In simple terms the X.509 authentication provides an algorithmically proven method for end-users (clients) to confirm that they are communicating with legitimate servers and not attacker sites (See Figure 1). The recent DNS flaw Dan Kaminsky, a well respected security industry expert, made known to the IT world via bug fixes by Cisco, Microsoft and others, makes this type of “left hand side” or client authentication more relevant than ever.

Figure 1 - Clients are vulnerable to attacks that lure them to illegitimate sites instead of the target (destination) site.

An X.509 v3 public/private key pair allows an enterprise to utilize “bi-lateral” (client <-> server) authentication. In this matter, the client confirms the legitimacy of the server, before passing important credentials e.g. account password or transactions like asignature or financial activity. It is exactly this type of bi-lateral authentication that nullifies DNS attacks like the one recently reported.

So why are more enterprises not utilizing X.509 authentication?

(2) Main reasons:

  • Cost
  • Complexity

Security personnel have been aware of X.509 bi-lateral authentication since the 90’s. However, cost has prohibited its widespread use (See Figure 2).

Figure 2- The complexity of a “classic” X.509 infrastructure is too daunting for most enterprises

Key costs include:
  • Hosting a Certificate Authority
  • Tracking both the served and revoked certificates

SecureAuth® eliminates the high-cost and complexities of managing X.509 certificates via a “Virtual Certificate Authority”

SecureAuth:

  • Removes the cost of deploying certificate servers
  • Removes the cost of tracking deployed/revoking certificates
  • Removes the cost of out-of-band (SMS, Telephony) registration systems
  • Removes the cost of converting current web servers to C-SSL authentication

SecureAuth® uniquely utilizes a “drop-in” authentication server ,a virtual machine or hardware server, that becomes a trusted resource which is able to:

  • Connect to MultiFactor’s hosted C.A., SMS servers, and telephony servers
  • Serve up private/public key pairs unique to an enterprise
  • Create/install Trusted Root Pairs that map directly to your enterprise

A key to SecureAuth is its ability to utilize the enterprise native data store, allowing it to avoid a costly and insecure replication of data. SecureAuth’s authentication server connects directly to the enterprise's existing data store to create X.509 certificates that map directly to data in the local store (See Figure 3).

Figure 3- The SecureAuth “Authentication Appliance” solution alleviates the cost and complexity of X.509 authentication. (Click to enlarge)

For the enterprise the addition of the SecureAuth authentication component is key. The deploying enterprise configures its web application to trust SecureAuth authentication via .NET Forms for Microsoft authentication, or SAML assertions for non-Microsoft applications. The SecureAuth appliance is factory-configured to securely utilize the MultiFactor hosted certificate, SMS and Telephony services.

The Enterprise is delivered a unique identifier that allows them to securely utilize MultiFactor’s hosted web services. In addition, certificates granted from the web services are embedded with identifiers that are uniquely registered to that enterprise. The identifier is stored in the end-user’s private certificate, in the “OU” field (See Figure 4).


Figure 4- The enterprises is assigned a unique OU that is utilized in both certificate delivery and validation, only enterprise-unique certificates are validated.

This unique ability to issue and validate certificates for an enterprise, without the enterprise ever hosting a certificate server, makes SecureAuth® powerful. SecureAuth® can be deployed in a days which makes it a deployment-must for the enterprise needing a secure solution for their application and network needs.

--
Garret Grajek is the COO and a co-founder of MultiFactor Corporation. He is a certified security engineer who has deployed 100s of security solutions while working for RSA, IBM, Cisco and others.

Monday, July 14, 2008

SecureAuth Can Secure End Users Against DNS Attacks

SecureAuth Secures End Users Against DNS Attacks the Enterprise may Incur.

By Garret Grajek, CISSP
COO, MultiFactor Corp.

In early July, Dan Kaminsky reported that a serious flaw exists in DNS software. Despite the bad news, Dan remained scrupulous and worked behind the scenes with Microsoft, Cisco, Sun, CERT and others before publicly disclosing the flaw on July 9th, details of which will be revealed in August. Patches have been made available by various vendors.

The question enterprises have to ask themselves is, are they comfortable with the public DNS system being their only line of defense in assuring that their END-USERS are actually connected to their site? (e.g. When the end-user clicks http://www.ubank.com/ is the end-user going to the site hosted by “Ubank,” or is the end-user being rerouted to a fictitious site)? (See Figure 1)

Figure 1 - The hacker utilizes a DNS attack as one of the methods to lure the Internet user to the attacker site.

The key to addressing this solution is to provide the end-user with a secondary mechanism that ensures he or she is at the correct site. As the Kaminsky report reveals, DNS alone is not 100% reliable, and it should not be the only mechanism utilized for resource-valued sites.

A mechanism that does ensure an end-user’s connection to the legitimate site is client-side SSL (C-SSL). C-SSL technology utilizes public/private key cryptography to conduct a bi-lateral authentication that affirms the proper identity of not only the client, but also the server.

Figure 2 - A deployment utilizing PKI can thwart this type of DNS attack by utilizing public/private key technology to verify the site’s address.

The issue has been implementing this technology on two sides:

  • Client side
  • Server side

Historically, PKI has been too difficult to implement on the client-side due to end-user education. Equally difficult, certain components have made implementation and maintenance too burdensome on the server-side. MultiFactor SecureAuth addresses both of these issues. (See Figure 3)

Figure 3 - SecureAuth addresses client-side and server-side complexities to allow bi-lateral, X.509 authentication. (Click to enlarge)

MultiFactor SecureAuth resolves PKI issues for the client

SecureAuth is 100% browser-based. It uses the browser to:

  • Store the Private/Public Key Pair
  • Retrieve the proper end-users’ key pair
  • Validate the proper end-users’ key pair

The end-user requires no knowledge of storing, revocation, or porting of certificates. SecureAuth’s unique, click-through registration method handles all the complexities for end-users.

MultiFactor SecureAuth resolves PKI issues for the Server

SecureAuth handles the X.509v3 authentication and validation without C-SSL; this saves an enormous amount of complexity for end-users. SecureAuth’s uniqueness is a self-contained X.509 validation mechanism that enables the validation of end- users’ X.509 credentials by utilizing standard server-side certificates. (E.G. SecureAuth utilizes the certificate that enables SSL encryption for a site, such as https://www.company.com/).

Figure 4 - SecureAuth utilizes its own technology to validate the client-server authentication, thereby validating both parties. This greatly reduces overhead and deployment cost to the X.509 solution. (Click to enlarge.)

In summary, enterprises wishing to provide secure sites are concerned about authenticating servers and end-users accessing the targeted sites. MultiFactor SecureAuth is an excellent solution that securely validates both parties, in a deployable manner.


--
Garret Grajek is the COO and a co-founder of MultiFactor Corporation. He is a certified security engineer who has deployed 100s of security solutions while working for RSA, IBM, Cisco and others

Monday, July 7, 2008

SecureAuth® for Microsoft SharePoint (WSS 3.0) and MOSS

SecureAuth is the most Secure, Integrated Authentication Solution for Microsoft SharePoint

By Garret Grajek, CISSP
COO, MultiFactor Corp.

The most Secure, Integrated Authentication Solution for SharePoint

MultiFactor SecureAuth is the only tokenless, non-phishable authentication solution for Windows SharePoint Server (WSS 3.0) that strongly authenticates the end-user AND the server, in an easy-to-deploy manner. SecureAuth is ideal for the growing number of SharePoint deployments that host secure data, including:

• Financials
• Sensitive internal and partner documents
PCI/FFIEC/GLB regulated materials
• Government and Health Care information

The key to SecureAuth is its integration to the enterprise’s existing SharePoint installation and existing data store. (See Figure 1)

Figure 1 –SecureAuth® Integration into a Microsoft SharePoint Deployment (Click to enlarge)

Microsoft SharePoint is an Important Tool in Today’s Businesses

With Windows SharePoint Services 3.0, IT professionals can tailor or extend the Windows SharePoint Services foundation to create new, efficient, Web-based tools. Enterprises can:

  • Manage business documents more easily
  • Build rich, flexible, and scalable Web-based applications and Internet sites
  • Expand platform services and common framework for document management to offer enterprise-wide functionality for records management, search, workflows, portals, personalized sites, and more.

SecureAuth utilizes native SharePoint Forms-Based-Authentication

MultiFactor SecureAuth is designed to work with the data connector and authentication components native to the Microsoft SharePoint installation. Unique for an X.509v3 authentication product, SecureAuth® can utilize the native ASP.NET forms based authentication, thus greatly simplifying the integration for the SharePoint administrator. (See Figure 2).

Figure 2 - SecureAuth® utilizes native SharePoint Forms Authentication (FBA) (click to enlarge)


SecureAuth Provides the Complete Solution for Enterprises to Secure SharePoint

Using a combination of a web server module and web services, SecureAuth provides a turnkey solution to deliver an algorithmically proven method to thwart man-in-the-middle and phishing attacks (See Figure 1).


The SecureAuth solution features out-of-band self-registration that automatically delivers X.509 certificates seamlessly to end-users (See Figure 3). The solution eliminates the need for administrator resources to deploy software, install upgrades, or train end-users on complex, remote access procedures.


Figure 3 – SecureAuth has built-in, secure, out-of-band registration (click to enlarge)

SecureAuth Distinct Features:

  • Utilizes SharePoint native Windows Forms Authentication
  • SharePoint installation does NOT require code modification
  • Utilizes secure C-SSL authentication without modifying the existing web server
  • Full protection from man-in-the-middle, phishing attacks

--

Garret Grajek is the COO and a co-founder of MultiFactor Corporation. He is a certified security engineer who has deployed 100s of security solutions while working for RSA, IBM, Cisco and others.

Tuesday, July 1, 2008

SecureAuth solves X.509 Portability for Authentication

SecureAuth solves X.509 Authentication Mobility

By Garret Grajek, CISSP
COO, MultiFactor Corp.


A breakthrough in the SecureAuth authentication solution is what MultiFactor calls "PKI-Free" mobility of the X.509 v3 credential.

Classic PKI solutions require end-users to understand how to export, transport and import their authentication credentials. MultiFactor's unique approach is to provide simple self-registration process. (See steps 1-4 below).

MultiFactor solves this mobility issue, by:

  • Providing integrated secure mobile registration, via:
    • Telephony OTPs (One-Time-Passwords)
    • SMS/Text Messaging OTPs
    • E-Mail OTPs
  • Configurable Short and Long Term Certificates
    • Short Term:
      • 10 minutes to 48 hours
    • Long Term:
      • 2 days to 10 years
    • Mangeable from a simple web-GUI
      • No PKI-knowledge needed by administrator
      • NO C.A.'s required to be installed
  • Require "AAA+Certificate" authentication

Thus when a user utilizes a different machine (kiosk mode) the user simply re-registers and a new, valid credential is crated for that user. The user doe NOT need to:
  • Understand private/public key technology
  • Carry a device
  • Transport the credential
  • Import any credential or new device

The user self-registration process is self-explanatory and requires no help desk support. Here is a step-thru of the process: (click each image to enlarge)


















Image #1: User enters his/her UserID to begin Self-Registration Process
(Note: Site can be public or private - the user chooses for better security)


















Image #2: The user self-registers by selecting from a (enterprise-configurable) list of options



















Image #3: User enters One-Time-Registration Code via Java Keypad



















Image #4: User inputs his enterprise (AD, LDAP MS-SQL, etc) password

(Note: This is stored at the enterprise and not duplicated by SecureAuth)

















Image #5: SecureAuth registers the User's Browser
(Note: Browser can be FireFox, Internet Explorer or Safari)


















Image #6: Lastly the user is redirected back to the ASP.NET/SharePoint Application


The portability and ease-of-use for end users, make MultiFactor SecureAuth the ideal solution for:

--

Garret Grajek is the COO and a co-founder of MultiFactor Corporation. He is a certified security engineer who has deployed 100s of security solutions while working for RSA, IBM, Cisco and others.

Monday, June 23, 2008

MultiFactor SecureAuth® Delivers an Efficient, Inexpensive Solution for Enterprises to Become PCI Compliant for Remote Access

SecureAuth, Remote Access and PCI DSS Compliance

By Garret Grajek, CISSP
COO, MultiFactor Corp.

PCI DSS compliance has become a driving factor in the security of many organizations.

Not only has PCI become a requirement by the payment card industry, but it has become and example to all organizations of how practical security can be implemented and business continuity maintained. For many years the concern over the cost of implementing solutions securely has outweighed concern over the impact of failed security. Over the last few years, growing headline breaches have created an atmosphere of awareness of the damages a breach can cause to an organizations financial structure and reputation.

The key PCI DSS requirements for an authentication solution that proposes to aid in compliance are:

This article will address both of these key requirements - as they relate to remote access. Specifically for networks utilizing MultiFactor SecureAuth authentication for Cisco remote access.

Requirement 8: Assign a unique ID to each person with computer access

PCI DSS Requirement 8.1: Identify all users with a unique username before allowing them to access system components or cardholder data

SecureAuth for Cisco VPN authentication is designed for enterprises to easily meet the requirement of distributing individual user IDs to end-users. SecureAuth provides a methodology of user self-enrollment, to securely distribute PCI-compliant authentication credentials (X.509 credentials are PCI compliant, see PCI DSS Requirement 8.2).

PCI DSS Requirement 8.2: Employ authentication, in addition to unique identification for all users

SecureAuth for Cisco VPN creates a secure user credential which is mapped to an enterprise-mapped UserID. The SecureAuth credential is utilized by the Cisco VPN appliance to securely identify and authenticate the user. The UserID is in the SecureAuth credential presented to the Cisco VPN appliance upon attempted access by the end-user. (See Diagram #1)

Figure #1 – SecureAuth creates and utilizes a unique ID per user (click to enlarge)

PCI DSS Requirement 8.3: Implement two-factor authentication for remote access to the network by employees, administrators, and third parties

SecureAuth is a two-factor authentication solution that utilizes the SecureAuth X.509 credential and the enterprise-stored password.

SecureAuth for Cisco VPN authentication works in conjunction with the

Cisco appliance to authenticate a user with the securely delivered SecureAuth X.509 credentials. (The SecureAuth X.509 credential meets the 8.5 PCI DSS requirement for “individual certificate”) . The Cisco VPN is set to utilize “AAA + Certificate” authentication, thus enabling “true” 2-factor authentication: the user must have both the SecureAuth certificate and input the password associated with the user’s account. (See Figure #2)

Figure #2 – The Cisco VPN is set to utilize both “AAA + SecureAuth Certificate” authentication (click to enlarge)

SecureAuth differentiates itself in the marketplace by providing the easiest to deploy certificate solution to meet the 8.3 PCI DSS requirement.

PCI DSS Requirement 8.4: Encrypt all passwords during transmission and storage, on all system components

MultiFactor SecureAuth for Cisco VPN authentication does NOT have its own user credential and password datastore. MultiFactor utilizes the directory (AD, ADAM, LDAP) that the Cisco VPN is using natively. (See Figure #2)

This helps the enterprise meet PCI DSS Requirement #8.4. The enterprise does NOT have to create sync and encrypt a new set of data information.

Figure #3 – SecureAuth utilizes the native user store the enterprise has connected to the Cisco VPN. (click to enlarge)

PCI DSS Requirement 8.5: Ensure proper user authentication and password management for non-consumer users and administrators, on all system components

The MultiFactor SecureAuth appliance is administered via a secure GUI. All administrators are required to authenticate via strong 2-factor SecureAuth authentication. (Certificate plus UserID/password) . (See Figure #4)

Figure #4 – SecureAuth Administrators must uniquely authenticate utilize secure 2-factor X.509 authentication. (click to enlarge)

PCI DSS Requirement 8.5.1: Control addition, deletion, and modification of user IDs, credentials, and other identifier objects

SecureAuth administration accounts are uniquely created and associated with individual accounts, therefore configuration modifications are associated with specific administrators, as outlined in PCI DSS requirement 8.5.1.

PCI DSS Requirement 8.5.2: Verify user identity before performing password resets

SecureAuth requires end-users to perform a 2-factor authentication, “certificate + password” before they are allowed to modify their passwords. The PCI DSS 8.5.2 requirement is met by forcing users to strongly authenticate before modification of their password.

PCI DSS Requirement 8.5.3: Set first-time passwords to a unique value for each user and change immediately after first use

SecureAuth works in conjunction with the Cisco ASA to reset passwords on first usage. The Cisco ASA sees the “must change password” attribute set in the data store, and gives end-usesr the appropriate screens to change their passwords.

PCI DSS Requirement 8.5.4: Immediately revoke access for any terminated users

MultiFactor SecureAuth is unique in X.509 authentication solutions by providing instant revocation. By removing any terminated individuals on the data store of record, SecureAuth facilitates one-button revocation (See Figure #3)

SecureAuth for Cisco VPN Authentication requires the end-user to have both a valid SecureAuth certificate and authenticate with a valid password. (See figure #2). If the user is removed from the data store, Cisco VPN, utilizing SecureAuth authentication, will not grant access to that terminated user.

PCI DSS Requirement 8.5.5: Remove inactive accounts at least every 90 days

An enterprise can set the SecureAuth credential to be valid for 90 days or less, thereby forcing users to re-authenticate every 90 days.

PCI DSS Requirement 8.5.6: Enable accounts used by vendors for remote maintenance only during the time period needed

MultiFactor SecureAuth has a configurable certificate length that can be set in accordance to security and resource requirements. Enterprises are asked, by PCI DSS requirement 8.5.6, to create credentials that are time-configurable. SecureAuth offers this feature.

PCI DSS Requirement 8.5.7: Communicate password procedures and policies to all users who have access to cardholder data admin

MultiFactor SecureAuth is a user self-enrollment product that “walks an end-user through” an easy process, to obtain a secure credential. Additionally, the product utilizes the enterprise datastore and thus the password policies around these IDs.

PCI DSS Requirement 8.5.8: Do not use group, shared or generic accounts and password

SecureAuth for Cisco VPN authentication makes this requirement obtainable for enterprises. Users share accounts because of the pain in distributing unique authentication to individuals. SecurAuth’s unique self-enrollment for X.509 credentials makes compliance to this requirement possible.

PCI DSS Requirement 8.5.9: Change user password at least every 90 days

SecureAuth is an effective tool in meeting PCI DSS Requirement 8.5.9. The requirement requires an enterprise to change the password every 90 days. SecureAuth requires the end-user to change his or her security credential every 90 days (Or whatever time the enterprise determines). The SecureAuth authentication credential can be set from 1 hour to 10 years. SecureAuth enables an enterprise to meet the requirement today, and adjust accordingly, should the requirement change. (Figure #5)

Figure #5 - Enterprises can select the length of the certificate for their end-users. (Click to enlarge)

PCI DSS Requirement 8.5.10: Require a minimum password length of at least seven characters

SecureAuth utilizes the enterprise’s Datastore (See Figure #3); therefore, whatever configuration the enterprise sets on its data store, it will ultimately be enforced by the SecureAuth appliance during certificate enrollment. This same policy is also enforced by the Cisco VPN during “AAA + Certificate” Authentication (See Figure #2).

PCI DSS Requirement 8.5.11: Use passwords containing both numeric and alphabetic characters.

SecureAuth utilizes the enterprise’s Datastore (See Figure #3).; therefore, whatever configuration the enterprise sets on its data store, it will ultimately be enforced by the SecureAuth appliance during certificate enrollment. This same policy is also enforced by the Cisco VPN during “AAA + Certificate” Authentication (See Figure #2).

PCI DSS Requirement 8.5.12: Do not allow an individual to submit a new password that is the same as any of the last four passwords he or she has used.

SecureAuth utilizes the enterprise’s Datastore (See Figure #3). ); therefore, whatever configuration the enterprise sets on its data store, it will ultimately be enforced by the SecureAuth appliance during certificate enrollment (See Figure #2).

PCI DSS Requirement 8.5.13: Limit repeated access attempts by locking out the user ID after not more than six attempts

SecureAuth for Cisco VPN authentication has a lock-out feature for registration. The default for this configurable feature is (3) attempts.

PCI DSS Requirement 8.5.14: Set the lockout duration to thirty minutes or until administrator enables the user ID

In accordance with requirement 8.5.14, accounts can be locked out by configuring the data store from which SecureAuth is pulling data (See Figure #3).

PCI DSS Requirement 8.5.15: If a session has been idle for more than 15 minutes, require the user to re-enter the password to re-activate the terminal

The SecureAuth/Cisco VPN solution relies on the Cisco VPN settings for session duration and session idle enforcement. This setting is set in the Cisco VPN, to enforce session idle.

PCI DSS Requirement 8.5.16: Authenticate all access to any database containing cardholder data. This includes access applications, administrators, and all other users

SecureAuth does not have its own data store; therefore the effort that the enterprise puts into securing access to the “data store of record” can be used by SecureAuth; no additional work is needed, given that there is no additional data store. (See Figure #3)


--
Garret Grajek is the COO and a co-founder of MultiFactor Corporation. He is a certified security engineer who has deployed 100s of security solutions while working for RSA, IBM, Cisco and others.


Tuesday, June 17, 2008

SecureAuth Deploys Secure X.509 Authentication in Less Than a Day

MultiFactor SecureAuth uniquely enables enterprises to rapidly deploy non-phishable authentication.

By Garret Grajek, CISSP
COO, MultiFactor Corp.

SecureAuth for Microsoft and Federated Web Authentication is the non-phishable authentication solution that can be deployed in less than a day’s effort.

Enterprises are looking for authentication solutions that actually address the issues of phishing, identity-theft, man-in-the-middle and man-in-the-browser attacks. Unfortunately – solutions such as one-time-passwords and web-picture solutions simply do not address these problems, because the end-user is not authenticating the server. (See Figure #1)

Figure 1 – End Users are vulnerable to attacks where the end server “impersonates” the legitimate target

Security engineers know the solution to this dilemma. What needs to be enacted is a solution that:

  • Authenticates the end-user
  • And... Authenticates the server
The 2nd part of this equation has been the most difficult. A methodology that has been algorithmically proven to solve this “bi-lateral” authentication dilemma – is Public Key Infrastructure. Unfortunately – the infrastructure to deploy a working PKI infrastructure has been beyond daunting. (See Figure 2)

Figure 2 – Standard PKI Infrastructure is far too complicated for a standard enterprise to deploy

The SecureAuth solution is unique, in that it abstracts the complexities of a PKI and PKI registration from both the end user and the deploying enterprise. With SecureAuth an enterprise can deploy the SecureAuth solution into its infrastructure in less than a day. For VPN authentication the integration is simply a matter of integrating the SecureAuth appliance with the enterprise network device. (See MultiFactor SecureAuth for Cisco VPN Authentication.)

For web authentication, enterprises usually desire more customization than a drop in appliance. For this reason, SecureAuth offers SecureAuth for Microsoft Applications and SecureAuth for Federated Applications.

A key value and differentiator for the SecureAuth solution is its ability to be deployed rapidly into the existing infrastrure – in fact, the product is designed to be deployed in less than a days effort.

The product has (4) basic installation steps, all designed for web programmers to work with existing data and applications integration mechanisms.

The (4) steps to a MultiFactor SecureAuth integration are:

1. Install the SecureAuth Web MSI module on an IIS server
2. Connect SecureAuth with your datastore
3. Redirect your application to the SecureAuth URL
4. Link SecureAuth to MultiFactor’s Web Services

1. Install the MultiFactor SecureAuth MSI

This is a trivial step where the enterprise simply clicks through the SecureAuth MSI. The installation executable creates a SecureAuth virtual directory with the necessary account privileges to execute all of SecureAuth’s enterprise side functionalities, including data connector commands, certificate inspection and web service calls.

Estimated Deployment Time:

1-2 hours by Web Admin

Figure 3 – SecureAuth installs with a simple MSI executable

2. Connect SecureAuth with your DataStore

The SecureAuth solution utilizes .NET classes to connect to the existing datastore. SecureAuth can take advantage of the largest set of data connectors in the world: The .NET library of membership and profile classes. (See figure 4).

Estimated Deployment Time:
2-4 hours to Microsoft AD or MS/SQL by ASP.NET data programmer

Figure 4 – SecureAuth utilizes .NET Membership and Profile Classes

3. Redirect the application

The key to the SecureAuth solution is its ability to abstract the authentication process from your application. SecureAuth utilizes native .NET target/redirect authentication methodologies (documented in this Microsoft tech note, titled Forms Authentication Across Applications.)

The key to the solution is to utilize the forms section in target application's web.config to redirect an authenticated user.

SecureAuth is designed to integrate into standard ASP.NET infrastructure, thereby taking advantage of cross-application authentication. SecureAuth can be integrated on the web server that the application resides – or it can be hosted on a separate web server.

Estimated Deployment Time:
1-2 hours by ASP.NET programmer

4. Connect to MultiFactor Web Services

The SecureAuth license includes usage of seamless integration with MultiFactor’s integrated web services, including:

• SMS text messaging service
• Telephony (Speech-to-text) service
• X.509 v3 Certificate service

These services are hosted in MultiFactor Corporation’s high availability, co-located SAS 70 compliant facility. They become a part of the authentication process without requiring additional servers or software. (See figure #6)

Communication between the SecureAuth web component and the web services is established over a secure WSE 3.0 connection. The solution saves the enterprise thousands in maintenance and personnel fees, while providing the functionality needed for the most secure bi-lateral authentication available.

Estimated Deployment Time:

1-2 hours by ASP.NET programmer

Figure 5 – MultiFactor has hosted web services that work seamless with the SecureAuth solution.

Summary:

MultiFactor SecureAuth offers the only non-phishable, tokenless authentication solution that is able to be deployed in less than a day of work.

--
Garret Grajek is the COO and a co-founder of MultiFactor Corporation. He is a certified security engineer who has deployed 100s of security solutions while working for RSA, IBM, Cisco and others.


Tuesday, May 6, 2008

MultiFactor Facilitates Secure Cisco IPSec -> Cisco SSL VPN Migration

"SecureAuth® facilitates a secure transition from Cisco IPSec to SSL VPN"

By Garret Grajek, CISSP
COO, MultiFactor Corp.

One of the vexing issues facing enterprises today – is how to realize the administrative cost savings and increase user functionality of Cisco’s ASA SSL VPN offering. The user advantages of SSL VPN have been documented and discussed, and thus this article will not delve into the “why’s” of SSL VPN deployments.

The key issue, has been, how to implement a solution:

  1. That facilitates the transition TO a “SSL VPN” solution FROM a tradition IPSec-based solution.
  2. Ensures Secure User Authentication in the process – that is port a secure authentication for the present IPSec clients to the new SSL VPN base.
  3. Is deployable to both the enterprise and end user

MultiFactor SecureAuth® provides such a solution.

Step #1 – Original State, Non-X.509 Authentication for the Cisco IPSec VPN

Let’s start with the initial state, Diagram #1, IPSec VPN tunneling via the Cisco IPSec client and a Cisco IPSec supporting appliance (VPN 3000 Concentrator, PIX Firewall, Cisco Routers, etc).



Diagram #1 – Original State: An IPSec User VPN Deployment (Click to Enlarge)

In the original state, the user is deployed with a Cisco IPSec client and is utilizing authentication other than secure X.509 bilateral authentication.

In addition to the authentication being insecure – the organization is also at risk with a “Shared Authentication” key being utilized for encryption. This means that even if the organization is utilizing tokens (hard or soft) for authentication – the encryption is still a mere password – and thus vulnerable to attack. (See Diagram #2)





Diagram #2 - IPSec Client Configured to use a shared “Group Authentication” key (Click to Enlarge)


Step #2 – Secure X.509 Authentication/Encryption to Cisco IPSec via SecureAuth®


The next step in this scenario is to:
  1. Add a Cisco ASA and a MultiFactor SecureAuth appliance into the enterprise
  2. Utilize SecureAuth to enroll users with X.509 Certificates and a new user IPSec profile
  3. Enable X.509 Authentication on the Cisco IPSec appliance with the new certificates and user profiles. (See Diagram #3)



Diagram #3 – Utilizing the Cisco ASA/SecureAuth® solution to distribute X.509 Credentials and new IPSec Profiles. (Click to Enlarge)

In this step, the enterprise deploys new X.509 credentials and new IPSec user profiles via the MultiFactor SecureAuth appliance. One of the advantages here – is that the enterprise, at this time, does not need purchase a large Cisco ASA SSL VPN license – a simple 2 to 25 user license – will suffice. The enterprise simply utilizes the ASA for the deployment of SecureAuth X.509 credentials and new IPSec user profiles.

The MultiFactor SecureAuth® appliance is designed to plug into the enterprise in a matter of hours. The “rocket science” of Certificate creation, SMS Text Messages and Telephony OTPs is handled via secure and world-unique set of MultiFactor-hosted, WSE 3.0 Web Services.

In addition to the user now being secured via valid X.509, bilateral authentication – SecureAuth® also creates a new user profile for the user that utilizing the new X.509 credential. (See Diagram #4.)



Diagram #4 – New User profile deployed by SecureAuth via User-Self enrollment. Note the usage of the X.509 certificate for encryption. (Click to Enlarge)

It is important to note – that the end state of this step – is that the user is now conducting secure bilateral X.509 authentication AND encryption to the Cisco IPSec. This is a vast security improvement over both username/password and one-time-passwords.


Step #3 – SecureAuth X.509 Authentication to the Cisco ASA SSL VPN

In this step the enterprise switches from an IPSec deployment to a full SSL VPN deployment. The same URL that was utilized to deploy the SecureAuth X.509 credential – can now be utilized for the Cisco ASA SSL VPN connection. In addition, the same X.509 credential issued by SecureAuth in Step #2 above, is utilized for the Cisco ASA SSL VPN authentication. (See Diagram #5)

Of course, for the ASA SSL VPN roll-out in this step, a larger Cisco ASA SSL VPN license is needed to handle the concurrent connections. But the advantage is, now users no longer need to have the Cisco IPSec client and profiles on their machines to connect. And because the SSL VPN authentication is through SecureAuth’s secure X.509 registration system, which can utilize both SMS Text Messaging and Telephony OTPs for registration – the enterprise can be assured that the SSL VPN users are verified.

Diagram #5 – SecureAuth X.509 Authentication to the Cisco ASA SSL VPN (Click to Enlarge)

Summary:

Enterprises have been searching for a methodology to migrate from tradition IPSec VPNs to the nimbler and more-user friendly SSL VPN solutions. The SecureAuth authentication system provides this solution that is:

  • Secure
  • Deployable
  • And User and Enterprise “friendly”

--
Garret Grajek is the COO and a co-founder of MultiFactor Corporation. He is a certified security engineer who has deployed 100s of security solutions while working for RSA, IBM, Cisco and others.


Copyright 2008. MultiFactor Corporation. All Rights Reserved.