Sorry, I Can’t Trust You... Yet

Identity and verification have been in the news a lot lately, especially concerning Covid vaccinations. (I think this is my first time mentioning “covid” in my newsletter).

When you get a vaccination you are given an ID card that provides proof that you got the vaccine. Do we implicitly trust that proof? Even then, do we trust that the vaccine was administered properly or even handled and cooled properly throughout?

The same when interviewing a candidate. How do we know for sure they can do the job? We verify with take home coding exercises, reference checks, and multiple interviews.

Here is a wild one for you: Hackers Set Up a Fake Cybersecurity Firm to Target Security Experts

Yeah, some entity stood up a FAKE cybersecurity company to pretend to do pentests.

It’s normal course of action to allow a security company access to your source code to review for security bugs and security issues.

Another recent news item you may have heard: Facebook Data Leak (And they have a huge security team!)

Can we trust anyone???

100%? No.

The argument is similar to reducing risk. We can never reduce risk 100%. We can take actions to minimize and mitigate where we can.

I’m not sure if I want to get into the world of security certifications and audits! Just because companies are SOC2 or ISO compliant, doesn’t mean they are secure. Read some of the

At the end of the day it’s a judgment call. The business wants to use Amce’s Take All Your Data But Make Your Life Easier SaaS product but you care about the data leaving your organization. Note: They may have signed up already and sent company data and now you’re trying to figure out their security.

So here are ways you can build trust of a third party.

Keep in mind, the rabbit hole can become very deep, so it’s often a balance of time (resources) and concern (security & liability) of what you’re trying to protect (reputation? IP? Consumer data? Company data? All of the above?). I’ve added sub-bullets to show how deep these rabbit holes can go.

• You send them a questionnaire and ask them to complete it. You are satisfied with their answers and trust they answered it honestly or that it actually reflects reality.

  • You schedule a time to discuss their answers

  • You schedule an audit of their answers and spot check some of their answers with their engineers.

• They answer the questionnaire but the answers are not to your liking.

  • Business really wants THIS product. So you have time find a way to make it work.

    • You can give less data

    • You ask if there are alternatives, take a quick look at their security stance, and provide as an option.

    • If you’re a big company you can leverage that to get them to fix things

    • If it can’t be fixed, you tell the business this doesn’t pass the security review and they’re liable and responsible if anything goes wrong.

    • If it’s so bad, you have to become the gatekeeper and stand on that hill.

• They have a SOC2, PCI, or ISO audit report they share with you.

• You did a cursory but in-depth review of how your data is handled by reviewing their architecture. Here are some things to ask:

  • How your data is stored, if it’s encrypted, and how exactly?

  • Do humans have access to your data directly?

  • How do they separate data between tenants?

  • Do engineers have to have 2FA to access production system?

Reflections On Third Party Security…

At the end of the mistakes will happen. Capital One had great security, but used a custom web application firewall that got breached due to misconfiguration. Users leak keys accidentally all the time. Databases are accidentally exposed online all the time.

I’m not trying to scare you, I just don’t want you to be complacent or unaware of the intricacies of third party trust.

That’s why we have cyber insurance I guess. :-|

Take care,

Ayman