During the “sales romance,” when software vendors are showing off the bells and whistles of their product to the ooohs and aahhhs of management, it’s a challenge sometimes to be the “wet blanket” of security reality.
All too often, executives make software purchases without any regard as to regulatory requirements, security best practices or implementation costs. It’s my job (and yours) to educate and ask the hard questions, preferrably BEFORE they shell out the big bucks, then bang their heads against cost overruns due to requirements, implementation of add-ons and customized product.
Once you’ve signed the software contract, it’s way too late to ask questions. You need the sort of answers that will give you some assurance that the software vendor is committed to writing secure code, cares about writing secure code, and invests in the time and training of their staff to ensure their product can provide the right information about what their software does “under the hood.”
This should be a part of the “due diligence” organizations perform before making software purchases. It’s more important to your company, in the long run, than the financial solvency of the software company. A great company writing bad code is a higher risk than a shaky company writing excellent code.
It’s also a great time to see how mature the software company is in terms of software development practices. “Real” software companies have code storage, written documentation of process and practices, as well as defined QA testing. Beware of a company that may say they have all these things, but have nothing in writing.
1. Where is security in your software development life cycle? (If they don’t know, or have to go look, be careful)
2. Do you test your software for security vulnerabilities? What do you use to test your software? Can I see the latest report? (kudos to them if you can see it. If they don’t test, you’re buying a pig in a poke)
3. If there is a database, do you have a security design for it? (Try to find out if they’ve basically opened up the database with one application ID that can do everything – cheap and easy coding. Cheap and easy to hack, too)
4. If this is a web-based application, do you provide documentation on how to install your application securely? (Watch for the ones that use a “default installation” of a web server to load their application on. It’s likely that if you secure the web server, you’ll break their application.)
5. What kind of logging and reporting does your application do? (You’re looking for good reporting on WHO, WHAT and WHEN. You’ll need this for your auditors, too)
6. How quickly will you test Microsoft patches so that we can patch? (This is critical; you don’t want to have a vulnerable server hacked because they don’t want to test, or be put off with promises of the next upgrade. Make sure they test for IIS, SQL and/or any other specialty the application uses.)
These are the kinds of questions that software vendors need to keep hearing, so that they know the customer cares about security and won’t buy a product that isn’t secure. Plus you’ll weed out hundreds of hours of pain and aggravation. It’s a “win-win.” For you.