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

Disrupt or Be Disrupted!

As competition in the free market increases every day - business models and business strategies continue to evolve. Innovation will drive disruption in business models from players that will disrupt the current practices of existing business's in order to create a niche in the marketplace. The challenge for existing business's is to continue to disrupt or die in this game. Famous examples of a disrupter was Netflix who with its innovative web content streaming for movies, TV shows and a robust supply chain resulted in the closing down of traditional movie rental shops like Blockbuster and Hollywood Video. However players like Amazon, Hulu, Google have entered in as disrupters in this space threatening the very disrupter (Netflix) and stopping their march of web-media delivery domination. It seems like it is a familiar pattern the disrupter comes into the market with an innovation, flys high for a while and then gets disrupted with evolving market and technological changes. As a CIO I feel the pressures of evolving strategies, changing the game plan from time to time (though it makes your internal staff and management discomfortable) I believe it comes with role to warn colleagues of "conventional thinking. CIO's have to recognize when competitive strategies (tested and proven) can become inherent weakness. This inherently becomes a pattern of thinking that develops over the course of time as management gets into the practice of "this is/was always the way its done here". This creates myopia and inertia that brings the organization's to complete stand still. CIO's who confine their interests and practices only to leading technology and improving business processes will surely not make any significant impact in their tenure. They need to constantly have an entrepreneurial spirit, have the ability to tinker and experiment, know the heart beat and pulse of your customers and stakeholders and reduce unhealthy interdependencies. The four things I just mentioned need to be taken apart one by one:

Entrepreneurial Spirit: This is the ability develop a peripheral vision where if we can help the bottom line by distinguishing yourself with a innovative product or service that brings value add you will survive and thrive. For example when Walmart couldn't enter the financial services market as a regular bank they joined hands with American Express to create Bluebird credit cards.

Experiment: Top managers who allow for experimentation encourage innovation. The Post It note innovation at 3M, or the ad's appearing in Google Mail are examples of management allowing for experimentation. It is to recognize that most of them will fail but some will succeed. It's about allowing for a culture of trying out different things and then measuring what worked and what didn't.

Know the heartbeat of Your Customers & Stakeholders: When you have middle players or vendors that separate you directly from your customers or stakeholders either build mechanisms that give you good feedback or eliminate them so you can avoid not knowing what your customers or stakeholders. You cannot afford this.

Eliminate Interdependencies: If you have business partners who are in the same field avoid the interdependency. For example Netflix has all its content delivered through Amazon cloud services, now that Amazon has entered the same space the interdependency is not good. Google had to delink from Apple because they want to be major dominant player in the mobile space. Avoiding interdependencies in your supply chain is also very important if a supplier is threat or in direct or indirect competition.

Thoughts for today,

Sam Kurien