I just received the most interesting email from WPML today after they helped with me a problem with my website.
WPML and M2i3 have a similar philosophy there: we don’t want access to something longer than it’s needed.
Yet, very often, client will give me their password so we can manage their accounts or help them troubleshoot issues.
In the best of world I would be able to have an account specific to me. Otherwise, I tell them to change it before they give it to us (since most people will reuse passwords) and to change it again after we are done.
Do I go and check if they truly have removed the accounts or changed the passwords?
No. That would be inappropriate and, to some extent, an attempt to breach their infrastructure.
But I sure can remind them to change that password and remove that account (like WPML did with me).
So, I ask you this question: “how careful are you to remove accounts and change the passwords you have given to the suppliers who assist you?”
It matters quite a bit nowadays, if they are breached, your own infrastructure is exposed. Potentially your client’s data is exposed.
And, if you are in Québec, with Québec’s Law 25, you’ll be required to disclose the event which will impact your credibility. Not doing so can expose you to hefty fines (as if loosing credibility was not enough).
How can you close these doors?
There are a few things you can do to improve your security posture:
- change your password before and after giving it to a supplier (it’s actually a good practice to change passwords on a regular basis)
- create accounts specific for your suppliers when possible, make their name clear that they are suppliers (use the name of their organisation instead of the name of the person who is helping you). If your software supports it, assign an expiry date for the access you granted.
- keep a registry of who you gave access, until when it’s needed and remove those accounts when they are no longer needed
- review who has access to which system on a regular basis. Remove anyone who should no longer have access.
With these little steps, your infrastructure and your data will be kept much safer.
—
Jean-Marc
Going Further with Alfred
AI has a reputation for answering. We find it more useful when it questions. For each entry in this blog, we ask Alfred, an AI assistant, to read and generate questions it finds worth exploring. Here are the questions it asked, and the author’s responses.
The supplier as external memory
Alfred: You place the housekeeping burden on the client’s side, reasonably enough. But in practice, isn’t it often M2i3 that keeps the best trace of “who has access to what” at any given client — because you’ve seen three or four generations of suppliers pass through before you? If so, does that create a tacit obligation to hold that memory, even when you don’t want to be its official keeper?
Jean-Marc: It really depends on what the contract between us and the client says. Some clients mandate us to hold and protect access to their assets (password, domains, etc). Doing so outside of a clear mandate would not be considered best practice.
So while we certainly have an obligation to protect that information while we control it, we also have an obligation to destroy it once it has served its purpose. For that reason we use password managers and consider “compromised” anything that has been transmitted through email or messaging.
Service accounts, the small business blind spot
Alfred: The four recommendations mostly address human access (suppliers, people). But most of the “open doors” in a modern infrastructure are API keys, OAuth tokens, webhooks, Zapier integrations someone wired up on a Tuesday afternoon and never reviewed. Does the same principle apply unchanged to those accesses, or does it call for a different ergonomics?
Jean-Marc: Most of the principles apply. A company should know who, how and what can access their data. This is essentially the spirit behind the famous Quebec Law 25.
