Preventing Your Database From Getting Hacked: What to Ask Your Software Vendors Right Now If I Were You

March 13, 2014
Kevin Lam

US Navy emblemIf you’re worried about your data getting hacked in 2014, you should be. I read an article about the Navy’s database recently getting hacked because they did not receive proper updates from their software vendor which exposed them to SQL Injection attacks. The glaring lesson from this report is that if you don’t know what to ask for security-wise from your software vendors, then you can’t expect protection.

Not everyone is a security expert. So, in this article I am going to be your security expert and give you the best practice defenses for SQL Injection that you can copy and paste right into your software vendor contracts. That way what happened to the Navy doesn’t happen to your business in 2014.

What I Would Require In My Software Vendor Contracts If I Were You (Copy and Paste These)

As the co-inventor of the Anti-SQL Injection library, here’s the minimum of what I would have in all my software vendor contracts to reduce risk from SQL Injection attacks if I were you. These don’t constitute formal legal advice, but they are sound software developer best practices that you should require. They are:

Input validation: All un-trusted data used in the construction and execution of dynamic database queries in applications must be validated using white-list or positive validation prior to use.

 

Parameterized queries: All database access using dynamic queries must be implemented using parameterized queries or prepared statements.

 

Parameterized stored procedures: All database access using stored procedures must be done so using parameterized stored procedures.

 

Least privilege deployment: All databases must be deployed using a limited set of security privileges, not to exceed the privileges required for the correct application functionality.

 

Defense in depth implementation: All database-driven applications must implement multiple controls to reduce the risk from SQL injection attack, such as input validation and parameterized queries combined.

Get Ready to Call Bullsh*t

If you ask for the above in your contracts with software vendors, I can guarantee that most are going to b*tch and moan. A lot. Expect the “this is going to add complexity” or “this is going to require additional resources” card (especially if they aren’t already following those best practices).  I call bullsh*t and you should too, here’s why:

  1. These are basic 101 developer best practices:  Psss … those best practices I indicated earlier is basic developer 101 material by today’s standards. Highschool students are learning about these right now in programming class. So, if your software vendor isn’t already following them, or willing to then I would question their ability and desire to protect your data.
  2. Without them you have no recourse: Without these in contract (as the Navy found out), if you do suffer a loss you will have little to no recourse.
  3. You’re not asking for the moon: You’re not asking the software vendor to guarantee that they/you won’t get hack, everyone gets hacked eventually. You’re just asking that they follow best practices to reduce the risk which is perfectly reasonable. If that causes a stink, then again, I would question their ability and desire to protect your data.

Alright, that’s it for this week’s Data Protection Friday article. Happy Friday and thanks for reading,

Kevin Lam signature

Kevin Lam, Co-Founder and CTO