If you didn’t make it to San Francisco for the RSA 2010 show – let me give you a little clue – it was all about the cloud. 

And that was good for SecureAuth.   Real Good.   We  at MultiFactor have been about the cloud since 2006.

Image #1   -  SecureAuth has always leveraged the cloud for advanced webservices, such as 1) Certificate Authorities, 2) SMS Text Messages  and 3) Telephony OTP

SecureAuth always recognized that the cloud was the right way to execute functionalities that were either:

• Too Cumbersome
• Too Difficult
• Or Too expensive

To manage in house and/or to maintain.

This is why the SecureAuth design, from day (1), leveraged the cloud.    SecureAuth is the only solution that has always been able to deliver native X.509v3 certificates to enterprises without the burden/expense/complexity of installing a certificate server.    SecureAuth expanded on this concept by enabling enterprises to utilize MultiFactor hosted:

• Telephony OTP Servers
• SMS Text Messaging OTP Servers

The leveraging of these MultiFactor hosted solutions make the SecurAuth solution the easiest bilateral (client/server) authentication solution to install and manage.   It virtually takes all the implementation and maintenance out of the installation process.

Compare the SecureAuth solution (image #1) to the same solution if an enterprise tries to host it themselves,  ( image #2).

For the comparable hosted solution, the enterprise needs to install:

• Certificate Authorities
• Certificate Storage Devices
• Certificate Revocation Devices
• Telephony Servers
• SMS Servers

Image #2)   This image shows the servers required to install a comparable solution on site.   (1)  Certificate Authorities,  (2) Certificate Stores,  (3) Certificate Revocation List, (4) SMS OTP Severs, (5) Telephony OTP Servers

If it was just about ease of use, SecureAuth wouldn’t be the new choice of secure environments.  What the attendees of the RSA conference recognized was this simple fact:

“The cloud doesn’t relieve an organization of federal or enterprise regulations, such as FFIEC, NCUA, PCI DSS, HIPPA or HITECH”.

So…

Where does it leave an organization?

It leaves the organization with the delima of:

• How do I leverage the cloud to save cost on maintenenace/complexity
• Maintain or achieve regulatory compliance

The SecureAuth solution is the ONLY solution that manages this difficult balancing act.   SecureAuth allows the enterprise to retain the user data, securely stored internally , conduct the authentication on premise – and leverage the cloud for the complex functionality.

Because SecureAuth has an appliance that can conduct the authentication on premise, the SecureAuth appliance can perform (3) relevant functions that are important to regulatory compliance: (See image #3)

The “Hybrid” SecureAuth “Cloud” solution provides, locally:
1.   Local Authentication to the enterprise’s native datastore
2.   Local Authentication workflow, modifiable to resource and user group
3.   Local Logging and Auditing

Image #3)   SecureAuth conducts the Authentication on-premise, meeting germaine regulatory compliance measures.   (1) Local Data Store,  (2) Authentication Workflow, (3) Logging/Auditing

All of these functions are configurable on the locally-resident SecureAuth server.   A feature not possible for solutions that do not provide an on-site component. 

More importantly, all of these functions make SecureAuth the Right Cloud Choice.

—————

To find out more, contact us at sales@multifa.com / +1 949.777.6959.   Resellers are encouraged to contact channels@multifa.com / +1. 949.777.6970.

Please join us for the webinar securing Google Docs and Google Apps on Thursday, February 18th at 10am PST.

Google Docs is just a technology that makes sense.

•  Web Based Document Collaboration
•  Shared Versioning
•  On-Line Editing
•  Multi-OS Support
•  Multi-Browser Support

Image #1: Google Docs is a easy way to store and share documents.

Now all that is needed is a way to securely authenticate users who need access to the files.

The answer is SecureAuth for Google Docs.    (See Image #2)

Image #2 - SecureAuth conducts a browser based 2-Factor, 2-Way authentication before allowing access to Google Docs.

SecureAuth for Google Docs conducts an internet-secure 2-Factor authentication that insures:
•  The User is the user
•  The Authentication Server is Authentication server

The 2nd part is important and needs to be explained.

Most authentication solutions only validate the user.  They don’t validate that the user is sending his/her  credentials first to a phishing site.    (This is what is defined by Man-in-the-middle, DNS and Kaminsky attacks – See Image #3)  SecureAuth utilizes secure cryptographic authentication to insure a secure authentication has occurred.  (See whitepaper on SecureAuth authentication.)

Image #3 - SecureAuth conducts a bilateral, 2-Factor authentication to protect against phishing and MITM attacks

Just as importantly, SecureAuth utilizes the information that is stored in the enterprise datastore.   This means no synching of passwords and authentication credentials for the enterprise.   This is an enormous cost saving for the enterprise.

The combination of SecureAuth and Google Docs is amazingly powerful.   The combination of leveraging the  native datastore for user authentication, such as Active Directory, and then allowing all of these users up to 1GB of shared file store – on a shared resource, the Google Docs resource – is a no brainer.  (See Image #4)

Image #4 - SecureAuth utilizes the native datastore (Active Directory, etc) to conduct a secure user authenticaiton, before crypotographally passing the identity to Google Apps.

This saves enormous amount of work for setting up portals, servers and file shares.   Google Docs solves these issues.   And SecureAuth insures that the authentication is conducted securely, without the need to migrate and synchronize authentication credentials.

Please join us for the webinar securing Google Docs and Google Apps on Thursday, February 18th at 10am PST.

In the current edition of  CIO Update  www.cioupdate.com they outline their list of 2010’s ten hot trends. Interesting stuff for sure, I love to read year end reviews and prognostications for the coming year. No surprise to anyone cloud computing becomes real makes the list at #8 . I am quoted as predicting that the  issue of integrity of the application and the data will be solved by the big players in the cloud space. One thing my days at IBM taught me is that when the big boys focus on solving the problem, eventually they do. That still leaves the issue of the integrity of the users. The large cloud providers are leaving it to the enterprise to control access, they have to, there is no other effective way to do it.

The MultiFactor Corporation SecureAuth approach to this problem leverages the enterprise investment and expertise in great ID enforcement tools, Active Directory and LDAP. SecureAuth leverages these existing tools to securely control access to the application or resource in the cloud. If you are NOT ready to export your identities to the cloud but want to leverage the cost savings of moving  to the cloud then give us a call, SecureAuth does that and more for hundreds of companies and all for a few dollars per user  per year.

2010 looks like the year that the cloud goes enterprise.

Since the introduction of the MultiFactor’s 2-Factor SSO offering for Google Apps, I’ve been in several discussion with enterprises trying to get their minds around SaaS offerings and authentication.

The main issue, seems to be, trying to understand the integration between application hosting and user identification.

In old school application deployments, these (2) concepts are tightly couple   That is a developer, has to:

• Writes the application
• Deploys the service
• Attaches it to a local datastore
• Creates an authentication page, usually some forms-based page

Well, companies like Google  (and Salesforce.com) have greatly simplified this process, by “abstracting” the authentication.    This is done through federating the authentication.   (Here is the Google Apps model, a extremely well crafted SSO system, based on SAML.)

What Google, Salesforce and other realize is that enterprises have needs to authenticate multiple applications, and forcing a tight coupling between authentication and the application directly, is well cumbersome at best – and technically speaking:

Tying the authentication directly to the application:

• Forces users to re-sign in to every application
• Creates multiple points of enforcement
• Creates multiple points of logging
• Forces user data synchronization between applications

Remember, it’s all but impossible to synchronize passwords, especially once stored, because they are most commonly 1-way hashed.  (Even the very powerful Google Apps directory synchronization tool, can not synchronize Active Directory and Lotus Notes passwords.)

Thus, what enterprises need is a way to take advantage of these new federated models.    Most enterprises already have directory.   What is needed is:

• A system that can authenticate from this directory
• Have a configurable authentication that can meet relevant regulatory standards
  • PCI DSS, FFIEC, NCUA, HIPPA, etc
• Then federate the identity to the relevant target
  • SaaS Services  (Google Apps, Salesforce CRM, Force.com, etc)
  • Hosted applications
  

  Image #1: SecureAuth Federates the user utilizing the native directory (AD, etc)

Contact us at MultiFactor, and we’ll talk more.

A recent advisory from US-CERT has a lot of people who are thinking about deploying SSL VPN, or who have deployed SSL VPN, wondering if this is a good decision.  There are a lot of articles on the subject, and many of them will leave you feeling like this is an unsolvable problem.  But, there are a few (Dark Reading included) that do a good job of explaining exactly what the vulnerability is, and how to protect against it.

The core of the problem can be described quite simply.  When a client (browser) connects to an SSL VPN, and then connects to ‘protected’ resources (let’s say your intranet page), the browser does not ’see’ the connection to the intranet page.  The browser is connected to the SSL VPN, and the data to the internal ‘protected’ site is proxied through the SSL VPN.  All the browser ever sees is the SSL VPN, and all of the web sites the browser connects to ‘inside’ the SSL VPN look just like they are a part of it.

This is the problem.  And the solution lies in the problem.

OK, so what exactly is the problem here.  When the browser is connected to the SSL VPN a session is created, with cookies and other things set.  If a malicious web site behind the VPN asks for a cookie the browser will send it.  After all, the browser is not connected to the malicious web site, it is connected to the VPN.

The solution can be stated simply.  Don’t let browsers connected to your SSL VPN connect to malicious web sites.

That may sound a little trite, but SSL VPNs have many mechanisms to help you prevent this kind of attack.  Web ACLs can be used to only allow traffic to specific resources.  Turn off the ‘address bar’ in the SSL VPN portal so that connected users cannot just browse around.  Those are two simple steps you can take to limit the exposure of your SSL VPN to this kind of attack.

The thing is, this vulnerability is not really build in to the SSL VPN itself, but is dependent on how the SSL VPN is deployed.  There is definitely a threat here, but this is exposure that can be mitigated with a well configured SSL VPN.

In recent days I have been explaining both internally and externally SecureAuth inate ability to solve what has been, pretty difficult SSO problems.

Namely, how to solve authentication and identity between servers that are both internal and externally located.

The SecureAuth solution, that the team and I designed, solves this issue.    The solution, from its beginning back in 2005, was formulated in a way to authenticate disparate web servers, whether they are externally or internally hosted.   This is because, after SecureAuth conducts a 2-Factor, 2-way authentication – SecureAuth is designed to create both intranet and extranet session credentials.

It just took the world a little time to catch up on being able to consume these external session credentials.

Google Apps and Salesforce have shown the world that externally hosted applications are practical and in may cases, provide a cost and functionality improvement over their internally based solutions.     Both these service providers are able to consume federated assertions, SAML to be specific.

But as we have seen in discussion with enterprises, especially after the recent Salesforce Dreamforce show – enterprises are looking for solutions that can provide a SSO experience to the user between these extranet (Salesforce, Google) and intranet (SharePoint, OWA, WebSphere , Oracle 11g, etc) solutions.

SecureAuth is this solution that bridges these solutions.

The solution can also be configured to translate IDs across applications and across the “cloud”.

SecureAuth is able to do this because (See figure #1) below:

1. SecureAuth redirects the authentication to the SecureAuth servers

• Target applications do not need to be in same DNS domain.

2.  SecureAuth then looks for a SecureAuth authentication token:

• The SecureAuth token can be configured for any identity attribute that resides in the datastore

3.   If the SecureAuth token has been created, SecureAuth is able to conduct an identity
translation to the target resource:

• The identity can be the “logon ID” or an secondary ID that SecureAuth draws from the datastore that the application recognizes.

With this design, SecureAuth is able to create a SSO session between hosted and cloud based applications.

Figure #1 – SecureAuth’s design enables 2-Factor SSO between hosted and cloud applications.

Please contact us at 949.777.6959 or sales@multifa.com.

Allen Miner, a member of the board of directors of Saleforce.com Asia, founder of Oracle Japan and founder/director of the SunBridge corporation, came by the MultiFactor booth a couple of times during dreamforce.  (Below pictured with Tom Stewart, CFO of MultiFactor.)

Already aware of SecureAuth’s Appexchange offering,  Allen came by see live demos and discuss integrations and current marketing plans.   In addition, Allen also led a  informative discussion to visiting Japanese attendees from Osaka representing Kanematsu Electronics – in Japanese.

Tom Stewart, CFO of MultiFactor, discusses SecureAuth with Allen Miner, Member of the Board Directors for Salesforce.com Asia.

SecureAuth 2-Factor SSO Story Makes Dreamforce fun for Team

The MultiFactor team just completed the Salesforce Dreamforce Show in San Francisco.   And, well to be frank, it was fun.   A word not used much these days, but it actually was.

• It was fun because there was tons of energy at the show.
• It was fun because the attendees had projects, and wanted to talk about them
• It was fun because the solution we have designed and perfected met the requirements

It was fun, well, because it was why we all got into this business in the first place – to design and implement solutions that makes sense.

Here is a quick synopsis, of what mostly was discussed at the show.

Enterprises want for good reason to move their applications to the Force.com platform.   (I attended many events and training sessions, the Apex and Visualforce platform are robust and gives coders an amazing amount of pre-built functionalities that expedite the concept->product . )

But many of the enterprises have (4) items that made our SecureAuth booth a busy place.

• Enterprises do not want to replicate password/authentication information

• Enterprises want to implement deployable 2-factor authentication

• Enterprises want to have local access to authentication logs and workflow.

• Enterprise want to offer SSO to their users between (A) Hosted Applications and (B) Force.com and Salesforce CRM solutions

The SecureAuth solution, in conjunction with the native Salesforce (SAML-supported) SSO provides all of the above.   (See figure #1 below.)

Figure #1: SecureAuth enables enterprises to leverage their current datastore, item (2), for SSO into Salesforce.

• In SecureAuth for Salesforce, the SecureAuth appliance (1) is deployed into the enterprise and connects it to the native datastore (2) – usually Active Directory, but this can be be any other LDAP or SQL datastore.
• Browser-based end users (3), can now  access  Salesforce applications (4) via SecureAuth’s secure 2-way (client-authentication) authentication (5a).
• Once SecureAuth conducts this authentication via a myriad of methods  (SMS, Telephony, e-mail, PIN, X.509 and others), the user is redirected to Saleforce (4) via a secure SAML assertion with the user’s Salesforce ID (5b).
• The user is now securely logged on directly to the Salesforce/Force.com application (6) and interacts directly with the Salesforce/Force.com  application for the rest of the session.
• Subsequently, if the enterprise chooses to configure SecureAuth for internal applications (7), the user can achieve single-sign-on (SSO) via SecureAuth.

This SSO between the hosted applications (7) and the Force.com applications (4) was one of the highly discussed part of the DreamForce show.

Which well made for good fun!

(SecureAuth is a certified and registered AppExchange Solution.)

Please contact us at 949.777.6959 or sales@multifa.com.

I have to say that I was overwhelmed by the response to the SecureAuth solution at the salesforce.com Dreamforce 09 conference this week.  We spoke to more companies that really understand the importance of great authentication and single sign on than any “IT security” trade show we have been to.   Salesforce customers are passionate about their IT and doing things right and efficiently.  Once they learn that we do VPN, in-house applications AND cloud applications, we have a real friend.  Read for yourself http://bit.ly/47ibi4 or please just give MultiFactor a call +1 (949) 777-6959 to see how easy it is.  

These guys love cloud security

TheMLS partners with MultiFactor to offer “Secure Portal Solutions“.

TheMLS currently utilizes SeccureAuth portal authentication for access to their MLS portal.

Customers are thrilled.   As can Laura, a realtor out of Los Angeles can testify.    We caught Laura at the National Associations of Realtors show in San Diego this weekend.