“Are we secure?” — “Depends on when you’re asking”

A conversation with Vlad Tkachev, IT Audit Partner at Baker Tilly for the Central Asia region, on why every audit has a short shelf life, what makes a salami attack different from plain theft, and why the safest backup is the one even your most powerful admin can’t touch.

— Let’s start simple. A client comes to you and asks: “Be honest with me, are we secure?” What do you tell them?

Honestly? I let out a quiet inner sigh. Because at that moment the person is hoping I’ll nod, pat them on the shoulder and hand over something like absolution — short, reassuring and, ideally, free. And instead I have to switch into pedant mode and spoil their mood a little.

— Why the pedant right away? It’s a fair question.

It’s a fair question, but it’s a trap. Not on the client’s side — they’re asking in good faith. The trap is in the wording itself. “Are we secure?” assumes security is some kind of stable state: yes, you’re secure, tick the box, carry on with your life. And that state doesn’t exist.

— What do you mean, it doesn’t exist? You run the audit, the system passes — so at that moment it’s secure, no?

At that moment — yes. I’ll go further: technically it might be flawless. In the exact second we sign off the report, close out the recommendations and head off for coffee, it’s a textbook example. The problem is that this perfect moment lasts roughly until the first admin logs in the next morning.

— So, until lunchtime?

Sometimes literally until lunchtime, yes. Here’s the thing — you have to change the mental picture. An information system isn’t a safe you put in the basement, lock and forget. It’s more like a living organism that’s constantly churning. Someone resigns, someone gets access “just for five minutes,” an update lands, the code changes, a contractor tweaks something on their end. Every one of those movements shifts the landscape a little. So any audit is, by its very nature, a freeze-frame. By the time you open the PDF of the report, the reality inside your network has already moved on.

— That sounds pessimistic. Does that mean secure systems simply don’t exist?

In all my years of practice I’ve never once met a system you could honestly call permanently secure. What I have seen is hundreds of beautiful, perfectly correct architectures — flawless on the diagram — that later fell apart on the most ordinary, everyday stuff. And that, frankly, is far more interesting than any textbook. Because real failures almost never look like the “hack” you see in the movies.

— Then let’s talk cases. Do you have a favourite — one that shows a well-built system breaking in the most unexpected place?

I have several. And I’ll deliberately tell you invented ones — for obvious reasons I can’t take real stories about live clients outside these walls. But every one of them is assembled from entirely real mechanisms; I’m not exaggerating anything. Let me start with my favourite, because it doesn’t have a single villain in it.

— How can you have a breach without a villain?

Like this. Picture an accountant — let’s call him a model employee, because that’s exactly what he was. Joined the company eight years ago in a modest role. Over the years he grew, moved through three departments, picked up a couple of promotions — a perfectly healthy career, everyone’s happy for him. And at every step along the way he was granted new access, properly, by request, signed off by his manager. Moved into treasury — got rights to work with payments. Made senior — got approval rights. Onboarded onto a new system — got another role. Every single grant, on its own, completely justified.

— So far this sounds like normal work, not a problem.

That’s exactly the catch. The problem isn’t what he was granted. The problem is that taking the old access away wasn’t anyone’s job. Not a single person in the company was responsible, when granting new rights, for asking: “wait, what does he already have?” Access just kept piling up — like stuff in the attic, you keep putting things in and never get round to clearing them out. And at some point it turned out one person could create a payment, approve it himself, and post it himself. The full cycle. In one pair of hands.

— And he took advantage of it?

In this story — no. And that’s the important part. Nobody ever gave him that kind of power — not one person, not at any single moment. It accumulated on its own, drop by drop, over eight years. On paper the separation of duties was perfect: pull any individual access request and it’s spotless. But in practice the principle that the person who pays shouldn’t be the one who checks himself had been quietly eroded by time. That’s what I call the most honest kind of vulnerability: nobody created it. It grew by itself.

The way I put it to myself is this: access tends to accumulate, not dissolve. There’s always someone accountable for granting it, and almost never anyone accountable for taking it back. And if you don’t treat that imbalance deliberately, even the most perfect separation-of-duties scheme will eventually slide into one pair of hands. Not out of malice. Just under its own weight.

— Alright, that’s a story about something breaking on its own. Do you have the opposite — where there was genuine malice, but it was impossible to see?

I do — a real classic. It’s called a salami attack, named after the slicing: you shave off one wafer-thin sliver at a time from a whole piece, and nobody notices. Picture a developer working on a billing system. He’s handed something deathly boring — say, the logic for rounding amounts in calculations. A task so trivial and dull that, realistically, no one will ever sit down and read it carefully. Rounding, whatever, next.

— And what can you possibly do with boring rounding?

Oh, plenty of interesting things. He writes the code so that on every transaction the fractional remainder — the fractions of a cent that come up in rounding and normally just vanish — doesn’t disappear, but quietly trickles into one specially created service account. From each individual transaction it’s a vanishingly small amount. So small that even if someone spotted it, they’d wave it off. But the system processes millions of operations a month. And those microscopic trickles merge into a very respectable river.

— But hold on. That’s a straight-up shortfall. Any financial control should catch it.

Nope — and that’s the beauty of the trick, if you can say that about theft. There’s no shortfall in the books at all. Debits and credits reconcile perfectly, down to the cent. Because the money doesn’t leave the system — it moves from one pocket to another inside it. A balance-sheet audit will come back spotless: everything balances, everything ties out. And a code audit… well, who, of their own free will, is going to go and reread a rounding function under a magnifying glass? It’s elementary, there’s nothing to see there.

— So it’s impossible to catch, in principle?

It’s catchable. But only one way — by changing the question. Standard control keeps asking: “does the balance reconcile?” And a salami attack is specifically engineered so that it does. So the only way to catch it is to ask something else: not “does it reconcile?” but “why has this service account, which normally never sees a thing, quietly built up a noticeable sum over the year?” The first question is about arithmetic. The second is about common sense.

And this is where a line runs that matters a great deal to me. Classic control looks for the error — the thing that doesn’t add up. A well-hidden attack adds up perfectly; what gives it away isn’t an error, it’s an anomaly. The difference is fundamental. An error is when the balance doesn’t tie out. An anomaly is when the balance ties out beautifully, but the thing itself just looks wrong. A machine is excellent at spotting the first and almost blind to the second. That’s why “does it all reconcile?” is a question we long ago taught the automation to ask. But “does this actually look normal?” still has to be asked by a living human being.

— You must have a pet peeve. What frustrates you the most?

Backups. That’s genuinely my personal hobbyhorse, I can go on about them. You ask: “Do you have backups?” — “Come on, of course, all set up, all on schedule.” You ask further: “And do you test the restore?” — “Yes, regularly, comes back up no problem.” It all sounds exemplary. And then ransomware arrives — and the nastiest part comes out.

— That there were no backups?

Worse. The backups existed. And they were tested honestly. The catch is elsewhere: those copies lived on the same network and under the same accounts as the production system. Just, loosely speaking, “in the folder next door.” And ransomware, once it’s inside, usually arrives already holding administrator rights. So it calmly, methodically works through everything that admin access can reach. First production. Then, with those very same rights, the backup storage. And there’s nothing left to restore from: the backups are encrypted along with the original, in one move.

— Makes sense. So then what counts as a proper backup?

Now we’re at the heart of it. A backup that the most privileged person in the company can reach is, strictly speaking, not a backup. It’s just a second target, kindly placed right next to the first one. A real backup is a cold, offline copy. Physically cut off from the network. The kind nobody can get to at all — including the almighty IT guy with root access, including, if you like, you yourself wearing the administrator’s hat.

— But that’s wildly inconvenient.

Absolutely. It’s inconvenient, it looks archaic, it’s annoying — every time someone suggests “let’s just connect it to the network already, so we can automate it.” And that inconvenient, “dumb,” cut-off-from-everything copy is precisely the one you must never touch. Because the point of a backup isn’t to be convenient. The point is that the same thing which destroyed the main system can’t reach it. The way I put it: a backup reachable from the same network under the same rights isn’t a backup — it’s a second copy of the same target. The only copy that saves you is the one nobody can reach.

— If you put these three stories side by side — what do they have in common?

In all three, the system was technically sound. Access was granted by request. The rounding worked correctly. The backups ran on schedule. You couldn’t fault a single item. And yet every one of those systems was vulnerable — the vulnerability just wasn’t hiding in the settings, it was in the processes around them. In who grants access, and how. In what question you put to the books. In where the copy physically sits.

Which brings me to the main idea I always end up at: security isn’t a property of the configuration. It’s a property of the processes. Systems almost never break on their own, out of nowhere. Two things break them — changes that went through without control, and decisions made for the sake of momentary convenience rather than security.

— So does that mean the classic technical audit — “check the hardware and the software” — isn’t all that useful?

It’s useful, but on its own it’s incomplete. An audit that looks only at hardware and software, in isolation from people and processes, is a technically impeccable but fairly useless piece of paper. It faithfully records what you have right now, this very second. And it says nothing at all about what happens tomorrow — when Monday comes and everyone starts changing, granting, tweaking and “temporarily” opening things up again.

— And so today, when people ask you about security…

…I stopped looking at firewall settings a long time ago. I look at how the company handles change. Who makes decisions, and how. What happens when it’s “urgent and needed right now.” Whether anyone ever takes access back, or it only ever gets handed out. Where the backup physically goes. If those processes are crooked, no software will save you, however expensive it is. And if the processes are healthy — the software is usually fine too. Because healthy processes are simply a reflection of a company that’s used to thinking one step ahead.

About the expert

Vlad Tkachev is an IT Audit Partner at Baker Tilly for the Central Asia region. Co-founder of the Information Security Centre in the Kyrgyz Republic, and an independent expert and consultant in ICT and information security for government and international organisations. He sits on the expert council of the state authority for personal data protection and is a member of the working group drafting the Digital Code of the Kyrgyz Republic.

He is a certified non-state forensic expert in the field of “Examination of Computer Information Devices” (specialty code 21.1; certificate of conformity to the STO-NSE-2016 standard, №013351), and a member of the Yu. G. Korukhov Chamber of Forensic Experts (“SUDEX,” Moscow), registry №3290.

He has worked in ICT and information security since 2002. Over 24 years of practice he has taken part in dozens of local and international projects: assessing and designing complex information systems, investigating computer incidents, building defences, and the early detection and prevention of information threats.