by Josh More
Publisher: Syngress
ISBN: 978-0124096073
Number of Pages: 95
Date Published: May 10, 2013
As I've noted in several previous blog posts, I believe the concept of Vendor Management is one of the weaker links in the security chain at many organizations. While this book doesn't necessarily show you everything you need to know to fix this problem, it does provide solid advice on proper due diligence for selecting vendors and products that you want to build a relationship with.
Josh More lays out a very practical framework for finding vendors that provide technology (products and/or services) that address the needs of your situation. More's Vendor Assessment process contains nine phases to help those responsible for evaluating and recommending solutions in Information Technology and InfoSec. The process is designed to help these individuals in fairly and quickly evaluating vendors, understanding how the vendor/sales atmosphere operates, and getting more value out of vendor contracts.
One of the biggest lessons I got out of the book was in properly defining the criteria used to assess and compare various solutions. By selecting specific criteria to measure each vendor, you are ensuring a fair and systematic evaluation so that the final decision can be based on a true apples to apples comparison and backed up with data. On page 17, More provides some great advice for deciding how many different criteria should be used in this process:
The limit is going to be the number of dimensions that you can hold in your head at any given time. This way, as you assess systems, you don't have to bounce between modes of thinking too much. This process, called "context shift," is a very common source of time loss when doing analyses. If you are running down a large list for each candidate, you have to constantly change your mode of thinking and every time you do, it will cost you a little bit of time. If your list is too short, you will be losing time thing of real-world scenarios that could be concerning but cannot be captured in your limited system.
More provides several examples to address this issue, ranging from the C-I-A triad to the CISSP 10 Domains. But I really liked the reference to the Parkerian Hexad on page 18, which is a short enough list to easily remember, but comprehensive enough to cover the majority of vendor/product assessments you will run into.
- Availability
- Possession/Control
- Confidentiality
- Utility
- Integrity
- Authenticity
I have to admit, this isn't the most exciting IT book out there, but I'm glad I read through it. All in all, this one is a quick read weighing in at just under 100 pages, but sheds some light on what can sometimes be a very ad-hoc selection and purchasing process.
In a recent blog post, Is Your Security Harming Someone Else’s Business?, Tripwire CTO, Dwayne Melancon, talks about mapping out the relationships your business has with other outside entities to "connect security to the businesses we depend on and those who depend on us."
This is a novel concept considering that many organizations have such a hard time mapping out their own internal processes, let alone ones that stretch outside their environment. One of the main points that Dr. Eric Cole discussed this year during his SANS 2013 keynote in Orlando was that when he has been called into organizations to do an investigation or analysis, the first thing he asks for is a network diagram and a list of locations of critical data. He then conducts a discovery of critical data on the client's network and maps out the true location of critical data to find that it rarely matches the client's list.
One of the questions that Melancon asks in his blog is, do you know what impact changes in your organization might have on contractual commitments with outside parties? Many times the people engaged in writing, reviewing and signing contracts within an organization do not have the level of technical understanding to know what good security practices are, let alone whether they are properly included in the contract. In the financial sector, there are regulatory requirements for this sort of thing (see Interagency Guidelines Establishing Information Security Standards)
Under the Security Guidelines, each financial institution must:
- Develop and maintain an effective information security program tailored to the complexity of its operations, and
- Require, by contract, service providers that have access to its customer information to take appropriate steps to protect the security and confidentiality of this information.
You Get What You Pay For (and Prepare For)
If the people writing and signing these contracts do not understand InfoSec, then this whole process seems a bit like going off a cliff and not knowing what's up ahead.
I was reviewing some BCP/DR
documents for a small financial institution not long ago and found a contract with a
technology service provider (TSP) that was storing off-site backups for them. The TSP provided the proof of breach insurance that was requested and it showed that the coverage limit was $1 MM per incident. That sure doesn't sound like much given the amount of money lost by small and medium sized banks recently due to phishing and account take over attacks which led to ACH/Wire Fraud. But then after taking a closer look at the contract, I found this statement in the section titled "Limitation of Liability":
"If VENDOR becomes liable to the CUSTOMER under this Agreement for any other reason, whether arising by negligence, willful misconduct or otherwise, (a) the damages recoverable against VENDOR for all events, acts, delays, or omissions will not exceed in aggregate the compensation payable to VENDOR […] for the lesser of the months that have elapsed since the Operational Date […]"
Say what? [Unnecessary Risk]
Somebody obviously didn't take the time to read this garbage before whipping out their John Hancock. Let's just say the amount paid to this vendor each year is much less than the value of the data the customer was backing up with this vendor.
Managing the security of interconnected systems is not just an IT issue. It is a business issue which means taking the time to read and understand the contracts that your business is agreeing to abide by. Does your company have a process for reviewing contracts? Is your IT/InfoSec team involved in that process? Are contractual requirements communicated to your IT/InfoSec teams? If you are missing these steps, then it will be impossible to do any sort of impact analysis across interconnected outside entities... just say'n.
While working on deploying an update to a software application by one of the vendors I deal with on a regular basis, I was given a document titled "Pre-Install Handout". (Well, I'm not really that crazy about handouts. Most of the time I believe in earning my keep. Anyway...) At the top of page three, there is a big yellow triangle with a bold black exclamation mark next to the following text:
"Domains: If the [server] machine is to be placed on the [customer] domain, [vendor] must have complete administrative rights to that machine.
There should be absolutely no security restrictions on making changes to that machine. If the domain security interferes with the [server] machines operations; it will have to be removed from the domain."
Dear vendor, if you can't get your software to work with the security settings of our environment, then it is probably time for me to start looking for a new vendor.
This is the same vendor that a couple of months earlier, I sent a request asking for a copy of their SSAE-16 reports and financial statements so that I could include the documentation in my vendor management program file. The response I got back:
"Though [Vendor] does have products that fall under the requirements of a SAS70 audit, because both [Product A] and [Product B] are considered in-house products for our customers (no data is stored on our servers here), it does not apply in this instance.
I have attached an FAQ that further addresses your request. As a point of mention, both the [Product A] and [Product B] divisions of [Vendor] share a facility with the [Product C] division and though we are separate products, we are bound by the same facility and information security management as addressed in that product’s SAS70. Let me know if I can provide any additional assistance.
The SAS70 report appears to now be in the new SSAE-16 reports, but again, the [Product A] and [Product B] departments, this doesn’t apply."
A couple of weeks after getting this response, I had a support ticket open with this vendor. The same support technician that sent me the response above, proceeded to download a copy of the application database from my server to their workstation to "test some things out". The vendor did not request permission before making a copy of the data that I am responsible for, and didn't admit to doing so until after I questioned them about it. I then asked for a copy of their SSAE-16 reports (which they obviously don't have). Finally, the vendor sent me an updated privacy statement that included coverage of customer data within the vendor's environment. While not a perfect solution, it should hold up in court if they have a data breach. But at that point all of the data I'm responsible for is probably already on pastebin.
So back to the software upgrade deployment I mentioned earlier. When I sent the paperwork in to the vendor for the service request to have them install the upgrade (and no, they don't allow anyone else to do the installation), I explicitly stated that they are not to make any changes to the OS, firewall settings, install third party tools, etc. unless they first got permission to do so. I also restated this to the technician (different than the one above) working on the install and got an affirmative response that they agreed to these rules of engagement. So guess what? I remote into the system they are installing the upgrade to and see the vendor making changes to the host firewall (as in completely turning it off). #FAIL! I then terminated the vendor's connection, turned the firewall back on, and called to see whether this technician suffers from short term memory loss.
Dear vendor, when are you going to wake up and treat your customers with a little bit of decency. It is not my goal in life to catch you doing stupid things. I really don't need the extra stress of worrying about what you might do to compromise the security of my data. I have enough bad guys out there trying to break into my systems without you handing them the keys to your backdoor.
A word of advice to sysadmins and business folks that deal with vendors:
I doubt I'm alone in this experience. I suspect things like this happen everyday to systems in your environment the same as they do in mine. Do you have policies in place to handle these situations? Are the people on your team trained to watch out for this type of negligence on the part of the vendor?
One of the basic concepts of data security is the principle of least privilege. This should be applied to vendors as much as anyone. Vendors don't usually have malicious intent, but in general they also have much less skin in the game when it comes to protecting your data. Monitor their activity. Watch what they are doing when they are in your system. Revoke their access unless you have a real need for them to be in your systems.
