addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwchatcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobegmailgoogleimageimagesinstagramlinklocation-pinmagnifying-glassmailminusmoremuplabelShape 3 + Rectangle 1outlookpersonplusprice-ribbonImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruseryahoo

Re: [sfmysql] Potential March topic: FU DB

From: user 1.
Sent on: Wednesday, February 27, 2013 11:04 PM
I'm interested. Might even be able to contribute time permitting.

On Wednesday, February 27, 2013, 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