Sep 11 2007
By Jim Reavis
(Editor’s note: This blog entry was originally posted to The Entitlement Management Blog at www.entitlementblog.com. If you are interested in XACML and more generally understanding how we can deploy enterprise applciations with more sophisticated and granular security controls, please go to The Entitlement Management Blog to learn and contribute.)
Without a doubt, the best part of my job as a security wonk is to listen to the war stories. Listening to how one bright but flawed person subverted several layers of security controls and stole information and usually money are very instructive. Understanding the security gaps that were exploited, how the forensics investigators cracked the case and the resultant control changes are like getting thousands of dollars of free consulting for the price of a single tall latte. You also sometimes can’t help but admire the ingenuity of a single person who succeeded against a Fortune 500 corporation’s security system, but then I wake up and remember that it could have been my data (and in some cases, probably was). There are many different lessons to be learned from these incidents, but one thing I can definitely say is that depending on your business application to protect you from a fraudster is foolhardy and hard-coding entitlements into the application is a bad idea.
What follows is one of those war stories. It is true, names and minor details were changed to protect the embarrassed. A large consumer products company (let’s call them BigCo) offers rebates on a regular basis as a sales incentive. I can hear many of your teeth gnashing already. Rebates lower the price of that gizmo so that it fits your budget, but the DNA sample and book report you have to submit is definitely a disincentive to claim it. Even when you do submit the forms, you might forget about it and throw away the check with the rest of the junk mail. As a result, billions of dollars in rebates go unclaimed every year.
Enter the fraudster, an employee of BigCo who works (or I should say worked) in the rebate department. The fraudster sees this unclaimed money and hatches a plan based on knowledge of how the process works. The fraudster sees this process:
1. Rebate vouchers are entered into RebateApp by Rebate Specialist I
2. Rebate Supervisor logs into protected screen in RebateApp to approve rebates for payment.
3. Rebate Specialist II logs into RebateApp to generate check mailing file and securely transmit it to check processing
4. Rebate Auditor logs into protected screen in RebateApp to make sure rebates were processed properly
The fraudster was not a genius, but had an understanding of the process and some skills in manipulating a SQL Database and added a few steps.
1. Rebate vouchers are entered into RebateApp by Rebate Specialist I
2. Rebate Supervisor logs into protected screen in RebateApp to approve rebates for payment.a. Rebate Fraudster performs SQL query to download check mailing address list
b. Rebate Fraudster uploads new check mailing address list with many of addresses changed to his sister’s apartment3. Rebate Specialist II logs into RebateApp to generate check mailing file and securely transmit it to check processing
a. Rebate Fraudster uploads the original check mailing address list to the SQL Database
4. Rebate Auditor logs into protected screen in RebateApp to make sure rebates were processed properly
A nice scam. The fraudster was eventually caught, but the RebateApp did not prevent him from carrying out the plan or play a role in catching him.
This type of event, which I am convinced is carried out everyday in some form or another, is a prime example of why enterprises need the loosely couple XACML architecture to enforce authorization and create entitlements to enhance application security following the least privilege philosophy. No amount of application hardening would have helped stop this fraudster. The RebateApp audit logs looked absolutely normal. XACML Policy Enforcement Points (PEP) can be used to channel requests to the database and protect it from unauthorized access, either from an application with insufficient security controls, or from a fraudster bypassing the application to query the database directly. Databases can and should have business rule logic within them, but all the very granular entitlements businesses need to create stronger internal controls against insider threats scream out for XACML. The database server and its DBA can work closely with the XACML components to ensure that a coordinated effort is made to control access and that direct access to the database like this fraudster attempted does not work.
Another tip I have for you is, if you did send in the DNA sample and you are waiting at the mailbox for your rebate check, treat your local forensics expert to a latte with your check – the war stories are worth it.
Related posts:
Posted by Jim.Reavis on Tuesday, September 11th, 2007, at 8:44 pm, and filed under Articles.
Follow any responses to this entry with the RSS 2.0 feed.
You can post a comment, or trackback from your site.
Post a Comment