Archive for the ‘passwords’ Category

TRESPASSINGIn the maturity model of identity management, we have been through many stages of evolution and may be on the brink of the final stage – context aware identity management.  First it was centralized authorization (directory), authentication (access managmeent, SSO, STS, federation), identity management (provisioning), roles (RBAC), auditing/regulatory (compliance and analytics), privileged accounts management, and finally centralized policy management (entitlements servers).  

The final frontier, once you have mastered all of the above, is context aware identity management.  The user may have all the rights and privileges to access the resources, but they are doing so in an abnormal way.  Call it behavioral security.  My classic example is a company’s CIO may have access to a sensitive data room and may even have their badges grant them access to the data center floor, but one has to ask why the CIO is entering the sensitive data center at  2 AM.  However, a member of the cleaning staff would have the same privileges and would be expected in at 2 am to do their cleaning.

So its all about context.  Having the right credentials and using them in an manner as expected and flagging when they are used atypically.  As of this writing, Bradley Manning is waiting his sentencing for releasing 700,000 classified documents to Wikileaks.  What many miss in this sad adventure is that Pvt. Manning did not “hack” his way into the systems containing this information.  He was hired/recruited, trained, authorized to have sensitive access, and had his access vouched for in several compliance reviews.  The only question nobody asked was why a low level private with clearance was downloading hundreds of thousands of files at one time.  His behavior with his access level should have sent up warning signs.

This type of behavioral monitoring has been around for years and found some success, particularly in the financial sector.  Banks and investment firms have employed adaptive access management tools to work with their single sign-on front ends to their web sites. You have probably seen them when your bank shows you a confirmation picture first and asks you to set up security questions.  What you may not know is the software also “fingerprints” your system (OS type/version, MAC address, IP location, etc.) and starts building a profile of how you access your account. If you do anything out of the ordinary, it may ask you who your second grade teacher was even though you presented the correct user ID and password. Try logging into your bank from your mother-in-law’s computer in Florida when you visit next and you will most likely have to answer some additional security questions because we need to insure its you.

So buried deep in the latest release of Oracle Entitlements Server (try no to thump my company’s products, but this is the only software I know that can do this at this point) is the ability to add to your enforcement policies to make them context aware. The enforcement policies can look at more than just job title and role, it can also look at location, device, time, organization, etc. to make a more informed decision on whether to grant access.

It may be okay that you have privileged access to mission critical servers to issue a reboot command, but, ya know, we are just not going to allow you to do that if you came in through an external firewall using you iPad.  Just not going to happen. You need to be onsite in the data center to do that.

It is particularly helpful when several users have access to the same system, but need to be limited on what they can see. Just saw a killer demo a few weeks back where users of a military application can see a map of the world showing location of current deployments, but the data is filtered so you can only see resources in your theater of operation.  Europeans can only see assets based in Europe, Africans only see stuff based in Africa, etc.  All controlled centrally with one access policy.

To get to this level of context aware security is not easy to do and represents what I believe is the final frontier in online security.  Its the ability to not only control access and authorization, but understand when and how the proper credentials are being used.  Remember that most damaging breaches are by insiders who have proper access.

Read Full Post »


What can I say but “really”?  (My nod to one of my favorite SNL Weekend Update bits).

LinkedIn just had six million of its user accounts and passwords posted on a Russian hackers website and LinkedIn has 160 million business user accounts, so nobody knows how many accounts were stolen.  Might be just computational time until all are published.  If you have a LinkedIn account, change your password immediately and regularly until LinkedIn has earned your trust back.

But everyone asks, how could this happen.  I have a guess.  Some yo-yo on the project team decided to save a little money for the company.  They chose not to salt their encryption hashs.

For those unsure what a “salt” is, its a way to add complexity to the encryption algorithms to make them harder to break.  Computers are computers and encryption routines are just mathematical formulas. Given a set input, you always get the same output.

To set up a brute force atttack, just use a computer to create a table of all the known output from an encryption.  Steal the hashed passwords from linked in, do a reverse lookup on your hashed output table and viola, you know the user’s password.  Particularly if they used common phrases and words.  So far, reports are the hackers were able to brute force reverse engineer 3.6 million passwords so far.

But what if I tacked “DSON” to the front of every password before I encrypted it?  Only I know to do this as application owner.  And this invalidates the output lookup table because its values were not generated with this added “salt” prefix to the encryption algorithm.  As a hacker I would now need a lookup table for every combination of 4 letter prefixes; tough to do. Today, modern secured systems use between a 48 to 128 bit salt to their encryption practices.

But here is where I think Linkedin got in trouble, because I see this come up during procurement on security projects all the time.  The added “salt” requires more storage space than the naked password and takes a little performance off the system to calculate.  So some make the extremely silly decision to drop the salt, use the naked password with the OOTB encryption routines.  Lets save money, everybody.

But last time I checked, disk space was extremely inexpensive and the added performance hit was near zero.  But the exposure to hacked passwords remain and is extremely expensive.

So check and see if your systems salt their password hashes.  If not, strongly recommend you start a project to migrate users going forward to a salted encryption.  Unless of course, you like having your customer passwords on display on a Russian hack-site.

Read Full Post »

There. I’ve said it.

Time for developers to stop coding security into their applications and focus more on business functionality of the applications they work on.

Think about it.  One of the first things a developer wrestles with is how to control users within their application.  Day one, they usually build a login screen.  Now where do I put the userID’s? How do I secure that?  And what can this user do?  What security model do I follow?  For this sensitive routine, how to we control who can and who cannot get access?

My personal experience estimation is 25% – 30% of all development efforts are spent rebuilding security and identity.  But as programs become more complex, more and more complexity must be built into the system.  And as we all know, complexity is the Achilles Heel for security.   Don’t even get me started with security and identity in cloud computing.

Instead, security should be thought of as a service. Instead of the programmer trying to learn and then implement security in their programs, they should rely on callable services to provide AuthN and AuthZ decisions.  Instead of building login screens,  a user identity repository, user administration screens, and provisioning sub-systems, the coder should just in calls to a security subsystem and rely on the decisions to be made for them.  Drag and drop in their IDE.

We already have some of this today, but we need to adopt it at a faster pace.  At the macro security level, access management and federation tools can protect an application and authenticate a user.  The programmer does not have to care how the user is authenticated, only that they are authenticated by the powers that be.  The user may have only supplied a user ID and password, used a challenge token, or a retina scan.  The programmer does not care.  It just calls the security service and asks is this user authenticated to use this application. Yes or no?

Fine grain entitlements are another matter.  These too should be handled via a security service.  Instead of writing convoluted security logic (lets see, if the user has this role and this entitlement, then let them do this, etc.), they should just insert a policy enforcement point (PEP).  This is a call out to the security service at the start of the subsystem logic.  Can the user do what they are about to try and do?  The programmer does not have to worry about why the user is approved,  just that they are approved.

Policy entitlement servers, which can support this PEP model, are available, but not enough applications are built using this decentralized security approach.  As an enterprise continues to grow in security maturity, the benefit of this approach becomes apparent.  Security policies become centralized across applications and can be managed with role based approaches.  Gone are the days when security is baked into a system and the original team leaves, leaving the organization with questions on how the security in the application works or how to change it to meet new policies.

Brittle security code is a thing of the past when all a programmer has to do is treat security as a service.  Does the user have a valid session to use this application?  Yes/No. Drag authorization point in the IDE into the program’s workflow and not worry how the user is validated.  Can the user run this report?  Yes/No.  Cut a check and pay a vendor?  Yes/No.  Much simpler when this is removed from the code and PEP’s inserted.

New regulation passed by who know who?  Change in the security policy of the company?  Much easier to manage with all user information and security policies in a central location.  Change the policy and the applications behavior is changed without recoding and testing (well, you want to test the policy changes in UAT first, just to be safe).

Instead of 25% of the development effort spent on security issues, less than 5% of a programmer’s time is dedicated to it.  Allowing them more time to focus on the functionality of the program.

So, I say, its time to get programmers out of the security business.



Read Full Post »

Recently, a challenge was put out to our organization to try and determine what the major challenges will be for IT in 2020. Thats several lifetimes in this business. But it always is recommended to remember where the road you are on is eventually leading or you will get lost.  After several long walks with the dog, here is what I believe.

The fine art of handling users across business enterprises…

The other day, I booked a round trip flight for my son to go out to Colorado to look at a college he had gotten into. He was ticketed to fly out on US Airways and returned on Frontier. The thing is, it was booked as a United Airlines flight. Which I found on Kayak.com, a second tier travel search engine. About the only thing I could not do was reserve a specific seat on the Frontier airlines. Guess they did not have that part hooked up yet.

Now think about the identity aspects of this transaction. The only site I technically identified myself to was Kayak.com to start my search. This is where I established my online identity instance. This identity instance then approached the United Airlines system with enough credibility for them to reserve a several hundred dollar asset (the seat) from their inventory. Guess Kayak.com trusts me because I created an online account with them.

But then United had to turn around to its suppliers, US Airways and Frontier and complete a transaction on my behalf. All of them had to trust the supplier of my debit card (Visa) who, in turn, had to get the thumbs up from my bank (Bank of America) that I had enough money in the bank to cover the bill. And I am sure several government agency “don’t-not-fly” databases were checked or notified.

And my son’s Continenal OnePass account was to be given credit for his trip, as United and Continental are partners and soon to merge. And in that same transaction, I could have arranged for a hotel, rental car, trip insurance, parking and dinner reservations if I wanted to.

Did I mention this was not for me, but someone else?

This represents the challenge to enterprise IT organizations and the enterprise itself in the coming decade. By 2020, organizations must be able to handle online identities passing through their systems. Today, many IT organizations have some form of centralized employee directories and customer databases. They are still rolling out provisioning and identity self service applications. Entire industries (healthcare come to the top of the list) must be able to provide this seamless walk through a pool of providers.

By 2020, users must be able to establish an online identity and be able to pass through companies and partnerships as easily as they walk from store to store in a shopping mall. Sessions will have to be trusted from partners, privileges determined, and security maintained. All without delay.

Microsoft calls this claims – a type of request, the right to the request, and the resource requested. But it is much more than that. Claims fit into the Windows world quite nicely, but its rough sledding when you get outside the Windows world and try to go to federated partners. Unless they are on MS as well, the integration is difficult.

So, in 2020, companies must rethink their entire identity, security, and compliance approach to allow these millions of user sessions to “pass through” their systems and do business with them. Identity is no longer imbedded in an application, or enforced at the firewall. It has to be built into the security fabric of the IT enterprise at the ground level. Thus Identity Network Engineering is the complete rethinking to the approach of building enterprise architectures. It has to merge all of the current identity technologies (provisioning, authorization, single signon, compliance, reporting, etc.) into a unified identity architecture that is as fundamental to data center design as networking and storage technologies are.

More entries on what that security fabric will look like in the coming blogs.

Read Full Post »

Reset Passwords?

Just  was pointed to a new article (thanks Kevin) in the Boston Globe about a Microsoft “researcher” doing a study and determining the cost of having users change passwords regularly far exceeds the cost of the assest they are protecting. The article recommends IT shops should abandon having users regularly changing passwords as “it just annoys the end users and is not cost justified”.

Completely wrong.

Yet again Microsoft touts having done exhaustive studies on identity matters and again comes up with a counter industry observation that is just plain wrong. Remember their Passport security wallet?  Need I say more about a company that continues to get it wrong on identity matters.

Yes, any malcontent that obtains a password would most likely use it immediately.  Immediate terror and destruction.

But the wise thief would be more propitious and use the newly gained access discretely and sparingly.

What would be more profitable?  Using an ID and password to obtain insider information about a company and posting it for the world to see on the Internet (big splash and embarrassment) or to use the access every quarter to gain an update on where the company is going and profit by taking repeated positions to gain repeated profit? Like Harry Tuttle in Brazil; In. Out. Quickly. No paperwork.

And regular password changes have several advantages.  First, one must have authorized access to change the password. If they don’t, the account is locked down/shut down.  This will automatically cleanse accounts that are abandoned for a variety of reasons.  For example, contractors are constantly given high privileged accounts to do their work on systems, but then leave once their contract is up.  Normally, good provisioning policies would deactivate all accounts associated with that contractor (read outsider), but often, in reality, the hiring/project manager just changes their status to “inactive” or does nothing at all in case the contractor is needed again in a hurry. Why not just give him/her the same accounts they had when they left a few weeks ago? Soon, these prized backdoor accounts are forgotten and left in statis.

IT managers cannot make a decision looking at hundreds, if not thousands of accounts, which accounts may be high exposure, left over accounts. Seasoning out passwords and locking accounts that are not reset insure these orphaned accounts are regularly cleansed from the system.

This also helps, to a point, to also detect users who may have access to a system and no longer really need it.  They may have gained access on a special project but no longer require that privilege.  If the user does not take the time to reset the password on a scheduled basis, they may not really need that access after all.  Their inaction will auto cleanse from the network an access that may have been legal, but no longer needed.

And lastly, if you don’t force account changes, users tend to resort to a really bad habit. Worse than sticky notes with passwords on the computer screen. If they are not forced to change passwords regularly, they tend to make ALL of their accounts have the same password.  The big risk here is if a malcontent gets the password to one system, they have the password to many more systems.

As any IT security specialist knows, the cost of the prevention needs to be cost justified based on the asset being protected and the likelihood of a security incident.  The “rough calculations” of $16B/min is unjustified in the article (and what kind of metric this is is very curious indeed), and I would strongly question any IT organization making a strategic decision on this tomfoolery of a justification.  As any reader would know, there are more than $16B in assets being protected on our enterprise systems today.

If you want to make your user’s life easier, consolidate systems log ins to a centralized directory, an access manager layer, or even better, a centralized federation security layer. Then they only have to worry about one set of user credentials.

Read Full Post »