Привет! Я — Катя DLPшка. Недавно пришла в профессию и… сразу же получила свой первый блэк аут. Рассказываю…

Четыре года в вузе я наивно верила: устроюсь на работу в айтишку, где клиенты всё понимают, а их сотрудники — ангелы. Я буду выявлять инциденты, говорить, что и как исправить, ссылаясь на ФСТЭК и ГОСТ, а мне отвечать: «Да, DLPшка Катя, согласны, давайте исправлять…»

Забавно вышло. Я сильно ошиблась

Именно поэтому я завела блог: хочу снизить риски от социальной инженерии. Потому что главная уязвимость — это люди. И я их прекрасно понимаю, наверное.

Небольшой тизер к моей первой статье:

Сейчас я работаю в компании по автоматизации предприятий. В отделе ИБ я аналитик DLP‑системы, отсюда и мой никнейм — Катя DLPшка. Я рил считаю, что DLP — хороший способ подсветить риски и каналы утечек, которые никто никогда не контролирует.

Так вот, закончился у меня очередной проект. Точнее, не закончился — мы его закрыли. Хотя искренне хотели помочь бизнесу. Обидно, да? Мой руководитель мне сказал не расстраиваться и вообще: «Лучшее лекарство — отпусти и забудь». Но я решила написать статью и рассказать (поныть) миру, с чем столкнулась.

И вот мой пятый проект как есть….

Один из недавних клиентов — классический представитель среднего бизнеса: свой домен, файловый сервер, распределённая работа с удалёнкой. CEO является владельцем компании и безгранично доверяет главному системному администратору (назовем его СИС). СИС в хороших отношениях с генеральным, и мнение первого лица звучало так: «Наш сисадмин — профессионал, он всё контролирует, нам отдельный человек по ИБ не нужен».

Но у нас есть бесплатный тестовый период. И владелец решил всё‑таки попробовать что‑то новенькое — побыть в «тренде ИБ», ну и к тому же посмотреть, а кто что делает или может, даже ворует. Так они и решились на наш 4-недельный тест DLP.

Как мы получили кривые права

Для сбора событий с файлового сервера мне нужны были права на чтение логов. СИС выдал права, но неправильно: вместо чтения файлов только у определенных пользователей, сотрудник дал доступ к терминальному серверу с учётками всех пользователей компании. Я, в свою очередь, предупредила заказчика об избыточности, но получила прямое указание продолжать работу в текущей конфигурации и мониторить всех пользователей, к которым у системы имелся доступ.

В результате я не могла менять настройки, так как не владела правами администратора, но зато модуль вычитки документов продолжал исправно писать в свою базу всё подряд. Данных я получила с большим запасом — и это оказалось золотой жилой. Я подумала: вот сколько проблем я вижу, сейчас я им помогу.... Угу… помогу…

Результаты DLP‑системы через неделю

Я начала с малого: посмотрела содержимое рабочих столов сотрудников. Абсолютно на каждом конечном устройстве обнаружился текстовый файл (а чаще незашифрованная электронная таблица) со всеми паролями. Внутри — учётные данные от корпоративных порталов и Госуслуг, парольные фразы от банков, доступы к удаленным столам и внутренним CRM. Венчала этот «клад» приписка: «Сохрани этот файл на рабочем столе или отправь себе по почте, чтобы не потерять ?». Да… со смайликом… Моя первая мысль: «Правила безопасности ИБ? нет… не слышали». Но самое интересное ждало меня на машине самого СИСа.

Находки на ПК «неприкасаемого» СИСа

Прицельно изучив файлы и логи с рабочей станции системного администратора, я нашла три критичные проблемы:

1. Антивирус с истекшей лицензией и базами. На машине стоял антивирус, который когда‑то был корпоративным стандартом. В логах DLP‑системы читалось, что последнее обновление вирусных баз произошло больше года назад, лицензия истекла. Фактически ПК был «голым».

2. Вредоносное ПО, пропущенное всеми средствами защиты. Сотрудник скачал вредоносное ПО (предположительно, стиллер), а устаревший корпоративный антивирус никак не распознал и не отреагировал на инцидент.

3. Хранение всех паролей компании. В корне рабочего стола лежал текстовый файл с паролями от доменных учёток, локальных администраторов серверов и учётных записей всех сотрудников. Файл не был защищён мастер‑паролем — открывай и заходи куда угодно.

Финал: как закончилась история

Я представила CEO полный отчет с описанием уязвимостей, индикаторами компрометации и выводами. Предложила несколько вариантов реагирования для выстраивания комплексной безопасности в компании: от использования антивирусного ПО и менеджера паролей, до развёртывания полноценной DLP‑системы в разных ценовых категориях в зависимости от количества лицензий. Ответ генерального директора был: «Нет, спасибо. Я знаю, что наш админ — надежный человек, он решит самостоятельно».

Контракт закрыли, компания осталась один на один со своими проблемами. Теперь каждый раз, когда в новостях появляется заголовок об очередной масштабной утечке паролей, я невольно думаю: а не та ли это компания, где нашелся стиллер на «неприкасаемом» админе?

Что я хочу подчеркнуть

1. Избыточные права — подарок для аудитора и лазейка для хакера. Ошибка СИСа с предоставлением прав уровня администратора дала мне возможность провести глубокий аудит. В реальных проектах рекомендую всегда внимательно проверять, какие разрешения вы даете подрядчикам. Случайная избыточность может помочь злоумышленникам.

2. Просроченный антивирус на ПК админа — симптом системной беды. Если главный ИТ‑специалист не следит за сроками действия лицензий и обновлением баз на собственной машине, он не контролирует безопасность всей инфраструктуры.

3. Дружба с владельцем — самый опасный вектор угрозы. Технические средства бессильны, когда бизнес‑решение принимает человек, для которого аргумент «Он мой друг, я ему верю» перевешивает результаты объективного расследования. Информационная безопасность должна строиться на процессах и проверяемом уровне доверия, а не на личных отношениях. Иначе бэкдором становится сама корпоративная культура.

К чему приводят такие инциденты: примеры из жизни

Описанная ситуация — реальная практика, которая регулярно заканчивается громкими утечками и многомиллионными убытками. Припомню ситуацию с Uber в 2022 году: злоумышленник методом социальной инженерии выманил пароль у сотрудника и попал во внутреннюю сеть. Там он обнаружил сетевые папки с PowerShell‑скриптами, содержавшими учётные данные администраторов в открытом виде, что позволило ему почти полностью захватить инфраструктуру, включая консоль AWS, почту и системы безопасности. Компания была вынуждена на несколько дней остановить множество внутренних сервисов.

Вроде написала — отпустило. Кто дочитал, отзовитесь, пжлста. Как вы сами действуете в таком аду?

И главное: есть ли фонд по защите таких, как мы? Аналитиков ИБ, которые всё видят, а их редко слушают. Я не говорю, что всё будет, по‑моему, и осознанность вдруг на всех снизойдёт. Но ведь в любой работе должна быть польза и аккуратность. Так почему бизнес не хочет, чтобы у него было аккуратно и с пользой для себя же?