For the last eight-plus years, I've been working as a fractional Chief Information Security Officer (CISO). Before that, I worked as a full-time CISO for an insurance company for seven years. In both of these roles, I've spent a lot of time working with senior decision makers to create the most business value for the money spent on cybersecurity.
Let me tell you about a typical problem that I help them with: the temptation to hit the easy button by playing whack-a-mole with compliance mandates.
Our current customer, Jeff, is the CEO of a Software-as-a-Service (SaaS) company. He recently reached out to me and said, "I really need to fix my security issues, but my team is small. I have a limited budget. And I just feel like these customer requests are just going to strangle me."
Jeff is really good at what he does. His company provides a valuable service at a fraction of the price it would cost as an in-house solution. His customers love his SaaS because they get great results. But Jeff doesn't know anything about cybersecurity, and he'd been trying for months to deal with requests from his customer's cybersecurity team on his own.
Who's his customer? Amazon Web Services (AWS). He also has several other large companies as customers, such as Microsoft and Salesforce. And each one of these companies has its own vendor risk management program. So he's constantly getting barraged by his customers about his cybersecurity.
Here are some of the questions he's been asked:
Will vendor provide training, as appropriate, regarding the privacy, confidentiality and information security requirements set forth in this Attachment 1 to relevant Representatives who have access to Customer A Information?
If vendor is to receive Personally Identifiable Information about a Massachusetts resident, will it have, and will it maintain, a comprehensive written information security program that is in compliance with 201 CMR 17.00 et seg.?
When reporting a Security Incident (as defined in Section 2.4), will the Vendor ensure that they make actual voice-to-voice contact with one of the contacts listed in Attachment 4?
It's a little unfair, isn't it?
Think about it: AWS is a $40 billion company. Their cybersecurity team is several times bigger than Jeff's entire company. And the AWS risk management people speak in a language, filled with jargon, Jeff has never heard before.
But one day, the AWS rep said to him: "Hey Jeff, our new VP is eager to submit all vendors through our external third-party security review process, and it will likely take weeks."
That time, it was easy enough for Jeff to understand what AWS was saying. And I think that's what put Jeff over the edge. He's thinking, "Weeks! Wow. How can I afford the time and money to do that?"
Even if Jeff ends up coming through this without losing AWS as a customer, spending weeks being peppered with questions about things he doesn't understand seriously distracts him from serving his customers (other people at AWS who don't work in the compliance department) and making them happy at the price he currently charges.
So, he's concerned about his company's future. He doesn't want to lose his customers. And who could blame him? I've known Jeff for several years, and I knew he was struggling with this on his own. But finally he said, "Alright, I'm raising the flag here. I'm going to need your help."
I've noticed that a lot of people in a situation like Jeff's just play whack-a-mole. Cybersecurity requirements show up and they just deal with them as quickly and easily as possible. Most people just sign the data security addendum with only a casual glance and then hope for the best. This is their version of an "easy button" for a really complicated problem.
And there's a lot of downsides to hitting this easy button: excessive cyber risk acceptance; excessive contract risk acceptance; paying for a stream of point solutions that overlap each other and also leave gaps in coverage; etc.
Ultimately, there's a lot of duplication of effort and Jeff's spending money on cybersecurity mitigations that check the box but don't do much to protect him because he doesn't really understand what's being asked of him. And he's probably contradicting himself to his team members as far as what it is that he wants them to do from one customer to the next.
I do have a proven strategy for everyone who has a Jeff at work you're trying to support. But first, I want to provide you with some very specific examples of how customer cybersecurity demands can cause trouble.
These examples are from real data security addenda to service contracts that my customers have signed. I've redacted the sources, but our customers are offering SaaS and selling to large insurance companies.
Here's the first example.
So, the first insurance company says, "Hey, if you have a data breach, we want to hear about that within 48 hours." And then the second insurance company says, "We really think 24 hours is the right way to go."
If you had already agreed to the first insurance company's 48 hours requirement, and you had operationalized it, what would you do when the second insurance company came along?
And is 24 hours even reasonable? Quite honestly, I don't think it's reasonable. I don't even think 48 hours is reasonable. I think reasonable is probably in the 72-hour range. And that's what I advocate for. But how do you balance all this stuff? Especially if you've already operationalized reporting along a much longer deadline?
Let's take a look at another example, on password requirements. So, another real-world example here where two insurance companies said this is what you, a small SaaS provider, need to do for passwords.
You can see that one SaaS customer wanted them to change passwords every 90 days, and the other one wanted them to be changed every 60 days. This is positively Stone Age compared to the current best practice recommendations from the National Institute of Science and Technology (NIST).
According to passphrase best practices, you shouldn't be changing your passphrases as long as they're in the 12-20 character range, right?
So, how do you reconcile all this?
You could just smile and give false assurances to customer #1, "Sure, we'll change our passphrases every 90 days." Then print the contract out, sign it, scan the document, and email it back.
And then assure customer #2, "Sure, we'll change them every 60 days." Then use your DocuSign account to execute that contract. Then just keep doing whatever you think is best.
I see that a lot. Just signing the contract and not trying to operationalize anything. But, if something bad does happen, they're going to be investigated and probably exposed as a poorly performing executive for making contractual promises that you don't actually fulfill. That could lead to litigation and a messed up reputation. Ugh.
So, one of the more powerful ways to create a cybersecurity program when you're in a situation like this is using an approach that I call "Secure Once, Comply Many."
In the circle on the left are all the different cybersecurity requirements that are pressing down on you.
And on the right is just a single set of internal guidance to your work force; standards, processes, and procedures so that your team has a single place to know what they should be doing. They don't ever have to think about where did these requirements come from. And they don't have to figure out "do I need a 90-day password reset for this system or a 60-day password reset?" You remove all that complexity from your workforce.
Let me show you how I do this kind of work. So, first of all, I keep a master spreadsheet of all of our customer data security requirements. I call this a "requirements traceability matrix." We can add any and all regulatory requirements in there, as well as the other things we do to stay out of trouble with phishing, ransomware, etc.
Just focusing on the customer stuff, you can see here that I have each one uniquely numbered. These are real requirements from four real customers. Right away, I can tell that customer A and customer B are asking for the same thing or very similar to the same thing, in two places: security and privacy training for vendor staff (see requirements 1 and 4).
And then you can see where customer B and customer C are also asking for essentially the same thing, an incident response plan, but using completely different language (see requirements 5 and 7).
And then, guess what? All four customers actually have some unique things that they're looking for.
Now, as I showed in the "Secure Once, Comply Many" visual, all these requirements are feeding into our internal security policy. So, when a new contract comes in, I'm comparing what they want with the things that we've already agreed to do with our other customers.
And then I'm working with our sales team to negotiate any new requirements so that they fit into what we're already doing.
So, if we can get the newest customer to align their requirements with what we're already doing, then that just simplifies everything. I don't even have to tell anybody in our workforce that we just signed a new agreement because they're already doing the right things.
With the "Secure Once, Comply Many" approach, Jeff is in a much better place! If you identify with Jeff, you should give this idea a try. Either way, please let me know what happens.
