The coolest stuff I saw on the show floor at RSA:
1. Validus had an OTP card with a biometric built in all in the credit card form factor (http://validustech.com/index.cfm)
2. Aveksa, hiding out in the Novell booth, had a very slick entitlement audit and role management system with a nice demo (http://www.aveksa.com/)
3. The NSA had a booth and was giving away an awesome cipher game book. My daughter and I will be hacking away at that for a while, I’m sure.
4. Not technically on the show floor, but I got a chance to sit with someone from Bitarmor and they made me think encryption at rest could really be viable (http://www.bitarmor.com/)
5. Arcsight was giving away a smart car. And I thought our $5000 prize was big!
Tuesday, April 28, 2009
The coolest stuff i saw at RSA
Labels:
cipher,
encryption,
entitlements,
otp,
rolemanagement,
rsa,
tfa,
twofactor
Monday, April 13, 2009
stuck in the middle with you
last week i was at a meeting at one of the financials, and it was no surprise that they want to talk hard cost cutting. they want to get everything they can onto their low cost, well run MSFT platforms. at the meeting are myself and the account manager who brought me in as well as another sales rep and their accompanying talking head. it must be fun for clients to schedule dueling consultants. i know i would in their shoes.
everyone was on the same page at the start. the topic was how to get their LDAP user stores into either AD or ADAM as easily as they can. they were reserving the choice between AD or ADAM for later. the conversation strayed a bit and we were talking about how they also wanted to get SSO for their external users out of this if they could. the other consultant kept dismissing my claims that they were going to have to go through a transition period due to their stated need to keep some users on LDAP longer than others. it went in circles until i asked him to lay out his plan. “First,” he said “you move everyone to ADAM”. the head architect from the client and i smiled at each other.
wasn’t the point that they could not just “move everyone to ADAM”? so many people seem to miss the part in the middle where both the old and the new have to work together for a while. and if you can’t see that, then you’re not seeing the real problem. if we could just snap our fingers and put everyone on shiny new tech all the time, shops like QSFT would be out of business. it’s all the hard parts that people get stuck on in the middle of these projects that make it interesting…
everyone was on the same page at the start. the topic was how to get their LDAP user stores into either AD or ADAM as easily as they can. they were reserving the choice between AD or ADAM for later. the conversation strayed a bit and we were talking about how they also wanted to get SSO for their external users out of this if they could. the other consultant kept dismissing my claims that they were going to have to go through a transition period due to their stated need to keep some users on LDAP longer than others. it went in circles until i asked him to lay out his plan. “First,” he said “you move everyone to ADAM”. the head architect from the client and i smiled at each other.
wasn’t the point that they could not just “move everyone to ADAM”? so many people seem to miss the part in the middle where both the old and the new have to work together for a while. and if you can’t see that, then you’re not seeing the real problem. if we could just snap our fingers and put everyone on shiny new tech all the time, shops like QSFT would be out of business. it’s all the hard parts that people get stuck on in the middle of these projects that make it interesting…
Tuesday, April 7, 2009
manage privileged accounts or privileges themselves?
Interesting article on privileged account management at SC magazine. whenever i read about this i can’t help thinking there’s a problem with the model. i think of it like a house. and password vaults, the primary vehicle for privileged account management, are a place you store the keys to the house. but once you’re inside, you could walk over to the priceless vase on the mantle and knock it over. the better model is to control the access at the level of individual entitlements – don’t give someone root, give them the ‘restart webserver’ right. it’s like having them in the house and allowed to look at the vase but not touch. the analogy always breaks down there unless you invoke crazy glue, though. but i bet you get the point.
of course, i can feel dimikagi getting ready to chide me that managing stuff at the individual entitlement level requires a previously sophisticated and mature approach to get right. and that’s correct. but most organizations could easily identify many use cases where they have whole communities of people getting access to privileged accounts just to run one command – the classic use case where every DBA has the oracle account just to restart the network listener for the database. so i think there could be some very easy things to knock off the list in even the most chaotic shop. otherwise we’d all have to take the nice things off the mantle or stop letting in guests all together.
of course, i can feel dimikagi getting ready to chide me that managing stuff at the individual entitlement level requires a previously sophisticated and mature approach to get right. and that’s correct. but most organizations could easily identify many use cases where they have whole communities of people getting access to privileged accounts just to run one command – the classic use case where every DBA has the oracle account just to restart the network listener for the database. so i think there could be some very easy things to knock off the list in even the most chaotic shop. otherwise we’d all have to take the nice things off the mantle or stop letting in guests all together.
Labels:
access,
entitlements,
iam,
privilegedaccountmanagement,
sudo
Subscribe to:
Posts (Atom)