Перейти до вмісту

Blog

Безпека інструментів співпраці: приховані ризики в Slack, Teams та чат-платформах

A chat message bubble containing a database password, surrounded by open integrations and disconnected user avatars with warning indicators

23:47. Backend-інженер налагоджує збій у продакшені. База даних повертає помилки тайм-ауту, і черговий Slack-канал заповнюється пінгами від служби підтримки. Її колега просить облікові дані продакшн-бази даних, щоб перевірити налаштування пулу з’єднань. Вона вставляє логін і пароль прямо в канал. В каналі одинадцять людей. Троє з них підрядники, доступ яких мав закінчитися минулого кварталу. Повідомлення індексоване, доступне для пошуку і буде існувати в архіві Slack стільки, скільки існуватиме робочий простір.

Збій усувають до півночі. Облікові дані залишаються в тому каналі назавжди. Через шість місяців, коли акаунт підрядника в Slack компрометують через повторно використаний пароль, ці облікові дані стають першим, що знаходить зловмисник.

Цей сценарій постійно повторюється в організаціях будь-якого розміру. Ризики, що ховаються в робочих чат-платформах, виходять далеко за межі випадкового необережного повідомлення.

Навчання з безпеки браузера: що співробітники дійсно повинні знати

Browser security training - browser window with protective shield against web-based cyber threats

Співробітниця шукає в Google конвертер PDF. Перший результат виглядає правильно. Логотип, брендинг, кнопка завантаження. Вона встановлює його. Протягом 48 годин її облікові дані браузера, збережені паролі та токени сесій ексфільтровані на сервер у Східній Європі. Сторінка завантаження була отруєним результатом пошуку, який ранжувався вище за легітимний інструмент.

Це не теоретичний сценарій. Palo Alto Unit 42 повідомив у 2024 році, що веб-браузери стали вектором атаки номер один для підприємств, залучені в понад 80% інцидентів початкового доступу. Ваш файрвол, ендпоінт-агент та поштовий шлюз мало допомагають, коли загроза живе всередині самого браузера.

Браузери тихо стали операційною системою роботи. SaaS-додатки, хмарні консолі, внутрішні інструменти, комунікаційні платформи. Майже все працює у вкладці браузера. І кожна з цих вкладок є потенційною поверхнею атаки, яку більшість навчання з безпеки ігнорує.

Навчання безпеки паролів, що змінює поведінку

Password security progression from a broken lock with weak passwords through a vault representing a password manager to an MFA shield with a one-time code

Фінансова компанія розгорнула щорічне оновлення політики паролів. Мінімум 12 символів, одна велика літера, одна цифра, один спеціальний символ. Працівники виконали. Безпека відчувалась добре. Потім red team через три місяці виявив, що 38% працівників обрали варіації “Company2026!” і що майже половина повторно використовувала корпоративний пароль на особистих сервісах.

Політику формально виконали. Поведінку, яку вона мала створити, ніколи не виникла.

Цей патерн повторюється в усіх галузях. Організації інвестують у правила паролів та чек-листи відповідності, а потім дивуються, чому атаки на основі облікових даних продовжують вдаватися. Проблема не в тому, що працівникам бракує обізнаності. Більшість людей знають, що повторне використання паролів ризиковане. Проблема в тому, що знання ризиковості чогось автоматично не створює альтернативної поведінки.

Навчання з класифікації даних для співробітників

Four data classification folders arranged by sensitivity level from public to restricted, each with progressively stronger lock symbols

Менеджер по роботі з клієнтами в медичній компанії потребувала поділитися даними результатів пацієнтів з потенційним партнером. Вона відкрила аналітичну панель компанії, експортувала CSV та надіслала його на Gmail партнера. Експорт включав імена пацієнтів, дати лікування та коди рахунків. Вона не усвідомлювала, що все це було у файлі. Вона хотіла лише агреговані числа.

Компанія виявила інцидент через два тижні під час рутинного огляду DLP. На той час лист було переправлено всередині організації партнера. Потребувалося повідомлення про витік згідно з HIPAA. Юридичні витрати, усунення наслідків та штрафи склали понад $200 000. Все тому, що одна співробітниця не могла відрізнити агреговану статистику від захищеної медичної інформації в електронній таблиці.

Цей тип інцидентів відбувається постійно. Не тому, що співробітники недбалі, а тому, що ніхто не навчив їх дивитися на дані та запитувати: “Що я насправді тримаю?”

AI-фішинг: як LLM допомагають зловмисникам писати кращі приманки

AI-powered phishing - LLM neural network generating targeted phishing emails to multiple victims

Фішинговий лист надходить у вашу поштову скриньку. Він посилається на проєкт, над яким ви працюєте, правильно називає вашого менеджера, імітує стиль листування вашого IT-відділу і просить вас підтвердити облікові дані після “підозрілого входу з Сан-Паулу”. Жодних друкарських помилок. Жодних незграбних фраз. Жодного загального “Шановний клієнте”. Він читається саме як легітимне повідомлення від вашої компанії.

Два роки тому написання цього листа вимагало від зловмисника-людини годин дослідження вашої організації, вашої ролі та ваших комунікаційних патернів. Сьогодні LLM виробляє його за секунди. Подайте кілька профілів LinkedIn та зразок корпоративного листа, і він генерує десятки персоналізованих варіантів, кожен адаптований для іншої цілі, будь-якою мовою.

Ось чому традиційні поради з виявлення фішингу про виявлення граматичних помилок та підозрілого форматування стають ненадійними. Сигнали, на які навчали шукати співробітників, зникають.