My organization is trying to build out its security capabilities, but every vendor seems to make promises bigger and better than the last, particularly when it comes to how their products will work with what we already have in place. We'd like to create a security checklist that highlights what we already have and how vendors' claims stack up against our needs. Can you provide advice on getting started on a vendor security checklist?
Ask the Expert
Have questions about enterprise security? Send them via email today! (All questions are anonymous.)
The gospel of information security has a common saying that is often talked about, but rarely followed: It is easier to build security into a system than to bolt security onto a system after it has been installed. Infosec pros often find themselves in this position when their business acquires a new application without considering the security requirements. For example, I have seen financial systems that store passwords in clear text and medical systems that transmit patient data without encryption. It is vital to evaluate these types of potential security issues before the system is purchased. That is the promise of building a security requirements checklist, but how should organizations start the process of creating a list?
The first source I use I'm beginning to build a security checklist for vendors is previous application vulnerability assessments. I often find that application vendors continue to make the same mistakes habitually, such as embedding passwords, missing operating system and database patches, and utilizing insecure remote access methods. (My personal favorite is HVAC contractors who want climate controls exposed to the Internet.) These assessments contain invaluable insights into what to evaluate before selecting and implementing an application vendor.
Next, I consult the corporation's compliance requirements and policies. The checklist should have a corresponding standard for each required compliance specification. I often work in the realm of the Health Insurance Portability and Accountability Act, so my checklist includes items like individual user identification and encryption of data in transit and at rest, though each individual organization must take its own environment into account with this exercise. For example, there may also be policy requirements from the corporation itself involving the protection of intellectual property, which should also be included in a vendor security checklist.
There are many more sources for this type of information, such as National Institute of Standards and Technology guidelines, Computer Emergency Readiness Team resources and Microsoft security recommendations. The best advice I can give is not to wait to implement a checklist until it is perfect -- organizations should start this process as soon as it is feasible. A checklist may start small and expand as an enterprise builds experience through each application assessment. Rather than waiting to bolt security on, it is more important to get a checklist into place and begin building in security.
This was first published in October 2013