Was at a conference recently and had a CIO of a fairly large insurance company make an observation about moving applications to the cloud that I think hits the nail on the head around a major problem in the adoption of the cloud.

He said “one thing I have come to realize is that when I move my application to the cloud, all of the security of my networks and firewalls that I have invested in over the years disappears.  The only defense I have left is identity and data security in the application”.

This drives right to a major issue facing migration to the cloud.  Running applications in someone else’s data center is not new (we just gave it a fancy title “cloud”).  The major factor holding back the adoption of the cloud by companies today is controlling authentication and authorization remotely.

Not many CIO’s feel comfortable putting all of the user information and security policies on equipment that is not located internal to the company and under the direct control of company employees.  CIO’s who rely on lawyers and contracts with host providers are setting themselves up to look for work.  Even if you can sue the pants off of your cloud provider, the basic problem is a breach would have occurred and your people are not involved at the security level.

Therefore, the solution is quite obvious.  Identity and security need to be delivered as a service to the cloud instance. And it needs to be rock solid.  The security service needs to be maintained on internally hosted platforms and applications need to be modified to work with external security and policy services.

This is evolutionary step that will make adoption of the cloud happen on a large scale.  Just as desktop applications needed to be rewritten to client server paradigm, then morphed into web based models, now to mobile apps, applications will have to adapt and evolve to an external security model delivered as a service versus being embedded or co-located with the application.

Okay, so this is not really an identity post, but it does have to do with cryptography and you might help bring a murderer to justice.

The FBI is asking the public to look at to hand written notes found on a 1999 murder victim.  They are written in a cypher that the resources the FBI has have been unable to crack.  See if you can recognize the code and help crack what the notes say.

Here is the link to the FBI site: http://www.fbi.gov/news/stories/2011/march/cryptanalysis_032911/image

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.

We are all familiar with shoulder surfing.  Particularly when flying. Laptops without a polarized lens on it are quite easily seen from two or three rows behind you while you type away at 36,000 ft. The amount of confidential company information, that was so carefully protected so only the authorized user was able to access it, is being worked on in an environment that could not be worse from a security stand point.  Tight quarters, prying eyes, business folks who may or may not be friendly.

Personally, I have seen almost weekly presentations being worked on for confidential clients (I know who the client is, who is making the presentation, what the content is, etc.).  Truth: actually saw a businessman work out the layoffs he was about to commit to.  I could have capitalized on that information.

But even with shoulder surfing, the prize jewels, the UserID/Password, was always somewhat hard to see, particularly the password.  The user’s hands are on the keyboard and the password field is masked, so I can get the  userID, but unless I can sight read the finger keystrokes, I am left without the password. Some passengers check email after landing, so I can also observe the email box they are working with.

But last night I saw my first evidence of a new security issue around tablet computers I had not thought of before.  We were coming in after 11:30 PM into Newark (don’t ask, successful, but long day).  The tray tables were up, we were buckled in, and the cabin lights had been dimmed. Never sure why they do that; always seemed to be unnecessary to dim the lights, the pilot is sealed into the front cabin. And if there was an emergency, we would be in the dark until someone turned on the light.

But I digress.

We land, with the cabin pretty dark inside and roll to a stop.  We get the obligatory “Let us be the first to welcome you to Newark…” near midnight speech and the all clear to use electronic devices.  And that just what one road warrior in the front row facing the bulkhead did.  Showing he’s more cool than the rest of us, he fired up is iPad and logged into his email and corporate network.

But what he did not realize was he was showing the entire cabin his login credentials, which I caught a part of on my camera as I was checking my phone for messages.

You see, one of the great features of iPads and their kind is the very advanced and very bright backlit screens. And in this dark cabin, the bright screen light up and projected an inverted mirror image of the tablet screen on the bulkhead just in front of him.  Granted it was not very clear, but I could tell he was opening a browser and typing a URL, then typing in a user ID and password.

And because the keyboard now rides on the bottom half of the tablet’s screen, the passenger was giving us a finger shadow show of him logging into his email.  The grey silhouettes of his fingers moving back and forth as the plucked out the user’s credentials.  Granted, it was not an exact science, but here I was, nearly five rows back and I could capture it all on my cell phone video.

Later on, I can replay that video, flip it to remove the mirroring of the image, and I would have a pretty clear show of the finger movements needed to log in.   I may not have whether is was a ‘t’ or a capital “T”, but I would be starting my hack with a lot of starting information to cut down the time to brute force attack the user’s site.  Just check his bag tags for any company identifier and I could start figuring out what system the man just logged into.

So, I call it silhouetting, a form a shoulder surfing, that can broadcast your credentials not only to the guy behind you, but the entire section of the plane.  It would help more if they were by a window to enhance the reflection surface.  I could easily get the screen and the typing motions from many feet away.

The new version of the database 11g R2 adds some nice new security features for us identity and security folks. One of which is tablespace encryption.  No longer does one have to pick which field is encrypted.  Now, if it makes sense, the whole table can be encrypted.  And the good engineers at Oracle make it simple and easy to do.

Hey, if you use some newer servers with the Intel Westmere chips in them, they now include the Intel AES-NI encryption onboard the chip.  This now gives hardware encryption speeds without having to buy and install a separate encryption board.  The 7x – 10x increase in speed means there is NO reason not to encrypt your database.  This makes any encryption performance hit nearly nothing, so there is no excuse.

But one of the quiet features thats hidden in ASO is how the keys are stored. It helps with that major problem of key management that has bollixed up great encryption plans over the years.   For every table (or column for those going old school), ASO generates a new encryption key.  All keys are kept in an Oracle Wallet (a PKCS #12 wallet) which are then re-encrypted to triple-DES strength with a master key that is kept away from the database and hopefully the wallet.

But what is missed by many is that by taking these keys and storing them in one wallet under a master key encryption means that key refreshes are much easier to accomplish.  Instead of having to generate new keys, recrypt the tables with the new key, etc., all you have to do is use Oracle Wallet Manager (included with ASO) to generate a new master key and recrypt the keys in the wallet. The tablespace keys stay the same, but you now have fulfilled your change the key storage for the database on a regular basis.

This now makes key refreshing much simpler and easier to do. So now you can implement a stronger security maintenance program of refreshing database encryption keys on  a more timely fashion (once a quarter is nice, definitely after any major changes to the database).  Encrypting tables is easy to do, keeping the keys rotated is not so easy as it sounds.  Within this nice key management utility in ASO, life just got easier.  And more secure.

Yesterday, IANA (that’s the Internet Assigned Numbers Authority; they do exist) allocated the last two publicly available IPv4 address blocks to APNIC (the Asian Pacific organization that miters out IP addresses in that area).  While the announcement below seems to be routine and only for those really into IP addressing, it does mark a milestone in the Internet – IPv4, as predicted, is running out of addresses.  All hail IPv6!

These last two address blocks, 39/8 and 106/8 represent the last freely available /8 address blocks under IPv4 and triggers a provision among the addressing community to work together to distribute the last 5 /8 blocks remaining.  When they are gone, that’s it for IPv4; no more IP’s to give out.

But don’t worry, there is still IP’s available under current IPv4 allocations and they will still be available for a while.  But it does mean the Internet is crossing over from IPv4 to IPv6.  In a few years time, the net will have to be IPv6 to accommodate everyone who wants to use it.

So what does this mean to us in security?  Well, for one, our customers are going to be forced to move to pure IPv6 networking in the next few years.  One of our largest clients, Comcast, even has a website up devoted to letting everyone know of their progress in this transition:  http://www.comcast6.net/

As for Oracle’s middleware, all of it can be reach via IPv6.  That does not mean all middleware is IPv6 yet (we are working on that) but all outward facing interfaces such as web proxies, etc., can handle the dual stack. There are some IPv4 only interfaces, but they are for local services and would appear in local or closely linked network segments.  For more details, see the Oracle Fusion Middleware Adminstration Guide.

But it does mean customers will be asking for IPv6 as a checkbox in their evaluation processes.

Here is the text of the announcement yesterday, which can be found at https://www.apnic.net/publications/news/2011/delegation

Two /8s allocated to APNIC from IANA

Heard it the other day during an analysts briefing about the newest developments in cloud computing.  The idea of cloud bursting is for the most part, major enterprises will want to house their own cloud services for day to day operations, but then expand into the public cloud during peaks in demand.  They want to burst their internal cloud for an external cloud platform. Thus “cloud bursting”.

Sounds good on paper.  An online floral deliver service can run their website on their own in house cloud, adding new sites and services.  This internal cloud is preferred from a security point of view in that all user PII and other sensitive information stays in house and under the enterprise’s watchful eye.  Now, when Mother’s Day rolls around, the company can “cloud burst”; access on a temporary basis additional websites it will need just for the holiday rush period.  They expand their capacity on a temporary basis by creating a hybrid cloud of internal and external services.

Well, that all sounds very impressive and it is logically it makes a ton of sense, both technically and economically.  However, the devil is in the details and my view is the success of this concept of cloud bursting is completely dependent on getting the security right.  It might look easy on paper to add a few more virtual sites to your hybrid cloud, but if the services requires any PII or other sensitive information, you are now moving that information to an external site and the game just got a lot stickier.

As mentioned elsewhere, data ownership of sensitive information is becoming more and more of an issues.  Yes, you can sign contracts with outside cloud vendors to insure security, but most CxO’s I talk to still have it in their DNA that secured information should stay internal.

What this concept of cloud bursting tells me this is an opportunity to get your single sign on (SSO) or federation house in order.  A rock solid identity foundation running your current external web sites should be able to remotely add external cloud sites and still manage security (authentication and authorization) on the internal infrastructure.  The external cloud sites would be “neutered” versions of the web resources and would use federation or redirection to an SSO identity provider on internal resources for user security. Again, sounds easy on the whiteboard.

So, as you make plans to expand you online presence, now might be the time to invest in building up your external facing security infrastructure and get use to managing multiple instances of your web resources securely.  Then, when you have to “burst your cloud”, it won’t be as painful and you can support the business needs of the company easier and at lower cost.

And if you haven’t seen George Clooney in the The Men Who Stare At Goats, you should.  Highly recommended and he shows his version of “cloud bursting”.

No matter how good your identity management architecture and processes are, you may have a gaping hole in your public facing web stack.  And you won’t even be sure when it is exploited.

The hole are any third party applications (like who doesn’t have a few in their portal?).  I am always encouraging buy versus build, as your business should be putting jam into jars or running a bank, not writing software applications. Particularly ones that face the customer . Face it, most internal apps have grown organically and they are sink holes of development cash. And they have not upgraded their facade technology. At best, they are working through a re-skinned technology layer that you are not even sure who built it.

A customer relayed an interesting scenario that occurred recently that might keep you up at night.  They are in the financial business and offer services in a rather full service portal.  Part of that portal is a external agent management and fulfilment  application that they have contracted to use  for years and now offer over their portal.  The application vendor was well known, well accepted, and had been a good partner for years.

After a recent compliance audit of the site, they received notification from the auditor that the third party application had an administrator account in it of an employee who had not worked for the company for six years. The account was a “privileged account”, a rather impressive marketing sounding term but means someone is too lazy to secure the OS with separation of duty policies and gives out root or system access to accounts and does not track them closely.  The “privileged account” has access to PII information, clients personal data and account information.  Someone using that account could log in and download a lot of information the should not be free (apologies to my open source brethren).

Remediation time – no problem.  Ask the third party vendor to scan the audit logs and see if anyone has used that account in the last six years.  Dust for fingerprints and you are done.

But here is the rub – the third party vendor was not following the clients data center policies on logging and auditing.  In order to save storage space, thus money (thus price to the customer), their application was not set to log as much information on use activities as it could.  Therefore (wait for it), nobody was sure if someone had used the privileged account for evil.

And in the binary business of security, without a way to prove a breach was not exploited, one must assume it was.  Thus, the client was forced to implement a remediation plan for several million customers to the tune of several millions of dollars and some pretty irate customers.  A hefty price to pay for a security breach that may have never even occurred.

Needless to say, our customer is implementing a security review of all third party applications in their infrastructure and insuring they are abiding by the security policies of the data center.  There is a cost involved, but not as much as the above remediation.

So when you look at your GRC policies, remember to include third party applications and their vendors and insure they are abiding by the same rules as every other application in the house.  Add components to your identity framework, such as SSO or federation, that can externally aid in identity forensics.  And by all means, insure the policies you place on your internal applications are enforced to the same level with any vendor who supplies an application to your company.

This entry is in response to a new tactic one of our competitors is using to convince prospective customers that the way to detect what employees are the most dangerous is to scan through all of entitlements and count who has the most entitlements.  That will point to users who have too many entitlements, so they must be abusing the system.  ”Mary has 54 Active Directory Groups tied to her userid, so she must be up to no good”.  The competition says this is the person you need to vet and keep under strict survellance.

Too bad the client bought it.   They are going to spend a lot of time tracking the wrong people.

So I ask the question, if you treat entitlements like keys on a keychain, who has the most keys on their keychain (save the security guards)?  According to this bent logic, the one with the most keys is the one most likely to be up to no good.

The answer is quite simple: the cleaning staff.

Have keys (or security Java card) that allows them to wander throughout your building pretty much anywhere.  The data center. The backup generator room. The CEO’s office.

So lets clamp down on the janitor and get approvals/certifications for every key they have on their key chain.

Too bad you would miss the administrative assistant to the CEO who only has three keys, but one is to the backup server room.

You see, its not the number of keys you have on your keychain, but why you have a particular key on the key chain at all. If you scan Active Directory, you will probably find Mary in our example does have 54 groups assigned to her, but her role is managing user group meetings for the company and 46 of these AD groups are old distribution lists (email lists) from old shows past that are no longer of much use and were not considered a security risk even when they were in play.

Congratulations.  You have found Mary is not a security risk, just lazy about deleting old meeting email aliases at the company.

So its not the number of entitlements, but what the entitlement is in context. Its entirely proper for the cleaning staff to have a key to the backup server room; they have to enter to clean the room.

However, what you would find suspicious is doing a role scan and finding all administrative assistants to directors,  AVP’s,  and higher in the finance department all have the same 5 entitlements (keys) but one admin assistant has a sixth key the others in her role does not. She too has a key to the back up server room.

That should raise a yellow flag and trigger an investigation.  Why does the admin need access to the backup server room?  Used to work there and nobody got her key when she transferred?  She made a copy so she can download client information after hours to sell on the black market? She found it one day in the lunch room and never gave it back?

A quick follow up investigation with the manager of the backup server room might find out that, yes, one financial administrator assistant has the key to allow her to drop off a copy of the CEO’s external back up drive once a week as a security precaution.  Or pick up the CxO’s private faxes that happen to come into a printer in that room.

Its okay then. Its an anomaly,  but every agrees that its okay.

Which then begs the question should other administrators also have access to the back up server room in case Mary is on vacation or ends up on leave?  Perhaps others should have this privileged key as well, now that we know its part of their needed entitlements.

The key here is not to count number of entitlements or keys, but use analytics to identify those critical keys and anyone in the organization who has abnormal access to the privileged key.  That is an effective identity management approach.

One last question: does it bother anyone other than me that I never have seen a pilot of a commercial airliner pull out a set of keys to fly the airplane?