Friday, October 6

First Week at RSA

I had an interesting and busy first week at RSA. It's no surprise that I met some extremely bright people. I spent my first few days in Phoenix working with an internal team and managed to speak with a few customers as the week progressed. Some of the very cool ideas I've already heard include:

  • Providing Network Access Control using machine certificates. The idea here is that you can't plug in a machine without a proper cert and gain access to the network. RSA has certificate management software that makes this solution a reality. The cert can be based on a specific hardware profile so getting your hands on the cert won't help. It's simple and effective.
  • Risk-Based access control or what RSA calls Adaptive Authentication. This is about adding an additional dimension to the authentication process. Not just what you have and what you know, but where are you right now? Or from which device are you attempting to gain access?
  • The business value of implementing Federation as a way to reduce bandwidth on the LAN. It never even occurred to me until one of my new colleagues pointed it out. Why tie up your global WAN with unnecessary packets (and spend your budget on increasing infrastructure) when you can leverage the web to pass access rights to overseas applications using a simple Federation solution?
  • RSA also has a nice key management utility for organizations that need to build encryption into software solutions but don't want to assume the burden of: 1) designing a secure encryption solution. 2) securing the encryption keys for use by the solution. Or worse yet 3) managing the on-going key life cycle. Keys can be shared amongst applications and re-generated on a schedule to reduce the risk of the keys being compromised.

Needless to say, I'm already getting very busy. I have a lot to do and I have to say I'm invigorated by the new challenges. ...until next time.

2 comments:

allan milgate said...

Matt - Interesting blog !
Re your comments:
1. device certificates. Server-based certs are widekly used in my neck of the woods.
2. The three factors are what you have (device), what you know (password) and what you are (biometric). You additional factor "where you are" is not viable for an identiy, only for device id, and that comes back to what you have.
3. Federated Identity? - there's also a lot more traffic passed through a SAML or similar SSO authentication than you might think, just to establish the trust.

Check out my blog,
http://identityaccessman.blogspot.com/ and maybe link it to your.

cheers,
Allan

Matt Flynn said...

Thanks for the comments Allan.
re: #2, I do think that risk-based authentication as a concept is becoming more appealing to the customers I've been speaking with. Perhaps "where you are" isn't the best example, but to stick with it - the idea is that you may choose to require additional levels of security (like 2-factor or answering questions) if a NY-based user is logging in from Singapore at 3am EST instead of from NY between 8am and 5pm EST.
re: #3 - I was thinking a SAML assertion and Web UI as an alternative to SSL/VPN and perhaps a client-server app. I realize that results and circumstances may vary, but I can imagine a scenario where a business case could be made for Federation strictly on network usage improvements.