Learning Databases
-
Learning Databases
For any DBA, protecting your data from unauthorized access is becoming more and more important. However the job becomes more and more complex all the time as hackers get more sofisticated and employees. But maybe a new technology can help as it learns about your databases. Specifically it learns about access patterns and and can detect deviations.
This is a great implementation for security in that it can help secure the databases not only from outside attacks, but also inappropriate inside access. Since your normal, internal user access patterns are analyzed as well, they can be watched for suspicious activity. A good example of this is seeing someone who has rights to access the SQL Server, such as an administrator, query the salary or bonus table when they have never done this before as part of their regular access.
But this technology is only part of a security system. Having a flag raised on some access that deviates the pattern isn't enough to determine if the database is being attacked or data compromised. Instead it's just enough to point someone in the right direction.
This is really a way to create a work queue for the security folks and give them a direction in which to start their investigation. Any questions raised by this system need to be investigated to be sure that there really is inappropriate access going on and no one in wrongly accused of anything.
Security is becoming a tricky business and most of the difficult parts are less technical and more administrative as we deal with the ever growing list of privacy issues. If you're a DBA, especially one working in a production environment, your skill set needs to expand to meet the needs of these challenges.
Steve Jones
-
I'm still just trying to do good database design and keep data available for the users that need it. This security business is another big issue...
-
Learning the database means learning the business. If you don't understand the business, it is hard to design a good database. Also the management has to understand designing the database is not easy. Somtimes the users just want the result fast so the developers just created something fast to satify the customers.
When I worked for a telecommunication company (long distance telephone) company, my boss told me to create something fast (he gave me two days) to capture the traffic of the incoming calls and outgoing calls, and wrote a procedure (a report), he said it would only run for a month. So I did not put too much thought and got the report done. In the procedure I hardcoded a lot of things. The database was poorly designed. I thought so what it would be done in a month. Well, the users liked the report so much, it ran for three years, did you know how much work I had to put in to maintain that piece of garbage? I could not ask my boss to re-design the whole thing.
Security is a big issue especially if the database is used by the web pages. We hired some hackers to hack the the web pages. It was so easy to break into the database and changed the data.
For internal users, the DBAs tried to set up role based security to prevent certain people to look at certain tables in production. They also prevented developers to update the production database. Guess what, it took me no time to break into the production system !!! The DBA group in my previous company hated me. The DBA manager complained to my manager. Hey, if you cannot do your job to protect your database, it is your fault !
-
I saw a demo of a product that did exactly what you are talking about here. It was very cool, would love to get it into out budget
-
Isn't this just the same thing that credit card companies have been using for years? I know I appreciate it when they call me with suspicious activity. It's always me just being weird, but at least they notice.
-
But security is one of the first steps in good database design. It's not something you can push under the rug and deal with later. The whole system has to be designed with security in mind. Then the security features must be built in at each part of the system, while you are building it, not sometime later "when we get around to it". Otherwise, the one little hole... that's the one that will be exploited.
-
use spellcheck
-
Yes, indeed. This is something which I try to get developers to understand sitting in an infrastructure architect position. If you don't design security in at the start, retrofitting security after a bad audit may be extremely costly to the company. This means securing the data using proper access controls at all levels, running with least privileges, doing proper input validation, etc. If this isn't done at the outset, it may not be possible without a complete rewrite later.
K. Brian Kelley
@kbriankelley -
I wish this was something they had taught me in school. Unfortunately, they didn't really get into databases at the undergrad level, so I never got as strong of a database starting point as I had hoped. Mr. Kelley is right - security definitely needs to be considered at the start or it can be troublesome to add afterwards.
I have a program that I wrote when I started with this company 3 years ago. Security though and tracking functionality wasn't put in, as the users didn't spec it and I was too new to even program it in. 3 years later, I now know what they're looking for but it'll be tough to retrofit it in.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply