addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscontroller-playcrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobegmailgooglegroupshelp-with-circleimageimagesinstagramFill 1launch-new-window--smalllight-bulblinklocation-pinm-swarmSearchmailmessagesminusmoremuplabelShape 3 + Rectangle 1ShapeoutlookpersonJoin Group on CardStartprice-ribbonprintShapeShapeShapeShapeImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruserwarningyahoo

Re: [sfmysql] Potential March topic: FU DB

From: Jeff R.
Sent on: Thursday, February 28, 2013 12:16 AM
Definitely interested.  Would participate of this actually happens.
Jeff Rule
2121Peralta Street #A9
Oakland CA 94607
M[masked] |

A little sincerity is a dangerous thing, and a great deal of it is absolutely fatal.
Oscar Wilde

On Feb 27, 2013, at 10:56 PM, Solomon Chang <[address removed]> wrote:

My idea for a March talk is more actually a round table, about guarding your database from internal breaches.

During my time at BofA and Visa, I came across a lot of companies that suffered database breaches where lots of credit card numbers were stolen.  However, of the baker's dozen I saw, all of them were internal jobs. Somebody on staff, with database access (although not always root access) was inevitably tempted with some financially valuable data on his or her company's system.

The round table I want to put together for the March talk is how to design your database infrastructure when there is a mole on your staff, but you don't know who.  Sometimes, when you work for a very juicy target like a large credit card company, there are so many potential moles that it is just easier to secure the trash can than to set the traps, if you know what I mean. 

It's not just credit cards, either.  It is well known that many people use the same usernames and passwords across several services, and unscrupulous DBAs often will harvest large lists of their company's password hashes to test elsewhere.  Sometimes, the company you work for has suddenly become extremely unpopular in the public eye, and someone on your staff thinks that if he steals and publishes certain data from your DB, he will be lauded as a national hero.

I've done my share of setting traps and auditing, of tracking down moles, of obfuscating data - and I'm even giving a talk about it at Percona Live in April - but I'm just one person. All my methods, I've had to come with by myself over the years.  I can't be the only one.  There has to be other people in this meetup who were responsible for sensitive data and had to deal with potentially profiteering staff.

I'm putting out the call for other people who have had to deal with this.

I call this round table: FU DB.

Solomon Chang

Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Solomon Chang ([address removed]) from The SF MySQL Meetup Group.
To learn more about Solomon Chang, visit his/her member profile
Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]

Our Sponsors

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy