Security

Security starts not with a program but with three questions. What I protect: email, accounts, client or company documents, the phone, money. From whom: from mass mailings that send the same message to millions; from a targeted attack on a specific company, firm or case; from an accidental mistake, a colleague's or your own. What happens if the protection fails: an inconvenience, lost money, a disclosed secret.

The answers to these questions are called a threat model. It shows where simple protection is enough and where something stronger is needed. For most people who work with documents the main risks are mundane: a reused password, a phishing email, a document shared with “anyone with the link”, a lost phone without a lock. A few habits and settings protect against them, and this practicum is made of exactly those.

Protection works in layers. No single measure covers everything: a password can be stolen, a second factor can be bypassed by phishing, encryption does not help if the laptop is unlocked. Each layer stops part of the attacks, and together they make an attack expensive and noticeable.

A site does not store your password in plain form. It stores a hash: the result of a one-way function from which the password cannot be computed back. At login the site hashes what you entered and compares it with what is in the database.

Site databases leak regularly. A hash is not decrypted, it is guessed: attackers take millions of known passwords, dictionaries and common patterns (“Kyiv2024!”, a name plus a year), hash each one and look for a match. Short and patterned passwords are found quickly. The “email and password” pair found this way is then tried automatically on other services. If the password is the same, everything opens.

Hence two rules. A password should be long and random: each extra random character multiplies the number of candidates. And each service gets its own password, so that a leak from one site stays a leak from one site. Nobody can remember dozens of such passwords, so a password manager keeps them.

A second factor adds to what you know (the password) something you have: a phone, a code app, a physical key. Then a stolen password is not enough. It is the single most effective setting for an account.

Factors differ in what they protect against. An SMS code can be intercepted or obtained by reissuing the number on a new SIM card. An app code is generated on the phone, but it can be entered on a fake site, and the fraudster will use it within seconds. A passkey or a physical key checks the site's address itself and signs nothing for a fake. That is why such keys are called phishing-resistant.

Phishing is an email, message or site that poses as a familiar sender to get you to enter a password, open a file or pay. Mass phishing is easier to recognize. Targeted phishing knows your name, your project or case, your counterparty, and arrives at a convenient moment.

The main check concerns the address. A link shows one text and leads to another domain. A domain can differ by one letter, contain a Cyrillic “а” instead of a Latin “a”, or hide the real address at the end: in “bank.ua.login-secure.com” the domain owner is “login-secure.com”, not the bank.

For companies that pay invoices the most costly variety is a swapped account number in correspondence. A fraudster breaks into the supplier's mailbox, reads the correspondence for weeks and at the right moment writes “our bank details have changed”. The protection is procedural, not technical: any change of payment details is confirmed by a call to the number from the contract, not from the email.

A client forwards a supplier's email with new bank details and asks for a quick answer. Here you are an outside adviser, but the steps are the same for an accountant, a procurement manager or an executive assistant. Go step by step: each choice leads on or into a dead end you can come back from. At the end you see the path you took and the branches you did not turn into.

Encryption turns data into a string of characters that only a key can open. The main question about any encryption: who holds the key. The answer decides whom it protects against.

In transit (https, TLS): data is encrypted between your device and the server. The Wi-Fi owner and the internet provider see only the fact of the connection and its volume. On the server the data is opened. On the server: the service stores data encrypted, but holds the keys itself; this protects against outside intruders, not against the service or a lawful request to it. End-to-end (as in Signal): the keys are only on the participants' devices, and the server forwards sealed envelopes it cannot open. Disk (FileVault, BitLocker): the contents of a lost laptop cannot be read without the login password.

Encryption moves the weak point to the device. An unlocked phone shows everything that is encrypted in transit and on the server. That is why the screen lock and disk encryption matter as much as a secure channel.

Most attacks on devices use known vulnerabilities for which updates have already been released. So automatic updates of the system, the browser and apps close more holes than any separate security program.

Three things protect a lost device: a screen lock with a PIN or password, disk encryption, and the ability to locate and erase the device remotely. On modern phones encryption turns on together with the PIN; on laptops it is turned on in the settings (FileVault on a Mac, BitLocker or “Device encryption” in Windows).

A backup protects against loss: a broken disk, theft, ransomware that encrypts files and demands a ransom, or your own mistake. The 3-2-1 rule: three copies of the data, on two different media, one of them outside the office. A backup that has never been test-restored is only the promise of a backup.

Incident reports show year after year that the human factor is involved in most breaches: a wrong recipient, an open link, a document published without checking, a password in a text file. Big hacks of large services are rare; everyday leaks through access settings happen daily.

A cloud document shared with “anyone with the link” is open to anyone the link reaches. Links get forwarded. One forward, and the document is with a third party without any hacking. The rule of least privilege: give access to specific people, only for the time needed and only at the level needed (view, comment, edit).

The question “is it safe to give documents to AI” is really four. Can the request be read in transit: no, the channel is protected by TLS, as with a bank. What does the service do with the data once it has it: that depends on the plan and the settings, in particular on whether conversations are used for training and how long they are kept. Can someone oblige the service to keep or hand over the data: a court can, and such cases have already happened. What data did you hand over yourself: that depends on your habits.

A working approach has three levels. Tasks without sensitive data: any plan with training turned off. Client materials, HR and financial documents: a business plan or the API, where training is off by default, plus anonymizing everything that can be removed without losing meaning. The most sensitive: a local model whose data never leaves the organization's perimeter. More on training and data retention in the practicums “How a language model works” and “Working with an assistant”.

The steps in order of importance. Tick what you have done: the ticks are stored only in this browser. App names are given as examples, not as advertising; choose what your system supports and your organization trusts.

After an incident, speed and the order of actions matter. Changing the password without signing out of all sessions or without checking the forwarding rules in the mailbox leaves the fraudster access. Below are five typical situations and the steps for each.