That you said you were interested in solving:
As was stated in this article:
“RSA CONFERENCE 2012 — San Francisco, Calif. – The way browsers perform SSL certificate-revocation checking is so fundamentally flawed, that some browser vendors have turned it off altogether”
What was reviewed at the conference was the established system that determines how a certificate issued to a user is deemed invalid. The current mechanisms are:
As we stated back in 2010 in this whitepaper: SecureAuth Solves X.509v3 Authentication and Certificate Revocation:
-
PKI is Difficult to Deploy – SecureAuth is Not
-
PKI is Difficult to Maintain – SecureAuth is Not
-
PKI is Difficult to Scale – SecureAuth is Not
-
PKI is Difficult for Application Integration – SecureAuth is NOT
-
PKI is Difficult for End-Users to Obtain Credentials – SecureAuth is NOT
The white paper spans 20 pages of detail, so I will summarize the key points below, for the quick version.
Certificate revocation is how to render the identity of an X.509 certificate null and void. In other words, “Fine you have a certificate, but I no longer trust it for the sake of this transaction.”
- “PKI is the only technology in the world that requires:
- A list of all valid credentials
- A list of all invalid credentials”
It is this 2nd list, the “anti-database,” that has made PKI all but impossible to deploy and maintain.
It’s easy to sit here, in 2012, and say, PKI w/ it’s CRLs and OCSPs is stupid. Well, it is stupid. Actually it is REALLY stupid in the context of 2012.
Seriously… try this. Go to your e-mail admin and tell him..
“I want you to check EVERY invalid user before you allow him access to his e-mail. E.G. check everyone
you ever suspended/deleted from your Active Directory and/or Google Directory – before giving him
access to e-mail”.
The admin would just say, uuhhhh, you are stupid. But this is exactly what “traditional PKI” does. (See Image #1)
Image #1: CRL/OCSP certificate revocation has always been hard. Wwith SaaS services, as Google states, it has become practically impossanible.
Maintaining “anti-database” is what you are trying to do with traditional “certificate revocation”. But why is this system so backward?
The dates of these “anti-database” technologies is illuminating:
o CRL – Certificate Revocation List (RFC 1422) 1993
o OCSCP – Online Certificate Status Protocol (RFC 2560) 1999
So Google is right to say that CRLs and OCSPs have no place in 2012. GOOGLE WAS NOT EVEN INVENTED when the RFC for CRLs was published!
Having worked for RSA back in the 1990′s – let me explain their (dated) reasoning:
Directories (let alone the Google cloud-based IdP) were NOT widespread. Active Directory was not even made available by Microsoft till 2000. Thus what the certificate people said is:
- I will issue certificate to users
- When I want to revoke a cert – I will add the specific serial number to a list of revoked certs
- And every time I want to validate the cert
- I will check against these list
OK – but anyone who has done ANY work in directories and, well, web/SaaS programming, would just redesign this workflow to have the revocation occure out of the central datastore. (AD, LDAP, Google store, etc.)
In fact, a real improvement would be…
- Allow the enterprise to choose their primary datastore
- Any datastore:
- AD, LDAP, ODBC, SQL
- Google, etc
- Utilize existing datastore attributes
- No LDIF’s, No schema changes
- Enact the revocation via a simple “generic” process
- E.G. just set a “Revocation Time” to current date.
This is what SecureAuth does.
Brief Detail:
The whole theory behind this is that every cert has (2) bits of time-stamped info:
- Issue Date
- Expiration Date
SecureAuth creating a system to:
- Issue the certificates
- And Validate the certificate
Please pay attention to this 2nd part, Google. (And anyone else interested in, once and for all, resolving the “revocation” problem.)
Because SecureAuth validates the certificate, SecureAuth can then check a datastore (any datastore – on premise or cloud based) – for the revocation time. (See image #2). Thus SecureAuth does NOT have to rely on (outdated CRLs and OCSPs!)
Image #2- Un-authenticated users (A) get redirected from SaaS and On-premise resources to SecureAuth. SecureAuth (B) conducts the authentication (and Cert Validation) and then asserts a “positive assertion” back to on-premise and SaaS (Google) resources (C). No CRLs or OCSPs are needed.
Of course, as stated, you can download this whitepaper , or you can just contact us. we will tell you more! (And of course, we got patents filed on this dating back to 2007!)
All the best!
–
Garret Grajek is CTO and a co-founder of SecureAuth. SecureAuth is a single appliance solution that delivers configurable 2-Factor and SSO authentication for Web, VPN and SaaS based solutions.
Categories
Blog |
Tags
|
Author
Garret |
|
Greetings:
The word’s out – SecureAuth has done authentication the right way. (Amylin, Carnegie Mellon, Carnival Cruise Lines, Carolinas Health Care, Chevron, City of Beverly Hills, Diebold Inc. Dish Networks – just follow the link.)
And we are not apologizing. (See image #2)
Image #1: Available SecureAuth engineers – who represent the greater SecureAuth community – who are proud of building a better authentication/identity product.
When Craig Lund and I started this company in the winter of 2005 – we set forth to correct some of the mistakes in the authentication business. I personally have been involved in hundreds of authentication and identity projects as an engineer at Security Dynamics, RSA, Netegrity, IBM and Cisco.
When we designed SecureAuth, we weren’t going to repeat the mistakes of:
Image #2: SecureAuth solves the failed designs of previous Authentication Systems.
Authentication Flexibility:
The problem with previous solution – is they were either:
- Single Functionality Authentication System (RSA SecurID)
- Cobbled Authenticaiton Systems (SafeNet)
There has never been a single authentication authentication platform built in with a:
- WebServices to high-availability SMS, Telephony, PKI systems
- Full support for both out-of-band and other auth methods (X.509, CAC/PIV, Yubikey)
- Utilization of local datastore information (KBA/KBQ, Help Desk)
Authentication Integration:
Well, lets be frank – this is where SecureAuth wins. Hands down. Why? Because the other products are just kludgy pure-play authentication technology where no programmer ever stood up in the meeting and say, “Excuse me – this crap is undeployable”. (Uhm, I know that – because I was that engineer @ RSA an IBM.)
SecureAuth is the only V.A.S. (Variable Authentication Server) with a built-in:
- Application Server
- Web Server
- Web Service Authentication Interface
That’s why SecureAuth always wins in P.O.C.s SecureAuth can actually execute on the functionality that, well, the architecture team is trying to execute on. And fact of the matter is – we probably already have and its been incorporate into our current release.
Try saying that with your token-based API system.
SAML / SaaS Integration
People – SAML is not a mystery. It’s just an XML file, that needs to be cryptographically signed by a X.509 private key. Oh – and you need send the right identity to the relying party – that may (but pbly not) match the ID that the user authenticated with.
Oh – and you should probably give some flexibility on how the user is authenticated – and provide some SSO for other SaaS/Web apps and your Active Directory domain.
Oh – and you should hook up the authentication to your SIEM system.
Lastly – gives the user some functional portal – that they could use both on the computer – and their mobile phone and tablet.
Got it? Good.
No one else does – except SecureAuth
.
PKI
If you are still defending PKI in all is achronistic dysfunctionality – then well you still can’t figure out why Colleen dropped you in high school for the guy with the better car and party circle. (I mean – you did have your Gremlin polished and you had planned to meet “Skeeter” and “Catch” at the bowling alley.)
Bottom line:
Any technology that says you must track all the IDs that are invalid – is well stupid. Seriously, people – that is just stupid.
Grow up – sell the Gremlin and read this.
Mobile
This last one really baffles me. How the “Traditional” IT industry has responded to the BRILLIANT, GROUNDBREAKING beauty of the mobile explosion: They say, “I know – we’ll take all these wonderful mobile devices and turn them into 1960-era CRTs with these undeployable MDM solutions.”
Seriously people – adjust to freedom.
The wall fell in 1989. (Look it up – it’s documented – there this whole Reagan/Gorbachev thing – its a good read – or late night History channel watching).
It’s a BYOD world. If your company has a policy that you must own everything on the mobile device – wake up – they laid off 30% of the staff in the last recession – the people accessing the resource are all contractors, suppliers, temporary employees – etc.
You don’t have a right to tell people what they run on their devices.
You don’t. The future is dumb devices and cloud storage – so seriously – give up the “control freak stuff”.
The wall fall. So will the MDM effort. Adjust.
All the best.
–
Garret Grajek is CTO and a co-founder of SecureAuth. SecureAuth is a single appliance solution that delivers configurable 2-Factor and SSO authentication for Web, VPN and SaaS based solutions.
Categories
Blog |
Tags
|
Author
Garret |
|
One of the key SecureAuth message in 2012 is how enterprises need to adjust to a BYOD. And that does not mean just purchases a mechanism (MDM) or other to manage personal and corporate mobile devices.
Remember: The Devices may be new each quarter – but the regulations (like PCI DSS, NCUA, FFIEC, HIPAA/HITECH) are not.
Which is why SecureAuth is so line with the 451 Group’s report on mobility and app control:
The report has some very key observations, including:
The fundamental issue that IT departments and security teams face with BYOD (bring your own device) is that they cannot stand in the way of mobile adoption – both because of user preferences, and because there are obvious productivity gains for the organizations. However, mobile adoption generates two major issues: there is no direct control over the device by IT or security, and traditional enforcement of ondevice data use andapplications can’t be readily extended to employee devices accessing corporate resources.
An astute problem statement – of course – but is also relevant is the the accurate assessment of SecureAuth in the 2012 BYOD market.
Which make SecureAuth had already launched a set of capabilities for supporting SSO from Apple iOS and Google Android mobile devices (building on existing mobile OS support), as well as automated enrollment and management of X.509 deviceside certificates. Now the company has looked to extendthose capabilities to bridge iOS device side certificates with Microsoft infrastructure through its ‘funnel.’…
The use case is significant not just because it illustrates the strengths of SecureAuth’s platform. It also allows the company to position itself as asubstitute for mobile device management for smartphones and mobile tablets, as well as establish a strategic footprint as enterprises migrate from Exchange to GoogleApps.
This really is the world in 2012.
It’s not just the issuing of mobile devices that enterprises need to worry about – it’s the whole new conundrum of how to provide access to corporate resources – that, well – aren’t at the corporation. E.G. the apps themselves may be in the cloud.
So now we have (2) intangibles in 2012 – that are no longer solved by the “crunchy shell” network topographies of the pre-cloud age, we have:
(A) – Mobile Devices – not part of a corporate domain
(B) – Cloud Apps – not part of a corporate domain
(Please see image #1 below.)
Image #1: SecureAuth helps enterprises with the (2) major technical advances in 2012 – (A) Mobile Devices and (B) Cloud Apps.
Learn more about SecureAuth BYOD capabilities from additional SecureAuth reading and/or our latest BYOD Webinar. Of course, you can just contact us – and we will tell you more!
–
Garret Grajek is CTO and a co-founder of SecureAuth. SecureAuth is a single appliance solution that delivers configurable 2-Factor and SSO authentication for Web, VPN and SaaS based solutions.
Categories
Blog |
Tags
|
Author
Garret |
|
A year ago, March 18th, 2011 – RSA announced that a hack occured on their facilities that compromised the security of the RSA SecurID tokens. RSA’s executive chairman, Art Coviello released an open letter which confirmed the breach of their security systems and revealed that the breach had been an attack on the SecurID authentication system, deployed at over 25,000 customers.
A year later: Where Are We Now?
Seriously. Many of the articles after the hack revealed what security types had already been saying for years (Bruce Schneier in lead) – the basic underlying premise of sending OTP codes for 2-Factor authentication is susceptible to simple Internet attacks, including Man-in-the-Middle attacks.
(After the attack – I even demonstrated to an assembled team of one of the largest security firms in America -FishNet Security- how easy it is to set up a Man-In-The-Middle (MITM) attack on RSA SecurID tokens. FishNet was so impressed by what was shown, they began to not only sell SecureAuth, but also use SecureAuth as a more secure and easier to use way of providing 2-factor authentication for their own remote access).
SecurID Does NOT Protect Against Modern Internet Attacks
SecureID, and other OTP token methods, do NOT protect against modern hacker mechanisms such as man-in-the-middle attacks. Modern hackers know that methods such as hard tokens (and OTP mechanisms like phone delivery systems) are just sending identity information without validating the authenticity of the relying party into which users are trying to access (EG. – unless a person can guarantee that they are sending the OTP, the password or even a RETINA scan to the correct server that’s supposed to be receiving this information, that user might as well be handing the hacker his username/password, because simply using SecurID or any OTP-type of security will not protect him from a hacker taking his credentials from his web session).
What has been known to elevate internet security is a system that is capable of:
- Authenticating the veracity of the user
- Authenticating the veracity of the authentication party
Image #2: RSA SecurID , and all the hard and soft token solutions, never addressed the issue of bilateral authentication – or who am I passing my credentials to?
So What Does Solve the Client-Internet-Server Security Issue?
The industry has known how to solve the client-server authentication issue since the
80′s with PKI ( e.g. the exchanging of key information for the purpose of bilateral (client/server) authentication). With bilateral authentication, a user is assured of the veracity of the authentication party with a cryptographically non-refutable request/response sequence between the client and the server. The actual exchange is handled under the precept of cryptographic hexadecimal numbers stored as public and private keys.
And…
The systems were never implemented in mass markets because they were too difficult to scale. I know this for a fact because Iworked for RSA in the 90′s. When we were explained how PKI worked and why it was imperative for secure Internet commerce, the “too difficult” response was always cited as the reason why PKI was not accepted in the mass market.
It was a simple business decision. When things are too costly, Industry looks for alternative ways that are not as good. In response, the industry bought technology like SecurID when companies wanted to “be secure” – or at least show they were trying to be secure. (Like the public facing financial internet site that uses RSA SecureID – that we showed can be hacked by a simple MITM proxy.)
And what has happened?
Well, now the world is nothing but client-server authentication across the internet, most of which is done over public channels (e.g. a browser to a public facing web server). The move to the cloud, intelligent as it may be for cost-savings and efficiency, has greatly advanced this type of communication.
…And the hackers – are having a field day. (See image #3)
Image #3: Hackers have taken advantage of the fact that most authentication (UserID/Password, SecurID and other tokens mechanisms) are unilateral – and thus susceptible to Man-in-the-middle (MITM) attacks.
So What Can Be Done?
The problem remains the same, regardless of what new pieces we add to the puzzle: (In image #2, Mobile devices on the left side and “Cloud resources” on the right hand side). We need a mechanism to ensure the veracity of both:
-
The Client (Desktop, Mobile, Tablet)
-
The Server (Enterprise, Cloud, SaaS, PaaS)
And now more than ever, a browser-based solution.
The SecureAuth solution solves this authentication problem by:
- Automatically issuing a cryptographic credential to the user
- Authenticating by the SecureAuth Solution
- On Premise or
- In the Cloud
- Passing the identity
- To an on-premise resource (web, VPN)
- Cloud Resource (Google, Salesforce, Workday, SuccessFactors, Amazon, etc)
SecureAuth: Bi-Lateral Authentication that Solves MITM Attacks
Why this is more relevant than ever in 2012?
The world is moving to a pure browser-server world, with the browser being the client of choice regardless of the device being used for access. (Google is adding over 5,000 customers A DAY in 2012 on its browser-pure Google Apps cloud system.)
The world is in need of a new authentication system. A system that can deliver strong authentication that meets today’s regulations (PCI DSS, NCUA, FFIEC, HIPAA/HITECH) despite the fact that users are not necessarily part of any domain, can request access from any location, can use any device, and will access not just internal enterprise resources, but also cloud-based resources.
The world needs SecureAuth.
Contact us – and we will tell you more!
Categories
Blog |
Tags
|
Author
Garret |
|
Having put together over 100 webinars for SecureAuth – I also take the time to listen to other firms webinars. (And yes – I am e-mailing and IM’ing through theirs – like others do to mine – all’s fair.)
What’s relevant about the other product webinars I listen to – is NOT what is included – but what is omitted.
There is not question that consolidating your SaaS/Web access to a single portal – is the right answer. And it’s also the right answer to consolidate access to an ID that your users already know. (E.G. “Federated the identity from your Active Directory – or other known idenity.)
But what is OFTEN omitted – is, well, how do you do all that boring stuff around the password??? E.G.:
- User Self Password Reset
- 2-Factor Self-Password Reset that meets Regulatory Compliance
- User Password Lock-Out and Unlock
- Password Synch to Cloud like Google
- Enforcing Password Strength across
- On-Premise Web Applications
- Cloud Applications
Image #1: SecureAuth becomes the centralized 2-Factor Password Mechanism for your user data resource (AD, LDAP, SQL, etc).
The SecureAuth solution is the 2-Factor “Instant IdP” that allows you to convert your present user store into a fully functional IdP for the modern enterprise deployment of applications. (On-premise and SaaS web deployments.)
Enterprises today, need to provide:
Check out the full SecureAuth Password Functionalities here. Contact us – and we will tell you more!
–
Garret Grajek is CTO and a co-founder of SecureAuth. SecureAuth is a single appliance solution that delivers configurable 2-Factor and SSO authentication for Web, VPN and SaaS based solutions.
Categories
Blog |
Tags
|
Author
Garret |
|
Had the pleasure of F5′s (wonderful) Peter Silva come by the SecureAuth booth @ RSA and record our BYOD (“Bring Your Own Device”) Story.
The SecureAuth BYOD story is what the IT world is clammoring for:
- Agnostic device 2-Factor authentication
- Full App access integration
As been will be detailed in our upcoming webinar with F5 (F5 APM and SecureAuth and FishNet Webinar – BYOD security for Web and Cloud Apps) – we will point out the importance of allowing any device access to your apps.
And this is what came out during the RSA show. The attendees: IT directors, security engineers, consultants – where looking for solutions on how to:
- Maintain their Access Control guidances
- But still allow access to the new devices
- iOS, Android, BlackBerry, etc
This is the SecureAuth story – and specifically the SecureAuth/F5 APM story. Contact us – and we will tell you more!
F5 APM and SecureAuth and FishNet Webinar – BYOD security for Web and Cloud Apps
Thursday, March 22nd, 10am PST
–
Garret Grajek is CTO and a co-founder of SecureAuth. SecureAuth is a single appliance solution that delivers configurable 2-Factor and SSO authentication for Web, VPN and SaaS based solutions.
Categories
Blog |
Tags
|
Author
Garret |
|
-
Authentication
-
Authorization
-
Auditing
But the 3 A’s were designed for the 1990′s – e.g. – when all the resources were internal – and a gateway device was placed in front of these resouces for 1-stop authentication.
The standard for AAA authentication was the RADIUS protocol. RADIUS allowed the gateways to generically pass collected authenitcation information to the RADIUS-compliant auth server. (See Image #1.)
Image #1: Traditional AAA authentication, RADIUS, collects static information from the gateway and then passes the creds via UDP to the RADIUS Server.
Problems with standard AAA (RADIUS) authentication:
1. Limits enterprises to supported workflow and static data content
- No flexibility in workflow
- Restricts enterprise to out-dated authentication methods (SecurID, tokens, etc.)
2. No support for new Cloud Applications
- No way to pass identity to SaaS / PaaS providers
- SaaS providers do NOT support RADIUS (Seem image #2)
Image #2: Standard AAA authentication, e.g. RADIUS, provides no support for the exploding world of cloud apps.
The 4th “A” – Identity “Assertion”
In the modern world – there are (4) “A’s” for secure Authentication:
- Authentication
- Authorization
- Auditing
- Assertion (Identity Assertion)
This is WHAT IS MISSING with the traditional (AAA) RADIUS authentication – there is NO WAY to ASSERT the identity to outside parties. (RADIUS is just a static mechanism to pass/query credential information).
What is needed:
1. A flexible Authentication solution
- That Supports multiple authentication methods
- Whatever auth method enterprise chooses
2. That “Asserts” the identity…
A mechanism to tell a relying party the ID
- Securely
- Repeatably
- Without APIs
This is EXACTLY what the Securauth product is, a product that meets the (4) of authentication:
Image #3: SecureAuth provides (1) Authentication, (2) Authorization, (3) Audit and (4) Assertion.
It is this assertion part of the authentication – that truely differents SecureAuth. SecureAuth takes on the last part of the authenticaiton – the “Assertion of the IDentity” to the relying party (Web, VPN, Cloud.) This is not left as an API excercise or a complicated coding project – but built into the SecureAuth product. (See Image #4)
Image #4: SecureAuth is the only solution that combines the required 4 AAAA’s of authentication.
—
Garret Grajek is CTO and a co-founder of
SecureAuth. SecureAuth is a single appliance solution that delivers configurable 2-Factor and SSO authentication for Web, VPN and SaaS based solutions.
Categories
Blog |
Tags
|
Author
Garret |
|
Please come by the Secureauth booth @ the RSA Conference – Moscone Center, Booth #217
–
IT admins face the explosion of apps, specifically cloud apps (like Google, Salesforce, Concur, Workday, SuccessFactors) – and need a way to manage these products.
And by manage – i mean:
- Conduct Authentication
- Allow Single-Sign-On (web user experience)
- Utilize a single account (enterprise data store)
- Log the authentication
Image #1: SecureAuth centrally manages authentication and identities for users – including 2-Factor, SSO, federation and logging.
Centralized Management
SecureAuth is the revolutionary all-purpose tool for the enterprise that centralizing the functionality for several key IT domains:
- Access Control for Network Access
- Access Control for Web Access
- Access Control for Cloud Apps
- 2-Factor AuthenticationWeb/SaaS Portal
- Identity Management of Enterprise UsersLogging of authentication
SecureAuth is able to become this centralized management tool – because of its powerful multi-tenanted architecture that allows it to create 100 distinct policies to manage the various enterprise resources.
Access Control for Web Access:
Admins can consolidate the access controls of their web resources – in a single platform, SEcureAuth. Web resources can include J2EE, .NET, Microsoft Sharepoint, IBM WebLogic, Oracle WebSphere and other platforms – all which can be collated into a single authentication portal.
Images #2: SecureAuth centrally authenticates on-premise Web Applications.
Access Control for Network Access:
Admins can centralize authentication access control for their various network VPN and gateway devices in a single, consolidated tool – creating different for access policies for different users utilizing similar or differentiating authentication mechanisms all supported from the same SecureAuth platform.
Images #3: SecureAuth centrally authenticates on-premise VPN/Gateway devices.
Access Control for Cloud Apps:
SecureAuth can also collate an ever growing number of SaaS solutions solutions and provide access to enterprise users coming from the intranet and extranet. SecureAuth can provide centralized access control to these apps, including managing the authentication, the workflow and the logging. The key to the secureAuth solution is that it utilize on-premise IDs (Active Directory) for acces to these cloud Apps.
Image #4: SecureAuth centrally authenticates and provides SSO for Cloud Applications.
2-Factor Authentication
SecureAuth centrally allows enterprise to control 2-Factor authentication to the VPN, WEb, Cloud Apps. A unique SecuerAUth realm can be created for each resource, with a differentiating authenticaiton policiy. SecureAuth authentication can be configured to utilize SMS, Telephony, E-Mail, KBA/KBQ, Help Desk, Password and X.509v3 Certificates.
Image #5: SecureAuth is a VASP (a “Variable Authentication Service Platform”). SecureAuth supports X.509, SMS, Telephony, E-mail OTP, KBA/KBQ (Knowledge-Based-Questions), Static PIN, Yubikey and Password.
Web/SaaS Portal:
The enterprise portal can be hosted on the SecureAuth solution. All access controls, including 2-Factor are built into the portal. In addition, the web single-sign-on between the on-premise web applications and SaaS applications is all constructed and managed throught the SecureAuth administration tool. SecureAuth can also integrate this web/SaaS sso to pre-existing portals.
Image #6: SecureAuth is a revolutionary 2-Factor, portal – built-in with full authentication and SSO between internally and external apps. Fully compatible for all devices.
Identity Management for Enterprise Users:
SecureAuth is able to provide centralized identity managment tools for both internal and external users. In addition, these tools can be delegated to both users and enterprise admins – according to pre-existing user groups. These tools include:
- Identity Provisioning
- Profile Enrollment (1st time use)
- 2-Factor password Reset
- User Profile Management
- 2-Factor Password Reset
- Administration Management of User Accounts
All of these policies are accessible from user internally and external located – but enforcement of the policies can all be sent to one of more centralized datastores.
Image #7: SecureAuth has built-in identity Management: User Profile On-Boarding, 2-Factor Password Reset, User Self-Management and Help Desk User Management.
Logging of Authentication:
SecureAuth provides the enterprise a centralized facility to log all access to SecureAuth protected resources – regardless if the resources are VPN, Web or Cloud resources. SecureAuth can send the “who, what, where and when” of logging in the format the enterprise requires – both text and syslog format. SecureAuth can send the syslog files to an on-premise SIEM (Syslog Information Event Management) server – or an office premise SIEM. Secureauth also supports a GUI interface to cloud SIEM, Loggly.
Image #8: SecureAuth provides full logging of all authentication – be it VPN, Web or SaaS.
Categories
Blog |
Tags
|
Author
Garret |
|
‘Tis the Season…
Come Feb 27th to March 2nd, thousands of us – including myself, will be at the Moscone Center in scenic San Francisco for the RSA Conference, 2012. (SecureAuth will be front row in the exhibit center, Booth #217.)
The job of many of you – at this event – is to:
- Map the requirements your company has around:
- Identity Management
- Access Management
- Cloud Apps Access Control
- Web Apps Access Control
- VPN Access Control
- 2-Factor Authentication
- Mobile, BYOD Support
- To the Vendors at the event
Well…
You can either:
Image #1: SecureAuth is a multi-functional, multi-tenanted authentication solution that combines the functionalities that previously required the “cobbling” of products from multiple vendors.
The breakdown of the functionalites is very revealing. (See image #2, below). Traditional vendors simply provide horizontal solutions that require enterprises to combine the functionalities together for a full soluiton. It is these integrations which tend to tend to run up cost and create security weaknesses in the architecture. Because SecureAuth is a single solution, cost is lower – and the security posture in augmented.
Image #2: SecureAuth combines the functionality required for Web, VPN, Cloud and Mobile Security into a single platform. (Click for full-size image)
Please come by the Secureauth booth @ the RSA Moscone Center, Booth #217 - or contact us – and we’ll map a solution to your requirements.
—
Garret Grajek is CTO and a co-founder of SecureAuth. SecureAuth is a single appliance solution that delivers configurable 2-Factor and SSO authentication for Web, VPN and SaaS based solutions.
Categories
Blog |
Tags
|
Author
Garret |
|
Welcome to 2012 – It’s a BYOD World. (That’s “Bring Your Own Device” in “IT” speak.)
SecureAuth and Support of BYOD (Including Amazon Kindle demo)
Enterprises are both:
- Encouraging users to use their own devices (For Cost Cutting)
- Being demanded to support End User devices (For Ease-of-use, Convenience)
The Concept of enterprises:
- Supplying all client side devices
- Locking down all client side devices
Well – is fantasy.
End user are able to access the internet, not just from the millions of Apple iOS devices - but from everything from bubble-wrap Android Phones bought at Walmart (See Image #1), Amazon Kindle devices for $175 (See image #2) – even including the Nintendo Wii gaming devices (See Image #3).
Image #1: Android Smart Phones, with full app and browser ability can now be purchase in buble waps at Walmart.
Image #2: Amazon Kindle Fire, at a whopping $199 – are legitimate wifi-enabled, browser based device – ready for corporate work – when protected by SecureAuth.
Image #3: Even the wonderful Nintendo Wii, is a legitimate member of the internet – and can be protected by SecureAuth.
If It’s Impossible to control the EXPLOSION of Client Devices – what is IT to do?
Control Access to your resources. The laws/regualations around IT have not changed – just becasue their are browsers on bubble-wrap devices and gaming tools.
All the same rules/guidances are in tact – Enterprises must still follow the 3 A’s of IT Security:
- Authentication
- Authorization
- Audit
It does not matter – if the user came from a Apple Air or a Android HTC or Lenovo laptop. The enterprise must still show:
- Which user accessed the resource?
- What authentication mechanism was utilized?
- Why the user was allowed the priviledged (Authorization)?
- When the user was given access?
The world has changed – And change is Good!
But we need to have the tools to manage/collaborate with the change. Not only has their been a (wonderful) explosion of client devices – their has also been an explosion of enterprise resources.
It’s NOT enough to put up a gateway around the perimeter!!
The modern IT environment requires access at the following (3) accss points:
- Enterprise-Hosted Applications
- Gateway/VPNs
- Cloud-Based Resources
This is the modern IT world – users need to be able to get to these resources – with whatever device they choose to use.
Image #4: SecureAuth becomes the authentication mechanisms that validates the user identity, regardless of device – and then provides access to the corporate resource.
Don’t Authenticate the Device – Authenticate the User!
This is the SecureAuth mantra! You are being asked by the regulations (PCI DSS, NCUA, FFIEC, HIPAA/HITECH, CJIS) to identify the user and then allow access. This is EXACTLY what SecureAuth is capable of doing.
SecureAuth uses flexible authentication mechanisms, mixed, matched – any way you choose, to allow access:
SecureAuth supported authentication mechanisms include:
- SMS
- Telephony
- X.509
- E-mail OTP
- KBA/KBQ
- Help Desk
- Password
All based on your enterprise-held identities – meeting all compliance criterias. It’s a new world – and the new world is good. Happy Wii’ing!
And contact us – to learn how to protect your corporate resources – in BYOD wordl.
—
Garret Grajek is CTO and a co-founder of SecureAuth. SecureAuth is a single appliance solution that delivers configurable 2-Factor and SSO authentication for Web, VPN and SaaS based solutions.
SecureAuth and Support of BYOD (Including Amazon Kindle demo)
Categories
Blog |
Tags
|
Author
Garret |
|
