Vendor Management for Application Security - Best Practices

Managing enterprise risk in organizations is getting complex every day as 65% - 70% of software's used by an organization are from outside vendors. The ecosystem's of vendor-supplied software ranging from desktop applications to cloud solutions and in between all of the heterogeneous mix of applications used to manage the enterprise's network increasingly demands that CIO's  take care of Governance and Risk Compliance practices seriously. Yet the amount of man-power required and capacity in existing IT staff is less than ideal with all the stuff they are asked to do on a daily basis. We live in an age where vendor supplied applications run the operations of a business with heavy exposure for the organization towards security vulnerabilities, liabilities and risk.


A PWC study I read in 2012 said that less 1 in 5 enterprises conduct security assessment's on their vendors even when an average typical enterprise may carry 300+ vendor applications in their enterprise portfolio. Also right now as I go through the requirements of PCI DSS, SOX and HIPAA mandated privacy and security controls it is shockingly painful that organizations are liable to extend their security controls on vendor supplied applications for compliance and policy requirements.Ultimately as requirement states you are responsible not your vendor!

It is true enterprises have traditionally lacked the efficient methods of analyzing security of the applications vendors provide... but shouldn't there be a process put in place (as most organization's IT shops don't have IT staff or margins in time) to sufficiently whet vendors and applications before they are deployed in the organization. Some thoughts I have in terms of what can become best practices would be to manage vendors and put a process in place for security audit of applications better would be the following: (I am aware loads of this has been written on vendor life-cycle literature's but these observations come form possible improvements I am trying to make in my little world)

1. First of all  take an inventory of Vendor Applications in your organization. Streamline the vendors and minimize inter-dependencies. This way also minimize the number of vendors if possible.
2. Create a vendor matrix which assigns assurance levels based upon critical-ness  of that application and its need in the enterprise.  Some call this Assurance level of what are up times based upon the importance of the application. A simple example would be email - which means your exchange server needs to be up 100% of the time or if you are using an external cloud provider like Google mail - from a SAAS based provider what is assurance levels they provide. For major players this may not be a problem but if you are using smaller shops this may be a significant consideration as you construct your vendor matrix based upon high need of applications against it assurance levels.
3. A security policy team that invites members from other areas of the organization that have a primary say and know how's/why's of the software solutions they constantly use should be part of the vendor evaluation process.
4. Determine ahead of time what type of security testing your system admins' are going to do for deploying or procuring of the said software application.
5. Can the primary users of the software that form your evaluation team create a report from their perspective of  +'s and -'s of the software.
6 .Finally make notes of the track record of your vendor's  in terms of support maintenance, price negotiation and other value add information they give in a timely manner regarding licensing, new features, training security alerts etc etc.
7. Ask the vendors for test reports, vulnerabilities past, present and future, remediation, fixes made by the vendor development teams.
8. Evaluate all software vendors at least four months before your budget cycles and get long term commitments (3 or 5 years if possible).

These steps are not rules but some common observations I have made in terms of practice.

Thoughts,

Sam Kurien