The Vendor Security Assessment (VSA): What You Need to Know

Image

Requesting that a SaaS company answer a Vendor Security request has become a regular thing for companies who work in the cloud. But have you thought about how the reverse works, that is, when your customer has a VSA process focusing on you? The Vendor Security Assessment, or VSA, is the means by which your infosec team confirms that a cloud vendor, or any vendor who might have access to your data, is going to be as careful with your data as you are. And of course, you are as careful with your customer’s data, protecting it from unauthorized access, alteration, or destruction. It would be very embarrassing, to say the least, for your customer’s data, code, or inner workings to be available to the internet at large through a vendor breach. Most VSAs requests start with some internet research on the vendor and a questionnaire about their practices. Your ability to satisfy the potential customer about your security posture can make or break a sale. What sort of questions are being asked? Well, as the concept of a VSA is still relatively new, each prospect asks questions a bit differently. Someday, there will be a standard form or even a certification with an annual audit. Until then, each VSA recipient needs to communicate what processes should give customers confidence in their ability to keep their information private, such as: Data classification: Having data in a “need to know” structure. This includes not only access to drive shares but also applications like Git, Salesforce, and Confluence. It also ensures that only appropriate access within the tool is granted to the right employees. Many users of these tools find the siloing of information and systems frustrating, but by preventing data from being available to just anyone with a login, you can protect that data from a variety of threats. It also makes your employees think about the value of the data they are handling. If it can only be retrieved from a restricted location, they will know that this data should be handled with care. Disable any unused network ports: You may have additional Cat5 plug-ins under your desk or at the empty cube next door. It might seem convenient to have a visiting co-worker or vendor plug in there as you work together unless you find these ports are not live. Wouldn’t it save your company time to just leave those active at all times? Well, if someone gains physical access to the space, they may plug in some unauthorized devices as part of an attack. Alternatively, a co-worker might innocently plug in a spare WiFi equipment they have at home with the intention of increasing signal strength in an underserved corner of the building. But though IT manages the known switches with security updates, this unknown device may be sitting wide open. By locking down the ports both intentional and unintentional, breach points are covered. New hire and termination procedures: Demonstrating that the onboarding and offboarding processes work, not to mention that an employee or contractor who has left the company can’t still log in and peek at what’s been going on, sounds reasonable. Does your company do it every time? How about that new employee IT didn’t know about until they walked in? Or the contractor who had an account and may be back next week? When do they get removed? Who’s telling IT and how? There is a reason to insist on the documented process so that steps don’t get skipped. Backups: There are quite a few mitigations to risks that involve having good backups to systems. At a tech company, many employees know how to spin up a new tool, but just because they can doesn’t mean they should. IT must get involved before these tools become production-ready if only to make sure they get backed up in case of issues. Server hardening: Again, for any production system, the software must reside on a server that is going to stay up to date on its patching and have certain other standards. It seems obvious when said that way, but on occasion, a test or lab server ends up being mission critical through a series of innocuous steps, and then there is some catch-up that has to happen—only now it’s in flight and people are depending on it. Security mindset: Do all teammates get a security introduction when they start, and are all teammates required to go through regular security training as a refresher? Security is easy to backburner if your people aren’t reminded regularly and practice their skills such as via simulated phishing emails or tabletop practice sessions of scenarios which everyone hopes will never happen. All of these and many other processes your ITOps and DevOps groups manage are not only good practices for business; they are also becoming required by customers. Want to help with sales and the bottom line from wherever you are in the corporate structure? Help make sure the entire company keeps an appropriate security posture so that you can easily pass your customer’s VSA.