Skip to main content

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.


Sam Kurien


Popular posts from this blog

IT as a Innovation Partner in Business

Usually in Business organizations and especially in organizations where R&D is a separate department itself a tension persists on keeping the IT department away from any decision when it comes to innovation or process improvement. In short the IT department is generally seen as less of a help and more of a hindrance to innovation efforts. One of the main reasons is traditionally information systems are designed to impose structure on process, achieve pre-defined goals, produce metrics and minimize need for human interaction (in some case over maximize human interaction leading to nothing but "meetings").

While Innovation activities are highly unstructured and emergent, IT cannot be ignored or kept in isolation because IT can help in visualization tools, data mining efforts, uncover hidden relationships between data and create tools of knowledge management/information repository that so desperately is needed cross functionally but especially by the innovators within a org…

Analysis of SAP’s Platform Strategy

The software industry has been through high and lows up with the constant advent of new technological innovations and rapid changes in the global economic landscapes. SAP is the leading enterprise application software giant started by Hasso Plattner. The rise of Enterprise application industries started in early eighty’s with organizations needing one single software program that was capable of serving the multiple needs and functions of various departments. One single enterprise-wide application software means integrating applications that fused together for the smooth exchange and extraction of information. For example when customer services sold a product and got stock updated in the inventory by the warehouse people and the same data could be pulled by the Finance department. Enterprise Application software’s were designed exactly to do the latter mentioned processes seamlessly. SAP started by break away engineer’s Plattner and group build the company on strong engineering fort…

How Dashboards can mislead

Read an interesting article from John Shapiro professor at Northwestern Kellog on how dashboards can mislead executives and I cannot agree more. To be honest, I love visualization of data and have pushed my data architects and report writers to give me snapshots of various measures but how often the rich data didn't mean anything as it did not align with organizational goals. Even more, what information is important to me is not necessarily relevant to other executives in the organization.  Data analytics visualized on dashboards typically describe existing measures on past phenomena, some better ones predict future events and past data and the best one prescribe a course of corrective or strategic actions.

Shapiro talks about three types of traps executives can fall for:

1. The Context Trap:  We equate empirical data to the objective. I have blatantly used the cliche "numbers don't lie." But this belief can be dangerous because we can track wrong measures or metrics…