Posted by: Arian Eigen Heald
Admins and Auditors, Compliance, Data Breaches, Database, Database security, Development, IT audit, Security, Tools & Tricks of the Trade
In the course of many audits and pentests, I can’t tell you how many times I have found flaws and openings based on bad development practices. It’s downright painful. And yet software keeps coming out with the same problems. I know WHY this is happening, but I can’t stop it. YOU can.
Have you ever been in the position of having a software vendor say: “We’re not going to test that patch yet, you’ll have to wait for the next software release from us. If you patch it, we won’t support it.”
Or finding a security flaw in the application, reporting it to the vendor, and having them say they will charge your company to fix it as a “feature request.”
Or examining roles and rights in the database, and finding out everyone is sysadmin. Or better yet, the developer hardcoded his ID into the application.
I bet you have, and you know I have. Once the software is installed and in production, they have you over a barrel and they know it. Time to build a better barrel.
Time after time, I’ve found software applications that don’t secure the application user inside the database (giving that user rights to EVERYTHING). Why? Because it’s easier to code. You don’t have to spend time finding out what broke and fixing it when you lock user rights down. Some applications hardcode usernames and passwords right into the software so that it can never be changed (unless, of course, you pay for an upgrade). Even worse, I’ve seen it when the ID is hardcoded with a blank password. Why? It’s fast, cheap and easy.
How do YOU change it? Two ways:
First, raise management awareness so that you are at the table with the software salespeople to ask some hard questions. Is security part of their SDLC (Software Development LifeCycle)? Management can often be “wowed” by a product without ever looking under the hood. Ask how their product is secured, especially since it will probably be holding important data. Don’t be wowed by application level controls – get some hard answers on how the data is accessed.
Second, be there at contract time. This is the most important. Make sure it is written into the contract that they will fix all security flaws found in their product within 30 days. Make sure that they are responsible for testing OS patches quickly and reporting to you if it is OK to patch. Pick a timeline you can live with. After all, you’re paying them for a service.
If not, you’ll have to live with buggy code and I’ll have to audit it. We’re in this together.