Cleaning Data

We spend a lot of time and effort trying to clean data. Anyone who has worked on ETL (Extract, Transform, and Load) has wrestled with trying to get good data for downstream systems. Maybe this sign is appropriate after all. 

Advertisements

SQL Injection Vulnerabilities Are Still Alive and Well

SQL injection has been around for a long time. One would have hoped that with it having been around so long, that we would have eliminated it as a vulnerability in our applications. This is especially true for financial sites on the Internet. Unfortunately, the reality is that we’re still dealing with it and big stories keep coming out. For instance:

PC World: Qatar National Bank claims customer data released by hackers is authentic

Keep in mind that from an architecture perspective, the primary place to stop SQL injection attacks is by validating the input when it comes in. If the input doesn’t match appropriate patterns, especially in the case of a banking application where the likely patterns for each input should be easily defined, you reject it at that level. It then doesn’t get appended or inserted into a text string which becomes┬áthe SQL statement to be executed against a database server.

If you don’t get it at this level, the ability to prevent the SQL injection attack gets much harder. Perhaps IDS/IPS can detect based on some text matches. We might be able to do the same thing within the database, say by using DML triggers. However, if the appended text generates queries that are basically what normally gets sent back, none of the back-end solutions are going to be very effective.

Also, keep in mind that there are plenty of tools out there that helps the adversaries. For instance, the Qatar National Bank attack used an open source SQL injection tool to accomplish the hack. So the adversaries don’t have to be exceptionally skilled to pull off an intrusion. Therefore, that means more and more folks are capable of these sorts of attacks. Not a good trend for the good guys.

Upcoming Webinar: Top Down SQL Server Security

On Thursday, May 12, 2016, I’ll be presenting a webinar on top down SQL Server Security. You can find the webinar info here. This is a new presentation I’ve put together, looking at how to build a security architecture in SQL Server around a new application or system. Here’s the abstract:

Security, when possible, should follow the KISS principle: Keep It Simple, Stupid! The more unnecessarily complex security is, the more likely for a weakness or vulnerability to work its way in. Therefore, it’s best to start looking at security from the top down. Going the other direction tends to leave us overwhelmed in the details. 
In this presentation, we’ll look at SQL Server security from the top down. We’ll consider particular scenarios that come up often in deployed systems and talk through how to implement security using the various options we have available: Windows users and groups, SQL Server logins, server and database roles, and object-level permissions. By covering these examples from a top-down perspective, we’ll be able to delineate our security goals and work towards the best way to implement them. Our scenarios will include examples from 3rd party application deployments as well as home grown solutions.

If you’re interested, the webinar will be held at 3 PM EDT. You can sign-up to view the webinar for free.

Slides from SyntaxCon

This past Saturday, May 6, I had the opportunity to speak at a new conference, SyntaxCon. This is a developer-centric conference located in Charleston, SC. If you weren’t able to make it this year, it looks like next year is a go. As soon as I have official word of that, I’ll post on here.

If you attended my talk and wanted a copy of the slides, they are here:

Syntax Talk on Back End Data Security

Thanks to those who attended!