September 24, 2006 at 4:01 pm
Data Breaches
It's almost a weekly news item. A data breach occuring somewhere in the world that means a large group of people suddenly needs to be concerned with identity theft. Apparently there's a comprehensive report from VISA on the top 5 causes and most of them affect the DBAs out there.
While I'd say that developers are the ones that need to avoid storing data on a card's magnetic stripe, the other four issues are ones we can help. And they're common sense:
All simple, common sense, best practice, and what should be required practices in any development project, much less one dealing with financial data.
Security is a tough business and most people don't want to deal with it. Most compromises are non-technical, meaning some human is involved in the loss of data. Usually this is through corrupt employees or social engineering. And it should stay that way.
There's no excuse for not being current on patches. Maybe not up to the minute because after all, we need to test them, but you shouldn't be six months behind either. And you shouldn't default accounts, passwords, services, etc. unless there's no way to disable them.
Security is a process and you should be constantly working on yours.
Steve Jones
September 25, 2006 at 5:04 am
Data breeches? Like Sander Berger wore?
September 25, 2006 at 7:09 am
Do you mean Sandy Berger?
http://en.wikipedia.org/wiki/Sandy_Berger
🙂
-------------------
A SQL query walks into a bar and sees two tables. He walks up to them and asks, "Can I join you?"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html
September 25, 2006 at 9:35 am
Sandy socked it away in a sock
huffing & puffing and in a pant
A breach in the administration, an administrative breach
to each his own, but in a....BREECH ?!?!
got too big for his britches..was it the other way round ?!
with all these glitches, how will Osama ever be found ?!
**ASCII stupid question, get a stupid ANSI !!!**
September 25, 2006 at 3:52 pm
In SQL 2K, SPs are the culprit a DBA can control. However in SQL 2K5, there is now the "Pandoras Box" of "CLR" ...
But in reality Steve, as a DBA, I cannot avoid "SQL Injection" if the developers have not taken the proper precautions and done their jobs seriously.
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply