Algeria AgencySecurity & surveillance
IT security: four stories, and how long it takes to notice
What costs is almost never the moment of the incident. It is the interval between it happening and somebody noticing.
The security family article lists in one paragraph what actually happens to a small business. This page tells four of them properly, because a list does not show the one thing that decides the cost.
That thing is an interval. In all four cases the event itself is brief and not very serious; what costs is the time passing between it happening and somebody noticing.
That interval runs to weeks for a reused password, days for a stolen computer, hours for a diverted payment, and minutes for an encrypted file. Those are not the same urgencies and it changes what has to be prepared.
So this page tells all four, says what shortens them, explains what to do in the first hour, and contains a figure we hold and will not publish — section 5 says why.
Four stories rather than a category
The words "IT security" cover things so different that the words themselves prevent a decision. Telling what happens is more useful than classifying it.
The first story is physical: a laptop disappears, from a car or from premises, and nobody thinks first about the data it held.
The second is a chain: a password used elsewhere shows up in the leak of a service with no connection to you, and somebody tries it on your mailbox months later.
The third is a conversation: a perfectly proper message, in an existing thread, asks for bank details to be changed before a scheduled payment.
The fourth is abrupt: the shared files become unreadable within minutes, on a Friday afternoon, and the backup that was supposed to help that day had never been tested. None of the four resembles what the word "security" evokes, and that is the problem.
The stolen laptop, and the disk that comes out
It is the commonest event and the only one everybody understands immediately — except on one point: what was lost.
The material loss is quantifiable and modest. The real loss is the contents: the mailbox and its history, offline work files, passwords saved in the browser, and sessions already open to your online tools.
The session password protects none of that. It prevents the machine being switched on and used normally; it does not prevent the disk being taken out and read elsewhere, which takes minutes and no particular skill.
The only protection is disk encryption, enabled before the incident, and it is today included in the systems your machines already run. It is not a purchase: it is a box ticked when preparing a machine, and it is the best-value measure in this whole pillar.
The interval here is short — a theft is noticed the same day — and that is what makes what follows decisive: within the hour, change the mailbox password, close the sessions open remotely, and warn the bank if access to it was saved. Those three acts get prepared in advance because they are not improvised on a Saturday.
The reused password
It is the story with the longest interval and the most distant cause, and that is why it is the worst understood: your system was not the one breached.
The sequence is always the same. An employee uses the same password for your mailbox and for an unrelated service — a shop, a forum, an application. That service suffers a leak, which happens regularly and which nobody is told about. The list circulates. Months later, somebody tries those pairs of credentials everywhere, automatically.
What happens next is quiet and it is what makes the interval long: whoever gets into a mailbox breaks nothing. They read. They wait for an exchange about money, and they step in at the right moment — which is the next story.
The consequence is that your mailbox’s security does not depend only on you, and that no equipment in the pillar addresses this case. What does address it sits in two measures, both free.
The first is a different password per service, which requires a way of remembering them — a manager, or failing that a notebook under lock, which beats a single password. The second is two-step verification on the mailbox, which makes a stolen password insufficient. If only one measure from this page were taken this week, that is the one.
The message asking for bank details to change
It is the most expensive story per event, and the only one whose interval runs in hours — because beyond that, the money has gone.
The naive version is easy to spot: an unknown address, approximate language, excessive urgency. That is not the one that works. The one that works arrives in an existing thread, with the right references, the right tone, and often the right signature — because whoever is writing has been reading your correspondence for weeks, by the previous story’s route.
There is no reliable technical way to tell it apart. It is a message that looks like a legitimate message, sent at the right moment, about a real subject. The firewall does not see it, nor does the antivirus, and an attentive employee gets it wrong.
The only defence that works is a habit, and it has to be a company rule rather than an instruction to be vigilant: any change of payment details is confirmed by a voice call, to a number you already had before the message. Never to the number given in the message, never by replying to the email.
That rule has to be written, known to everybody who can trigger a payment, and applied without exception — including when it is the director asking, including when it is urgent, and especially when it is urgent. Urgency is this story’s main tool.
The encrypted file, and the one thing that gets you out
It is the story with the shortest interval — minutes between the start and everybody noticing — and the only one that stops the business rather than costing it a sum.
The trigger is almost always ordinary: an attachment opened, software downloaded from a search result, an out-of-support machine left plugged in. What follows is automatic and fast, and it touches everything the person could modify — so the server shares, not just their own machine.
That is why this story is the one that justifies the ranking of this whole pillar. No product in the security family solves it after the fact: not a camera, not a firewall, not access control. One thing gets you out, and it is a restore.
The copy still has to be out of reach. A backup permanently connected and reachable from the machine gets encrypted along with everything else, and that is exactly what we find in most cases. A disconnected copy is needed, or one at a third party, with an older state kept — that is what the infrastructure article says and here is where the sentence gets paid for.
One clarification that is not technical and is more useful than the rest of the section: nobody should hesitate to report. An employee who thinks they clicked and waits two hours for fear of being blamed turns a contained incident into a general one, and that fear is a management decision rather than a computing problem.
We have the figure and we will not publish it
At this point an article like this prints a statistic: a share of businesses affected, an average cost, an average time to detection. We will quote none, and the reason differs from every one this site’s other articles have given.
The previous refusals were about the figure’s quality. It came from another country, it was produced by whoever sells the solution, it was undated, it measured the wrong population, or it expired faster than the page. None of those defects applies here.
We know how many businesses we have supported after an incident of this kind, over what period, and which of the four stories each of them lived. The figure is ours, it is dated, it is verifiable internally, and it would be exactly the sort of local data this market lacks.
It will not be published because this market is small. A company writing how many clients in a given sector, in a given city, over two years, suffered a given type of incident, publishes information that points at businesses identifiable by anybody who knows them. The precision that would make the figure useful is precisely what would make it name people.
It is this site’s only refusal that protects somebody other than the reader, and we would rather write it than let anybody think we have nothing to say. What we can publish without naming anybody is what this page does: the four stories, their order of frequency, and the interval that decides the cost.
The three habits that cost nothing
The family article names them in a line; they deserve detail here because they are what addresses three of the four stories, and because none requires a purchase.
The first is a different password per critical service, with a way of remembering them. The debate about password complexity is secondary to this one: a complicated password reused everywhere is more dangerous than a simple one used once.
The second is two-step verification on the mailbox first, then on the services holding money or customer data. The mailbox comes first because it is what resets everything else: whoever holds it holds the other accounts.
The third is section 4’s call rule, written down and applied without exception. It is the only one of the three that addresses a story technology does not address at all.
A fourth thing has to be added that is not a habit but a decision: the account of every person who leaves is closed on the day of departure, with the prepared list the family article discusses. It is the most profitable measure in all of IT security and it cannot be bought.
The administrator account in daily use
There is a technical decision that changes the severity of three of the four stories, it is free, and almost everybody refuses it for a comfort reason.
The principle: the session somebody works in every day does not have administrative rights over their machine. Installing software then requires confirmation with a second password, which is a real inconvenience of a few seconds.
What that inconvenience buys matters: most of what runs by mistake runs with the person’s rights. Without administrative rights, malicious software touches that user’s files; with them, it touches the whole machine and sometimes what it can reach.
The resistance always comes from the same place and it deserves honest treatment: people who install things often find it tiresome, and they are right. The answer is not to give them the rights permanently, it is to give them a second administrator account they use at the moment of installing.
There is one case where we give way, and we would rather write it: on a machine where an old business package demands elevated rights to run, the battle is lost in advance and the right answer is to isolate that machine, as the server article describes, rather than to pretend.
What to do in the first hour
Incident response in a twenty-person business has nothing to do with what documents written for organisations with a dedicated team describe. It fits in four acts and they get prepared in advance.
The first is to disconnect rather than shut down. Unplugging the network cable or cutting the wireless stops the spread; switching the machine off erases what would have allowed anybody to understand. That distinction is this section’s only technical point and it is worth knowing.
The second is not to erase and not to reinstall straight away. The temptation is strong, it comes from wanting to get back to work, and it removes any possibility of knowing what left — which is precisely what an insurer or a client will ask you.
The third is to change passwords from another machine, starting with the mailbox and with anything touching money. From another machine, because the one concerned can no longer be used for that.
The fourth is to write down the time. The time of the first symptom, the time it was reported, the time of every action. Three days later that list is worth more than anything anybody thinks they remember, and nobody keeps it unless it was decided in advance.
Who to call, and what to have written down first
Half the time lost during an incident goes on finding out who to call and under which contract number. That list gets written on a quiet Tuesday and kept where it will be found without a computer.
It has six lines. Your IT supplier, with a number that answers outside working hours if the contract provides for it. Your bank, business desk, with the stop-payment procedure. Your operator, with the line number.
Then your host or mail provider, with the account holder — because that is what will have to be proved. The person at your company authorised to decide on an interruption, as the support article requires. And your insurer, with the policy number and what they require to be reported.
That list is a paper document. It is the only recommendation on this whole site that insists on paper, and the reason is simple: this page’s four stories make access to your systems uncertain at precisely the moment you need that list.
Keep a copy off the premises. It is the same reasoning as the second copy of data in the infrastructure article, applied to a sheet of paper.
What we are not qualified to say
This section is deliberately short, and it is the page’s most important limit.
A security incident can create obligations: towards people whose data was affected, towards an insurer, towards a client whose information you hold, or under the regulation applicable to your activity. Those obligations exist and they have deadlines.
We are not qualified to tell you which apply to your case, and we will not, because an approximate answer on this subject is worse than no answer at all.
What we can say is what to prepare in order to be able to answer, and it is useful: section 9’s list, a timestamped record of what happened, and keeping the machine concerned rather than reinstalling it immediately.
The step to take before any incident, and it takes one call: ask your insurer what your policy covers in this area and what it requires you to do, and put the question of your obligations to somebody whose trade that is. It is an hour’s work and it never gets done afterwards.
What we do, and what we will refuse to do
What we will refuse: selling a security product to a business that does not yet have section 6’s three habits. They are free, they address three of the four stories, and no invoice replaces them.
We will refuse to publish our own incident figures, for section 5’s reason, and we will refuse to quote anybody else’s without saying where they come from and what population they cover.
We will refuse to add a second security package alongside the system’s own without having measured what it brings, and to bill an "awareness" engagement that does not end in three written rules posted somewhere.
What we do: disk encryption enabled when preparing every laptop; two-step verification put on the mailbox before anything else; the call rule written and posted where payments get triggered; the daily account without administrative rights, with a second account for installing; the backup copy out of reach and restored in front of you; and section 9’s paper list, handed over in two copies.
And what you can do today without us: enable two-step verification on your business mailbox. It takes five minutes, it addresses the story with the longest interval, and of everything this site has written about security it is the one thing we would ask you to do before closing the page.
Frequently asked questions
What happens most often to small businesses?
Four stories: a stolen laptop, a reused password leaking elsewhere, a message asking for bank details to be changed, and encrypted shared files. What costs is not the event but the time taken to notice it.
Does a session password protect a stolen laptop?
No. It prevents the machine being used normally, not the disk being taken out and read elsewhere. The only protection is disk encryption, enabled before the incident and included in the systems your machines already run.
How do we recognise a fraudulent message?
The one that works is indistinguishable: it arrives in an existing thread, with the right references and the right tone. No tool tells it apart. The defence is a rule: any change of payment details is confirmed by a call to a number you already had.
What should we do if files become unreadable?
Disconnect the machine from the network without switching it off, erase nothing, change passwords from another machine, and write down the times. Only a restore gets you out — provided the copy was out of reach and had already been tested.
Where should we start if we do only one thing?
Two-step verification on the business mailbox. It takes five minutes, it addresses the story with the longest interval, and the mailbox is what resets every other account.
Why do you not publish incident statistics?
Because our figures are dated, local and verifiable, and this market is small enough that a precise figure points at identifiable businesses. It is this site’s only refusal that protects somebody other than the reader.
Where we come in
The number of laptops whose disk is genuinely encrypted is usually zero, and nobody in the company knows it. That is the figure to establish before any purchase.
- We record that state machine by machine, including the ones that leave in the evening.
- We turn encryption on at build time, not afterwards on a machine in service.
- We measure what a second product would slow down before installing one.
Without the three basic habits in place no security product protects you: we decline the sale and name which are missing.
Read next
Notifying a breach within five days: the runbook, hour by hour
The clock starts the moment you know, not the moment you are certain. That is the only sentence in this article that changes anything.The phone is the workstation: what leaves with it
Orders arrive on a phone the business never bought. The number, the session left open, and what goes on the day somebody leaves.The regional audit divisions: what an inspection asks for, in what order
An inspection begins with a list of documents, not with a visit. There are four, they are known, and nothing stops you producing them first.
Let us talk about your project
A free audit, no commitment: we look at your online presence and tell you what is holding it back.