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.