Honeytokens: The Other Honeypot

martyros writes "I just read a fascinating article by Lance Spitzner securityfocus.com about a concept he calls honeytokens. The idea is similar to that of a honeypot, which he defines as "an information system resource whose value lies in unauthorized or illicit use of that resource". Rather than having a computer that's designed to be broken into, however, you have say, a record in a database or a file has no legitimate use; ergo, if anyone uses it, it must be illegitimate. An example he gives: adding a record to the hospital database for a guy named "John F. Kennedy". It doesn't correspond to a real person, so no one has any business looking at the file. If someone does access it, you know that they're abusing their privileges somehow. The article has several other clever examples, which I found very thought-provoking."

Comments

Or they made a mistake

[buffer-overflowed]

Or there's a flaw in your software.

Or they were poking around bored.

Or you've been hacked in which case you won't have an access record anyway if the hacker did their job right.

Yes, quite superior to a honeypot, in every way.

Re:Or they made a mistake

[in7ane]

I agree, it's just too likely that it will be people from within the organization just 'poking around' with no ill intent.

It's just human nature - same as having to open a box with the sign 'do not open' on it :)

Add to this that authorized workers will likely be told about these and told to keep out - causing a flood of 'I wonder what's in there...'

Re:Or they made a mistake

[highcaffeine]

I was going to mod this down (overrated), but decided I'd rather reply.

No one said that honeytokens are superior in every way to honeypots and should be used in place of the latter. That you pulled out of your hindquarters. Basically, what you said could be expressed similarly in this example: "Seat belts are not absolutely superior in every way to the steel frame of a car, so what's the point in buckling up?"

I would hope that makes it clear how faulty your logic is. Like using seat belts in addition to a protective steel frame, to provide added protection, honeytokens could be used in addition to honeypots. Their ultimate goals are the same: protect your life (frame/seat belts) or your data (honey[pot|token]). If your life/data is that important, why not provide all the layers of security you can?

One advantage that honeytokens do have is in who they can help protect against. Honeypots are typically deployed to detect and help figure out how to protect against external threats. Anyone with a shred of sense about security knows, however, that you also need to protect against internal threats. Deploying honeytokens can help in that vein, by posssibly detecting internal abuse of your systems.

Just because honeytokens won't protect against everything, solve global hunger, and bring about world peace, doesn't mean they shouldn't or can't be used effectively.

Re:Or they made a mistake

[dasmegabyte]

Ok -- I think this isn't necessarily a bad idea, so long as you don't expect it to be the end-all, be-all of security. I often perform wierd ad-hoc queries on tables for data mining purposes, or to help our support team do things that their program just won't do (like cross index reports for a list of ids).

Some DBAs LOVE to think that their precious data is only access the way they want it to be accessed. I once had a guy tell me, flat out, "You guys should never be doing ad hoc queries. Write and submit a stored procedure for everything you do." I have never heard a more ivory tower asshole statement in my life, and you better believe I didn't listen for a second. Nor should I have, nor would he really want me to...when the CEO comes over and asks for usage statistics for a potential customer, he doesn't want to be told "Wait until the DBA shmuck reviews this query first." It becomes harder to justify your excessive salary when all you do is prevent us programming peons from doing our job and call it "security."

If I pull up a honeyrecord, and you're my dba, you should ask me about it, but not assume my account has been hacked and lock it down. Which means this is nothing more than yet another check measure. You'll still have to eye your logs and know your system.

You know, this is actually a great way to prove somebody from outside has been data mining, and prosecute them for it. Put bullshit data in your db. If it shows up on somebody's website as fact, you'll know they were grabbing your shit. Producers of maps do similar things...invent dead end streets and place them where nobody will ever try to go. If you look at somebody else's map, and you find your BS street, you know they plagarized. Just make sure you never buy a house on that street. Heh.

Re:Or they made a mistake

[IWannaBeAnAC]

Maybe, just maybe, in a hospital database I would agree. But there are many fields where you would want people to notice and flag suspicous looking records.

Even in the hospital example, what would you do if the office worker noticed something was wrong? Say, there was an obvious typo or something like that, potentially serious if nobody notices. Do you want the worker to be afraid of reporting it?

While I can see the obvious abuse, poking around stuff that you wern't specifically told to poke is the stuff of legends, it would be a shame if society evolved into a "no permission means no look, no touch" attitude.

Sure, I can see that honeytokens can (and are - after all its just a version of the old 'put a marked note in the safe' trick that has been used in one form or another probably forever) be really useful - but it isn't a replacement for TRUST. I wouldn't want to see this applied universally, especially on public networks.

Re:Or they made a mistake

[dasmegabyte]

God, it's assholes admins like this that give IT a bad name...and are probably the reason why so many jobs are getting outsourced. I mean, why keep around people who think it's their job to be a beligerent elitist and in the process stop everybody else from getting their job done? I didn't think Nick Burns was a funny character at all...I thought he was a sick composite.

Listen. Management doesn't mean discouragement. It does not mean banning a person from doing what they need to do because you're too fucking lazy to make it safe. There's a huge difference between indescriminately giving somebody root and letting them run select statements in a database or on a particular set of tables. It's the difference between giving the inventory guy the keys to your warehouse, or letting him run around INSIDE without hassling him every five minutes. I used to work for the records center for the NY Department of Criminal Justice, and they didn't run as tight a ship as some of the UN*X admins I've known. That's because if they denied access to everything like some sysadmins, the "runners" wouldn't be able to pull what they needed, and law enforcement would suffer as a consequence.

Besides, as much as you like to think of it as such, this isn't your system. You may be in charge of it, but chances are you don't use the thing. The customers do -- the customers and the staff who serve them. You may be in charge of it, but you have no ownership over it. You're in charge like the custodial staff is in charge of the toilet.

You can keep the bad guys out of the building with your firewalls and your routers and your proxies. You can keep the idiots in house out of the sensitive shit, back up the data every 17 seconds and dust everybody's keyboards at night for unknown fingerprints. Hell, you can even come up with some cockamamie password policy, like i have to have at least one korean symbol in my password that changes bihourly. Do whatever makes you feel like you actually know dick about security -- just don't keep me from doing my job. If I can't run a query for a troubled customer, we've lost business. If you have to monitor one extra user account for suspicious activity, we haven't lost anything. Not only is creating potholes like this counterproductive, it also doesn't improve security in the least. I've never known an "exploratory hacker" who cared a whit about getting access to a person's read only accounts when it's often just as easy to get root. Why eat hamburger when you can eat steak?

The problem...

[melete]

The problem with this (and with a lesser degree, with honeypots) is that these tokens will get accessed in legitimate ways -- for example, what if your secretarial staff is creating a mailing list, and "JFK" gets sent something? Or you have a browse function in an application that uses the database?

It's a good idea, but not a panacea.

Re:Sorry-ass bosses.

[pla]

When the Boss steals, it's big-time, way more than any of you make in a year at your salaried job.

The big guys don't need to steal to drain the company. The laws (and corporate policies) allow them to do things the rest of us would spend hard time in the federal pen for.

As a trivial (though not unusual) example, at my previous job, the CEO made a bad call about handling a bug in a customer's software. Relatively minor bug, but due to the nature of the software, he and the company might actually have had to endure criminal proceedings if they handled his bad call poorly.

So the solution? He left the company with nearly a ten MILLION dollar parting bonus, sort of vaguely admitted responsibility, regulators considered the matter suitably dealt with, and the problem went away.

Think about that... This guy broke the law, so they gave him millions of dollars.

And some folks wonder why so many of us outright despise corporate America.

As Eric Idle once said, after killing a dozen or so tribesmen in Monty Python's "The Meaning of Life", "Back home they'd hang me, but here they gimme a fuckin medal!".