Archive for the ‘Oracle’ Category

Keep Calm hes backTime flies when you are having fun.  Or extremely busy. Or a legendary procrastinator.

Noticed that this blog, which  I keep putting on my to do list to update, is going on 3 years stagnant. Its not just because I am lazy, but things just got busier and busier.  Sell the house and move to Florida, take on new coverage territories, new products to learn and expanding coverage of identity and security in mobile and the cloud.

Not lazy, just busy. Very busy.  Since the breaches with Home Depot, Target, Sony, etc., security and identity have now earned a seat at the big boy/girl table in the enterprise.  Now have Platinum status with several travel services now.

But now is the time to blow the dust off this blog and put it back in motion.   Customers are migrating to generation 2 mobile applications and considering moving identity and security functions to the cloud.  Lots to talk about.  This time I promise to keep this updated regularly.

Good to have you back.



Read Full Post »

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 »


Interesting question came up on an internal database security alias that I thought should be shared.

The question posed on behalf of a database customer was around seeding random routines.  Was it more secure to provide a seed to the random number generator routines or not?  The question was extended to say that if seeding the routines was more secure, what new security issues were introduced in storing the seed values used?   To seed or not to seed, that is the question.

In this particular case, the answer is NOT to provide the seed the database random routines in production.  Seeding is similar to the cryptographic concepts of salts and even nonces, but within databases, it is used slightly differently.  In the Oracle DB world, generating a random numbers are the domain of the DBMS_RANDOM package.  It specifically states it should not be used for cryptography.

Like salts and nonces, a seed is used to add some increased entropy to the generation of random values.  Computers, for all their advanced capabilities, are still psuedo-random generators, not pure random generators.  Given the same input, they will generate the same output.  So to add some additional complexity to the random number generation to make it appear more a true random number, the DBMS_RANDOM routines allow the developer to “seed” any random number calculation. So one would think adding a seed to the generation would make the overall system more secure because the seed would better enhance the randomness of the pseudo random generation.

But, by supplying this seed to the calculation, the developer now introduces an added security complexity.  Where to store the “seed” securely between calculations? It is in effect a secret key if used (inappropriately I might add) to encrypt or protect information in the database.  Even with the documentation saying to do this, we have seen this done again and again.

What most developers miss is the DBMS_RANDOM package is a random package, not an encryption package.  If one does not supply a seed to the random number generator, the routine creates a random seed on its own, based on userid, date, and process id.  Not a truly random seed, but does add some entropy to the random generation.

In fact, the reason the routines allow the code to pass a seed instead of random generation of the seed is to allow testing.  By passing the same seed to the random number generator, you get the same random number back, which allows testing across runs.  As long as the seed remains fixed (non-null) the random number generator will pass back the same number. So, the thought that adding a seed to the random number generator to improve randomness actually fixes the generator to producing the same number, not a random one.  Plus, you have a security problem of where to store the seed.

So the answer is NOT to seed the routine in DBMS_RANDOM, but let it generate its own “random” seed when called. Remember, this discussion is around this implementation of one random number generation routine in an Oracle database package and should not be applied to other random number generation routines. But be dutiful of the seeding documentation.    Also, be aware that if you are using random numbers to do cryptographic encryption, you need to be sure the random routines are strong enough to insure the resulting security is trustworthy.  You need to use cryptographically secure routines. Not all psuedo-random routines are designed with that in mind.




Read Full Post »


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…..


Read Full Post »


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:

Read Full Post »

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.

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 »

Older Posts »