Feeds:
Posts
Comments

printchip_web

Happy holidays all.  Apologize for the dormant state of this blog, but its been crazy trying to keep up with everything.  That is a good sign that identity and security business is stronger than ever.  Already making a New Year’s resolution to be more active in the blog-o-sphere.

Never has the focus on identity and security been so intense.  One security firm we deal with stated that they believe there are over 10,000 active identity theft entities out there. These run the gamut from your neighbor’s kids trying something after school to organized crime rings and even foreign governments.  Recently, it was reported, authorities have disrupted a planned cyber attack on US banks set for early next year by organized hackers out of Russia.

Which brings me to the point.  It was a comment from a CIO presenting at one of our sponsored events on identity.  The comment rang true for me.  He said something to the effect: “The biggest challenge facing me in the coming months is securing my company’s assets from online threats.  The need to lower costs has us migrating our assets to the cloud.  There, I lose a lot of the security I have built up over the years.  All our investments in firewalls, DMZ’s, certificate servers, centralized directories…. all of that is no longer under my control.   As I see it, moving forward, the only security I can rely on is identity management.”

This is a recurring thing with my clients.   As we, as an industry move more to a services, cloud based model,  we are going to have to re-invent what we know about security and identity management.  We will look more into these issues in the coming weeks as we get ready to move into the challenges of 2013.

The future’s so bright, I have to were shades…..

 

Salt

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.

Datamasking

Try not to make this a blog an outpost for plugging my company’s wares, but want to make an exception in this case as I think many can benefit from it.

Got word yesterday that our long awaited data masking templates for Oracle E-Business Suite 12.1.3 were released to production.

Okay, I hear you whimper.  Why is that so important?

Because unmasked test data is one of the easiest targets for thieves to hit.  And its so simple to plug this hole.

For those who need the short background version:  companies go to great pains to set up identity management and secure their data in production, rich with credit card numbers, ssn’s, PII, etc.  ERP applications like Oracle’s E-Business Suite 12.1.3 capture and store a great deal of this information in their databases and do a lot to make sure it is secure in production.

But many of my customers think nothing about taking a snapshot of the database for QA and testing purposes. Maybe once or twice a month, they clone the database into testing, because “nothing tests our new code better than our production data”.  They now have a new copy of production in an less secured testing environment.

Often, these test/QA folks are with the development team (maybe even outsourced) and often have privileged accounts into the database and the application so they can test full functionality and affect changes in the test environment.  Your production site might be under strong lock and key, but it would take a dev tester mere minutes to clone yet another copy of sensitive data on that SD card they brought with them to work that day.

So data masking is just that.  A the production data is cloned, key elements of the database are masked, obfuscating the actual data.  Masking may randomize user’s SSN’s, exchange phone numbers and addresses between user records, etc.

Masking is a little more involved than just scrambling data.  You still need the data set to behave as it does in production.  You just cannot swap everyone’s zip codes if your software uses it to do reports by region.  An 07405 zip code with a California address will not test cleanly.  Plus, you need to track the changes to the database so you can do them again with some consistency, so refreshes of the masked data behave in a like and similar fashion.

So what’s the big deal with the announcement?  The problem with masking, particularly complex ERP systems, is to know where the sensitive data is in the system and how best to mask it for protection, yet still have it behave properly for testing.  ERP systems have their own way of building relationships between the tables the are built on and often these table can run into the hundreds.  So the good news is the development team for EBS worked with our masking team to create templates specifically for the EBS 12.1.3 suite.  This will significantly compress the time to get a masking program in place and plug that security hole. You can leave a copy of your masked production data on a SD card at the counter at Starbuck’s and its safe as can be.

So if your company runs EBS 12 and runs copies of production data in testing, you should look into these new data masking templates. And I know there are a lot of you.  You can find out more about the the Oracle Data Masking Pack with Oracle Enterprise Manager.  You will need to purchase a license for the Data Masking Pack, but the EBS templates are available free in the following patch:

Fox and egg

We all know the biggest security risk are not external threats, although they do pose a substantial problem area, but internal privileged users. We also know the majority of the at risk information is contained in databases. So why do we leave the fox to watch the hen house?

I run into this situation all the time, at companies that believe they have a strong security posture.  However, they have a team of dba’s maintaining their corporate databases.  If it is like most database teams, they are a small, elite group of database technologists, many with root access to the database farm.  Most databases manage their own security, so a common practice is to share dba accounts and keep user ID’s and passwords in a shared spreadsheet.

When we point out the huge opportunity for one of the dba’s to go rogue, we often hear “that can’t happen here, we trust our dba’s”.

Until the next breach is recorded.  Then you will find out it was DBAFIN12 who accessed the personnel database and that could have been anyone of 5 dba’s and that’s if it was one of the dba’s, not someone who just happened across a copy of the password spreadsheet.

So what to do?  First, centralize DBA user management into a directory.  Most databases can use an LDAP directory as the user store.  This not only puts all accounts that have privileged access to the database farm, it also does two things.  Requires each DBA have an identifiable user account so sharing is discouraged.

Second, by placing account management in a directory, you often place account management into the hands of a team external to the DBA team.  Gone are the days where one DBA can grant high privilege access to a data table to another team mate.  Now, if they have to go through a directory team, the DBA’s will have to justify why they have access and when they no longer need it. Hey! Instant separation of duty!

Many database companies, including my company Oracle, also have more sophisticated central user management. Oracle’s Enterprise User Security (EUS) has been in the database for several versions now. It provides an additional layer in the LDAP directory of Enterprise Roles and schema mapping.

An elegant solution to having the foxes run the hen house.

Back again finally.  Things are as busy as ever here.

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.