Павел пишет интересное. В США арестовали 👮 двух близнецов, работающих в ИТ-компании, которая обслуживала федеральное правительство. Судя по тексту приговора, братаны крали данные и пароли, удаляли базы данных, подтирали следы своей деятельности в системах налогового ведомства, минсельхоза, минэнерго, регуляторов по национальной безопасности. Вроде обычная история, но есть один нюанс... Близнецов в 2015 уже осудили за кражу компьютерных данных 😡

А где хваленый скрининг персонала при доступе к федеральным ИТ-системам? Хотя Задорнов и был прав 🤦‍♂️, но я задумался, а насколько реален такой кейс у нас? Как проверяются сотрудники ИТ-подрядчиков, имеющие доступ к отечественным государственным информационным системам? Проверяются ли они вообще? 🤔

Тут сорока на хвосте принесла 😂, что один аутсорсинговый SOC на субподряд взял одну команду из очень ближнего зарубежья, а там тоже решили сэкономить и взяли на работу гражданина Украины со всеми вытекающими... из защищаемой SOCом компании данными, которые после были пошифрованы 🤒

А у вас в политике ИБ для подрядчиков учитывается такой риск? 🤔

#инцидент #ответственность #supplychain

Читать полностью…

А вы выключаете свой Wi-Fi-маршрутизатор, уезжая в отпуск? 🤔

Читать полностью…

🎉 «Ну что? Мы сделали это!»

Так радовался в июне 2025 года у себя в сторис в Telegram Иван Семчук, гендиректор небольшой IT-компании «Бакка Софт». В этот день «Аэрофлот» официально представил свое новое веб-приложение — его разработкой занималась компания Семчука. Через месяц похожий восторг, по всей видимости, испытали украинские и белорусские хакеры — они смогли пробраться в инфраструктуру «Аэрофлота», используя «дырявый периметр» этого подрядчика.

Это деталь из моего нового расследования про летнюю атаку на «Аэрофлот». Напомню, в конце июля «Аэрофлот» почти сутки не летал после совместной атаки Silent Crow и Киберпартизан Беларуси. Отменили и задержали больше сотни рейсов — по официальной версии авиакомпании, из-за «сбоя информационных систем».

🔍 Как продвигались хакеры — ключевые моменты

• Silent Crow начали с подрядчика — той самой «Бакка Софт». Взлом подрядчика обнаружили ещё в январе, но incident response провели плохо, и спустя несколько месяцев хакеры вернулись уже осторожнее. Ранее по аналогичной схеме, через взлом подрядчика, Silent Crow «заходили» в «Ростелеком».
• В «Аэрофлоте» долгое время не было 2FA на терминальных серверах, а у подрядчика был удаленный доступ к инфраструктуре. Хакеры зашли с термильника, затем «провалились» в Active Directory и смогли получить учетку с высокими привилегиями.
• В итоге, у хакеров была учетная запись администратора в корпоративном домене «Аэрофлота»(!)
• Дальше у них был этап сбора информации из корпоративных систем. Отдельно подчеркну, что ответа на то, действительно ли хакеры смогли достать полный массив баз данных истории перелетов «Аэрофлота» — нет.
• Потом они разлили групповую политику, которая по расписанию запустила wipe на рабочих станциях. После запуска процесса уничтожения данных хакеры убили и сам корпоративный домен.
• Разрушение IT-инфраструктуры «Аэрофлота» началось около 5 утра 28 июля: сотрудники начали писали в чаты, что не работают почта, корпоративный VPN, а рабочие станции уходят в циклическую перезагрузку и др.
• Около 7 утра, после того, как стало понятно, что взломали AD, поступила команда «все вырубаем»: в офисах «Аэрофлота» сначала отключили каналы связи, затем — отрубили электричество и отдали приказ приостановить полеты.

«Команде „Аэрофлота” респект хотя бы за то, что они быстро все рубанули, и в итоге очень большой кусок инфраструктуры смогли спасти», — говорит один из моих собеседников в сфере ИБ.
🧩 Источник, знакомый с материалами расследования кибератаки, говорит, что хакеры использовали около двух десятков образцов вредоносного ПО: 

• модифицированные администраторские/диагностические утилиты, которые делают дампы оперативной памяти, что позволяет извлечь пароли, ключи и сеансы;
• самописные модули управления;
• общедоступное ПО и прокси, в частности Ghost Proxy и HAProxy.

Вывод у него примерно такой: «Здесь не было какого-то ноу-хау. Это дело громкое политически, но в техническом плане там ничего необычного».

⚠️ Однако в ходе расследования был обнаружен интересный нарыв.
Оказывается, индустрия ИБ в России негодует из-за того, что НКЦКИ ФСБ не делится с отраслью индикаторами компрометации (IoC) по этой и еще ряду крупных кибератак украинских хакеров, что не позволяет другим компаниям учесть ошибки «Аэрофлота» и закрыть те лазейки, которыми воспользовались хакеры.

“Мы IoC’и “Аэрофлота” достали, но из-под полы, по дружбе. В бюллетенях НКЦКИ их не было. По сути, всем остальным дали понять – крутитесь как хотите, теперь ваша очередь тонуть”, – говорит мой собеседник в ИБ-компании.
@kolomychenko

Читать полностью…

Исследование TAdviser показывает, что в РФ стали гораздо активнее использовать технологии беспарольной защиты 🤒 Все бы хорошо, но вот 95% случаев применения – это одноразовый код в виде СМС на телефон, что давно уже не может считаться серьезной защитой). Тот же PassKey всего в 15%. Хотя тут у меня сомнения есть, что TAdviser правильно понимает термин Passkey – они его, почему-то, уравнивают с OTP, что не так (хотя и с PassKey тоже arkenoi/whats-wrong-with-passkeys-advocacy-e3b6806b3277">не все так хорошо) 🤒

Но чудится мне 🤔, что мы еще долго будем жить с паролями, а значит мы не скоро избавимся от разбросанных по vault-хранилищам, документам, заметкам, чатам, старым инструкциям и даже по временным рабочим пространствам паролей от тысяч учетных записей в серверах, облаках, сторонних сервисах, внутренних инструментах и т.п. А даже один слабый или повторно используемый пароль может дать злоумышленнику доступ ко множеству систем внутри инфраструктуры 👺 И с ростом ее масштаба риск только увеличивается, поскольку "теневые" пароли (заброшенные, забытые, плохо защищенные) могут долго не замечаться. Мне тут показывали как работает PT Dephaze, так он специально ищет пароли на "захваченных" ПК, чтобы потом использовать их для расширения плацдарма. Тоже делают и плохие парни 🥷

Как провести аудит парольной системы? ✍️
6️⃣ Найти, где обычно хранятся пароли. Сначала идентифицировать все места: парольные менеджеры, документы, черновики, чаты, внутренние вики, сторонние сервисы и т.п. Это помогает увидеть, насколько "распылён" парольный ландшафт. Да, все вы, скорее всего, не найдете, но масштаб проблемы увидите и основные места определите. Инструментарий будет зависеть от инфраструктуры – это могут быть TruffleHog, GitLeaks, SecretScanner, osquery, AWS Security Scanner, Kube-audit, Checkov, BloodHound, SharpHound, PingCastle, Purple Knight и т.п.
2️⃣ Проанализировать, как сотрудники создают и хранят пароли. Посмотреть, насколько политики соблюдаются: создаются ли сильные пароли, используются ли надежные генераторы, не переписывают ли пароли в чаты/файлы, не передаются ли коллегам небезопасным образом и т.п. Часто из-за спешки и неудобства (все эти регистры, спецсимволы, буквы и цифры) сотрудники возвращаются к простым, слабым или повторяющимся паролям.
3️⃣ Проверить надежность и уникальность паролей. Оценить длину, сложность, использование словаря, совпадение с утечками, повторное использование на разных сервисах. Это дает явное понимание, где есть риски для взлома, перебора или credential stuffing. Тут снова все зависит от инфры, но можно посмотреть в сторону Hashcat, John the Ripper, PACK, HaveIBeenPwned, Dehashed, DLBI, zxcvbn, Cracklib, SpecOps Password Auditor, ANIXIS Password Policy Enforcer, Password Auditor Pro и т.п.
4️⃣ Особое внимание на привилегированные аккаунты. Учетные записи доменных администраторов, root, сервисные аккаунты, сетевые админы, облачные контроллеры – часто остаются вне внимания (редко меняются, хранятся "на борту", используются совместно, после увольнения сотрудников не удаляются). Аудит таких учетных записей должен проводиться особенно тщательно.
5️⃣ Проверить, как пароли интегрированы с системами управления идентификацией (SSO, MFA, identity-провайдерами). Бывает, часть систем настроена на SSO/MFA, а часть все еще работает на "старых" паролях, что создает двойные стандарты и дополнительные риски.
6️⃣ Проследить жизненный цикл учетных записей и паролей – от создания до удаления: удостовериться, что после ухода сотрудников, окончания проектов, тестов пароли и учетки удаляются или контролируются, а не забываются.

После аудита можно составить сводный отчет 📝: сколько паролей соответствует политике, сколько слабых или повторяющихся, сколько хранится вне хранилищ, сколько привилегированных логинов требуют внимания. Это помогает подобрать и аргументировать меры по усилению безопасности. Может это будет просто использование парольного менеджера (например, Passwork), который помогает централизовать хранение, упростить контроль, ограничить доступ, логировать события и облегчить дальнейшее управление паролями в рамках большей части инфраструктуры 🤔

#аутентификация

Читать полностью…

Ошибка №23. Невыполнение требований compliance

Компания может годами игнорировать обязательные требования регуляторов или отраслевых стандартов, но в момент инцидента это может обернуться штрафами, проверками, ограничениями деятельности, потерей лицензий и серьезными репутационными последствиями. Нередко оказывается, что ущерб от невыполнения некоторых нормативных актов (не всех) куда выше стоимости его соблюдения.

Например, после крупного инцидента в одной финансовой организации регулятор установил, что компания не выполняла обязательные требования PCI DSS по журналированию и сегментации. В результате – многомиллионные штрафы, внеплановая проверка, запрет на запуск новых услуг и прямые убытки от оттока клиентов.

Как исправить:
➡ Проводить регулярную оценку соответствия адекватным требованиям и устранять пробелы до проверок и инцидентов.
➡ Автоматизировать контроль выполнения адекватных требований по ключевым зонам (доступы, сегментация, журналы регистрации).
➡ Встраивать compliance в архитектуру процессов, а не оформлять в виде отчетов "для аудиторов", или пытаться выполнить все в авральном режиме.

#стратегия

Читать полностью…

Ошибка №21. Отсутствие культуры ненаказания

Когда за ошибки карают – их скрывают. Инциденты растут, а цикл обнаружения увеличивается.

Например, на одном производстве сотрудник заметил подозрительные файлы, но боялся сообщить, "вдруг он что-то сделал не так". Через час началось массовое шифрование внутри инфраструктуры.

Как исправить:
➡ Формировать прозрачную систему поощрения за раннее предупреждение.
➡ Анализ инцидентов без поиска виноватого (не путать с анализом root cause).
➡ Публичные кейсы успешного поведения.

#стратегия

Читать полностью…

Ошибка №19. Теневые ИТ и данные (shadow IT / data)

Облака, личные Google Docs, неучтенные SaaS, тестовые базы с реальными данными, оплаченные личными картами GPT-сервисы – все это выходит за рамки привычного контроля ИБ и является точкой проникновения в компанию и утечки данных.

Например, сотрудник случайно оставил копию клиентской базы в личном Dropbox → утечка и большой штраф от регулятора.

Как исправить:
➡ Открыть "официальный" способ решать нужные для выполнения служебных обязанностей задачи или предложить работникам корпоративные лицензии на нужные сервисы.
➡ Обеспечить мониторинг теневых сервисов и потоков данных (вообще, иметь карту информационных потоков также полезно, как и базу активов).
➡ Разработать и контролировать политику хранения данных.

#стратегия

Читать полностью…

Ошибка №17. Слабая или отсутствующая MFA

Усталость от push'ей и запросов на подтверждение аутентификации, однофакторные протоколы, использование одноразовых кодов в SMS, отсутствие защиты сессий – и злоумышленник внутри.

Например, во время взлома Uber в 2022 атакующий использовал усталость от push-уведомлений и социальный инжиниринг для обхода MFA. Аналогичным образом взламывали Cisco, казино MGM Grand и многие другие компании.

Как исправить:
➡ Внедрение FIDO2.
➡ Контроль устройства и контекстный доступ.
➡ Защищенные каналы выдачи токенов.

#стратегия

Читать полностью…

Ошибка №15. Отсутствие сегментации

Плоская сеть – это рай для злоумышленников, расширяющих плацдарм внутри скомпрометированной инфраструктуры.

Например, WannaCry распространялся мгновенно именно в плоских сетях без сегментации. То же самое – Ryuk, Conti и другие шифровальщики.

Как исправить:
➡ Внедрять сетевую сегментацию, VLAN, микросегментацию.
➡ Внедрять Zero Trust Network Access.
➡ Ограничение межсервисных коммуникаций.

#стратегия

Читать полностью…

Ошибка №13. Резервные копии есть, но не тестируются

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

Например, в 2023 муниципальный госпиталь в США был вынужден выплатить выкуп, потому что четыре года бэкапы записывались на поврежденный стример, а никто даже не побеспокоился проверить, работает ли он.

Как исправить:
➡ Тестировать восстановление из резервных копий регулярно.
➡ Хранить оффлайн-копии.
➡ Документировать процедуры восстановления.

#стратегия

Читать полностью…

Ошибка №11. Слабый контроль подрядчиков (supply chain)

Внешние вендоры имеют доступ к вашей инфраструктуре, но вы не контролируете их безопасность и их доступы в вашу внутрянку.

Например, атаки на SolarWinds, MOVEit, 3CX – крупнейшие supply chain инциденты последних лет.

Как исправить:
➡ Внедрить процесс оценки вендоров.
➡ Требовать MFA, регистрации событий, ограничение доступов.
➡ Контролировать работу подрядчиков в реальном времени.

#стратегия

Читать полностью…

Ошибка 9. Нет обучения и тренировки

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

Например, на заводе оператор не знал, что делать при блокировке HMI шифровальщиком и в панике обесточил часть цеха, остановив производство и увеличив ущерб от атаки.

Как исправить:
➡ Регулярные штабные киберучения, а также иные формы сценарной геймификации процесса обучения.
➡ Практические тренировки реагирования на инциденты (как противопожарные тренировки).
➡ Обучение не только и не столько служб ИБ и ИТ, но и бизнес-подразделений.

#стратегия

Читать полностью…

Ошибка №7. Игнорирование «некритичных» уязвимостей

Уязвимость CVSS 5.0 может быть идеальной точкой входа, если ее эксплуатация проста.

Например, в 2023–2024 годах сотни компаний пострадали от массовых атак через уязвимости в Confluence и MOVEit, имеющий невысокий CVSS.

Как исправить:
➡ Оценивать уязвимости по их эксплуатируемости/трендовости (EPSS, KEV), а не только по их базовому уровню CVSS.
➡ Учитывать бизнес-контекст и критичность систем, в которых найдены уязвимости.
➡ Строить процесс риск-ориентированного обновления.

#стратегия

Читать полностью…

Ошибка №5. Отсутствие стратегии развития ИБ

Работа ведется хаотично, в режиме тушения пожаров. Нет целевой архитектуры, дорожной карты, метрик зрелости и и процесса ее оценки.

Например, у крупного холдинга SOC появился раньше, чем инвентаризация ресурсов. В результате SOC не видел 40% инфраструктуры.

Как исправить:
➡ Построить модель зрелости (NIST CSF, разные варианты CMM).
➡ Выработать 2–3-летнюю дорожную карту с приоритетами.
➡ Связать стратегию ИБ со стратегией цифровой трансформации и бизнес-стратегией.

#стратегия

Читать полностью…

Ошибка №3. Неправильное распределение ответственности

Классическая ошибка: "ИБ отвечает за все". На деле безопасность – распределенная функция (это вообще-то функция, а не подразделение). Когда ответственность не формализована, никто не отвечает за доступы, обновления, уязвимости, конфиги и мониторинг.

Например, в одной госструктуре ИТ-администраторы считали, что патчи ставит ИБ, а ИБ считала наоборот. Результат – эксплуатация старого RCE в Exchange и компрометация внутреннего домена.

Как исправить:
➡️ Составить матрицу RACI на ключевые процессы (не забывайте ее поддерживать в актуальном состоянии).
➡️ Декомпозировать зоны ответственности: ИТ, ИБ, DevOps.
➡️ Закрепить ответственность в форме KPI.

#стратегия

Читать полностью…

В последние недели вокруг атаки на американского ИТ-подрядчика Truenorth Corporation, обслуживающего десятки госагентств Пуэрто-Рико 🇵🇷, складывается удивительно разносторонняя картина. Официальные лица успокаивают: "данные граждан не утекли, сервисы восстанавливаем, все под контролем". Но инсайдеры рисуют куда более тревожный сценарий, что до боли напоминает атаки на отечественные государственные организации и компании, у которых по официальной информации "все хорошо, просто сбой", а в реальности все гораздо плачевнее 🧐

В заявлениях губернатора и государственных служб утверждается, что атака 🤕 произошла 25 ноября, в разгар длинных праздников, задев "всего" три агентства – Департамент образования, ASES (здоровье и медстрахование), государственный страховой фонд CFSE. Официальная версия говорит, что данные граждан не были украдены, службы восстановлены с резервных копий, а масштаб инцидента "контролируемый", без сбоев при оказании критических услуг населению 🤣 В публичных заявлениях – максимум спокойствия и ни слова о системной угрозе, масштабах заражения или доле недоступных сервисов.

Совсем иную историю рисует INDIARIO и источники в кибербезопасности. По данным журналистов и экспертов, знакомых с ситуацией заражены сотни серверов (>150 у CFSE, около 30 у ASES и 11 у Департамента образования) 🔓 При этом шифровальщик задел не только пользователей, но и ключевые финансовые, административные и сервисные платформы, часть которых была недоступна или работала с перебоями. В ситуацию оказались втянуты FBI и CISA 👨‍💻, что само по себе признак серьезности. Был даже активирован режим "emergencia tecnológica", то есть технологическая чрезвычайная ситуация. О последнем в официальных пресс-релизах – полный молчок 🤐

Многие в этом инциденте до сих пор остается в тени: 😦
➡️ Была ли утечка хоть какого-то объема данных?
➡️ Почему власти так осторожно комментируют масштабы?
➡️ Насколько велика зона поражения внутри Truenorth?
➡️ Сколько времени услуги работали в условиях деградации?

Правительство явно старается минимизировать информационную волну 🌊 Инсайдеры, наоборот, утверждают, что мы видим только вершину айсберга. Правда, как часто бывает в кибербезопасности, лежит где-то посередине. Но мне кажется мы еще услышим про этот кейс в новостях. Очень уж он напоминает стандартные истории последнего времени, когда атака началась с подрядчика и затронула серьезные организации, которые не хотят терять лицо. Поэтому начинается все со сбоя и, в "худшем" случае заканчивается "данные граждан/клиентов не пострадали". Но вот потом правда выплывает наружу 🤔 Но будет посмотреть...

#инцидент #недопустимое

Читать полностью…

Еду утром в лифте, слышу разговор:

– А что, пошифровали в итоге?
– Да.
– И что? Выплатили выкуп?
– Да, 2 битка!..

Интересно девки пляшут. Вот чтобы так, в лифте, столкнуться с профессиональным... А тут еще и Казначейство США 🇺🇸 подогнало отчет "Ransomware Trends in Bank Secrecy Act Data Between 2022 and 2024", в котором проанализировало 7395 BSA-отчетов, полученных FinCEN в период с 1 января 2022 по 31 декабря 2024, связанных с инцидентами программы-вымогателей, из которых зафиксировано 4194 отдельных ransomware-инцидента 🤒 Общая сумма зарегистрированных выплат по этим атакам – более $2,1 млрд. Для сравнения: за 2013–2021 годы было зарегистрировано около $2,4 млрд выплаченных выкупов по ransomware.

Медианная сумма одного выкупа: 🤒
➡️ 2022 – $124097
➡️ 2023 – $175000
➡️ 2024 – $155257
В целом за 2022–2024 чаще всего выплаты были до $250000. Важно отметить, что эти цифры – лишь часть реальной картины. Точное число атак, вероятно, гораздо выше, потому что не все жертвы заявляют о выплатах, и далеко не все через финансовые учреждения 🤑

По количеству инцидентов лидируют: 📈 производство – ~456, финансовые услуги – ~432, здравоохранение – ~389, затем ритейл и юридические услуги. По сумме выплат наибольшие потери понесли: финансовые услуги (~ $365,6 млн), здравоохранение (~ $305,4 млн), производство (~ $284,6 млн), далее научно-технологический сектор и розница.

За отчетный период было выявлено 267 уникальных вариантов программ-вымогателей 😷, на лидерами среди них были ALPHV/BlackCat, Akira, LockBit, Phobos и Black Basta. Так, ALPHV/BlackCat является лидером по сумме выплат – около $395,3 млн, а Akira – лидер по наибольшему числу инцидентов (376) 🥷

Что касается способов коммуникации, то в ~42 % отчетов описан способ связи с вымогателями 🤝 Из них 67% через TOR, 28% – по email, остальные через мессенджеры с E2EE, файлы и пр. В оплатах доминировала криптовалюта Bitcoin (BTC) – ≈97% всех зафиксированных транзакций. После получения выкупа злоумышленники часто использовали нехостинговые, "холодные" криптокошельки (unhosted CVC-кошельки) и далее – криптовалютные биржи для отмывания средств 💴

#ransomware #отчет #статистика #ущерб

Читать полностью…

Мария врывается в инфополе с разбором ИБ-инцидента Аэрофлота 🛩, о котором все предпочитают молчать, потому что никто никому ничего не говорит. Особенно удручает позиция НКЦКИ в этой ситуации, что в очередной раз ставит вопрос о том, что у нас в стране все равны, но есть те, кто ровнее 🤔

#инцидент #supplychain

Читать полностью…

Ошибка №24. Выгорание специалистов ИБ

Перегруженные специалисты совершают ошибки, принимают плохие решения и покидают команду.

Например, SOC-команда крупной авиакомпании пропустила ранние признаки атаки, потому что работала в режиме постоянных переработок.

Как исправить:
➡ Реалистичные и обоснованные нагрузки.
➡ Автоматизация рутинных операций
➡ Поддержка команды и программы благополучия (well-being).

#стратегия

Читать полностью…

Ошибка №22. Коммуникация ИБ на "птичьем техническом диалекте"

Когда CISO говорит на языке CVE, SIEM, EDR, SOC и ATT&CK, бизнес слышит белый шум. В итоге нужные решения не принимаются.

Например, одна компания откладывала внедрение MFA три года, потому что "доклад ИБ непонятен". После демонстрации удачного бизнес-кейса внедрили за месяц.

Как исправить:
➡ Переводить риски на язык денег и последствий.
➡ Давать руководству понятные ему сценарии и альтернативы.
➡ Построить "CISO Dashboard" с бизнес-метриками.

#стратегия

Читать полностью…

Ошибка №20. Отсутствие сети контактов между специалистами

Во время инцидентов часто теряется драгоценное время, потому что ИБ, ИТ, DevOps, юристы, PR, подрядчики или специалисты с иными нужными компетенциями просто не могут оперативно связаться друг с другом. Контакты устарели, лежат в недоступных системах, хранятся у одного человека или вовсе отсутствуют.

Например, в одном финтехе при компрометации CI/CD ИБ не смогла найти DevOps-лида – его контактов не было в актуальном списке. В результате восстановление задержалось на несколько часов, и злоумышленники успели распространить вредоносный код на продовый кластер.

Как исправить:
➡ Создать и обновлять единый перечень аварийных контактов.
➡ Хранить его в нескольких местах, включая офлайн.
➡ Включить коммуникационные сценарии в программу учений.

#стратегия

Читать полностью…

Ошибка №18. Legacy-системы

Старые ОС, уже не поддерживаемые производителем компоненты, устаревшие сервера и оборудование – идеальная мишень для атак.

Например, WannaCry массово поражал Windows XP, которая продолжала использоваться в больницах и госучреждениях.

Как исправить:
➡ Разработать и реализовывать план миграции.
➡ Виртуализация и изоляция legacy.
➡ Мониторинг вокруг критичных legacy-узлов.

#стратегия

Читать полностью…

Ошибка №16. Нет регистрации событий и мониторинга

Компания может быть взломана месяцы назад – и не знать об этом, а хакеры орудуют внутри инфраструктуры, не боясь обнаружения.

Например, Equifax была скомпрометирована более двух месяцев прежде, чем заметила активность в системе.

Как исправить:
➡ Регистрация всех критичных для конкретной компании/процесса/системы событий.
➡ Централизация логов.
➡ Построение SOC с аналитикой и ML-корреляцией событий.

#стратегия

Читать полностью…

Ошибка №14. Ошибки конфигураций

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

Например, открытые для общего доступа корзины Elasticsearch/S3/MinIO приводили к утечкам миллионов данных в компаниях Uber, Verizon и десятках других.

Как исправить:
➡ Применять автоматические сканеры конфигураций.
➡ Проверять соответствие политикам безопасности (например, CIS Benchmarks или предоставленные разработчиками сканеров безопасности).
➡ Обязательный анализ кода IaC.

#стратегия

Читать полностью…

Ошибка №12. Нет безопасной разработки и контроля изменений

Продукт выходит быстрее, чем его успевают проверять на предмет безопасности. Небезопасные настройки по умолчанию, жестко зашитые ключи и секреты, слабая авторизация – типичные дефекты, приводящие к ущербу.

Например, в 2022 один финтех-стартап потерял десятки миллионов из-за ошибки в авторизации в API (IDOR). Ошибка появилась после "быстрого" релиза кода без его анализа.

Как исправить:
➡ Ввести в компании практику DevSecOps.
➡ Включение Security Gate в CI/CD.
➡ Внедрить статический и динамический анализ и проверка IaC.

#стратегия

Читать полностью…

Ошибка №10. Нет реестра активов

Нельзя защитить то, чего не знаешь. Замурованные в стены сервера (был у меня такой кейс как-то), виртуалки-"летучие голландцы", установленные для удобства Wi-Fi-точки доступа, забытые VPN-доступы, старые тестовые стенды – все это прекрасные входы внутрь инфраструктуры.

Например, в Colonial Pipeline одной из точек входа был старый VPN-аккаунт без MFA, невнесенный в список активов.

Как исправить:
➡ Формирование собственной базы CMDB или доступ к ИТшной, а также автоматическое обнаружение активов.
➡ Инвентаризация облаков, SaaS, теневых ИТ (shadow IT), включая теневые ML.
➡ Классификация данных и сервисов по критичности для бизнеса.

#стратегия

Читать полностью…

Ошибка №8. Нет отлаженного процесса реагирования

SOC находит проблему, но дальше начинается хаос. Кто блокирует? Кто согласует отключение атакованных систем? Кто информирует вышестоящее начальство об инциденте? Кто занимается восстанавлением?

Например, в медицинской организации SOC увидел расширение плацдарма (lateral movement) шифровальщиком, но не смог остановить атаку из-за отсутствия полномочий. Через 3 часа был зашифрованы сегменты с данными пациентов, электронными медицинскими записями и медицинским оборудованием.

Как исправить:
➡ Создать соответствующие плейбуки под типовые для организации инциденты с указанием ролей, сценариями действий, чеклистами.
➡ Проводить регулярные киберучения (штабные и технические, на киберполигонах).
➡ Дать SOC привилегии осуществлять "срочные действия".

#стратегия

Читать полностью…

Ошибка №6. Пентесты раз в год вместо постоянного контроля

Однократный пентест – иллюзия безопасности. Уязвимости появляются ежедневно.

Например, один банк прошел летом пентест в соответствие с требованиями Банка России и ФСТЭК. Осенью появилась критическая уязвимость в VPN-шлюзе – ее никто не заметил. Через нее APT-группировка получила доступ внутрь банковской инфраструктуры и месяц держалась внутри сети.

Как исправить:
➡ Внедрить постоянное сканирование уязвимостей, в том числе включая и внедрение решений класса BAS (Breach & Attack Simulation).
➡ Проводить периодические Red Team / Purple Team.
➡ Выставить компанию или ее ключевые системы на Bug Bounty и кибериспытания.

#стратегия

Читать полностью…

Ошибка №4. Ориентация только на инструменты

Руководство покупает "волшебные коробки", а процессы остаются прежними. SIEM без собственных, регулярно обновляемых правил корреляции, DLP без классификации информации согласно ее ценности и процессов обработки, EDR без реагирования – мертвые инвестиции.

Например, компания внедрила SIEM, но не выделила команду аналитиков, которые бы постоянно проводила анализ событий ИБ, адаптацию правил, написание корреляционных цепочек и т.п. Полгода SIEM работал "на запись", а атака через компрометацию VPN-доступа осталась незамеченной – хотя события были в логах.

Как исправить:
➡ Любой инструмент не может существовать без людей, процессов и интеграции.
➡ Начинать нужно с процессов, а не с закупок.

#стратегия

Читать полностью…

Ошибка №2. Не работают политики и регламенты

Документы есть, но они либо не отражают реальность, либо никто им не следует. Сотрудники подписывают положения "для галочки", а процессы строятся вне нормативов.

Например, в одной финансовой компании политика по управлению доступами требовала отключать доступ уволенного сотрудника в течение часа, но ИТ делала это "когда дойдут руки", а иногда и вовсе не узнавала о факте увольнения, так как HR "забывал" уведомить об этом соответствующие подразделения. Инсайдер, экс-сотрудник, воспользовавшись этим "окном" унес из облачной CRM десятки контрактов.

Как исправить:
➡️ Политики должны описывать реальные процессы, а не процессы должны подстраиваться под бумажные процессы.
➡️ Нормативы должны быть встроены в ITSM / DevOps-платформы.
➡️ Контроль исполнения – обязательная часть аудита.

#стратегия

Читать полностью…