Пост Лукацкого

01 October 2025 06:39

В середине 20-го века кибернетик Росс Эшби сформулировал закон необходимого разнообразия, суть которого в том, чтобы эффективно контролировать систему, управляющий орган 👉 должен обладать достаточным набором состояний, сопоставимым с числом возможных состояний управляемой системы. Иными словами, если внешняя среда или объект, которым мы управляем, может вести себя множеством способов, то и управляющий механизм должен быть способен реагировать столь же разнообразно, иначе он будет неэффективен. Закон этот применим во многих сферах - в управлении организацией, в биологии и, конечно же, в ИТ и ИБ 🛡

Например, согласно этому закону если атакующий может использовать сотни векторов атак, а защитник строит оборону только от трех-четырех сценариев, то защита будет слабой и неэффективной 🔓 Чтобы быть адекватным угрозам, защита должна обладать сопоставимым "разнообразием" средств: мониторинг, сегментация, резервирование, сценарное моделирование, автоматизация, обучение пользователей, патч-менеджмент, предотвращение угроз, харденинг и т.п. (изучайте, мать его, проекты MITRE - ATT&CK, D3FEND, SHIELD и иже с ними – они как раз для этого и существуют) То есть наличие широкого спектра защитных мер и средств – это не блажь, а требование закона, по которому существует Вселенная 🤹

Отсюда вроде как возникает очевидная проблема – система управления ИБ должна быть не менее сложной, чем множество управляемых ею сущностей 🧘‍♀️ Но мы же все хотим простоты, которая подразумевает, что система управления ИБ будет максимально унифицированной, автоматизированной, работать по нажатию "одной кнопкой". То есть набор возможных реакций должен быть предельно ограничен, что вступает в конфликт с законом Эшби. Но в реальности все немного иначе 😂

Система может казаться простой снаружи ("одна кнопка", "обнаружить и остановить", автономный SOC), но внутри нее работает множество правил, алгоритмов и сценариев реагирования 🎮 Пользователь видит простое управление, а "разнообразие" скрыто в алгоритмах. Также, не обязательно, чтобы "одна система" содержала все разнообразие. Можно распределить его между слоями: часть ответственности – у продукта ИБ, часть – у SOC, часть – у облачного сервиса. В итоге совокупность экосистемы покрывает разнообразие угроз 🤕

Невозможно создать реально эффективную "одну кнопку" 🔲, которая бы решала все вопросы ИБ. Но можно создать интерфейс одной кнопки, за которым скрывается "оркестр" механизмов, соответствующих закону необходимого разнообразия. Без тех же SIEM/SOAR/мета-продуктов/whatever оператор не смог бы эффективно управлять всем разнообразием: слишком много средств, слишком много сигналов тревоги, слишком много возможных вариантов реагирования – блокировать, детектировать, предупреждать, помещать в карантин, шифровать, изолировать, уведомлять, патчить, контратаковать и т.п. 🚫 Человек бы "тонул" в событиях. SIEM и SOAR – это как раз инструменты реализации закона необходимого разнообразия на практике. Они делают так, чтобы у организации был достаточный набор реакций на угрозы, но при этом оператор не утонул в сложности 🤔

Так что в следующий раз, когда пойдете за защитой бюджета на SIEM 🧬 или SOAR 🚘, ссылайтесь на доказанный математический закон! Вдруг сработает?!

#наука

Пост Лукацкого

30 September 2025 15:42

В Дэчжоне (Южная Корея) 🇰🇷 пару дней назад произошел масштабный пожар в Национальной службе информационных ресурсов (NIRS) – ключевом государственном дата-центре, который представляет собой некий аналог наших Госуслуг. Возгорание началось при перемещении литий-ионных батарей источников бесперебойного питания (UPS): одна из них вспыхнула (в итоге нахрен сгорели все 384 батареи), огонь быстро охватил соседние модули, температура в серверных поднялась до 160 °C 🔥

Масштаб ущерба по первоначальными прикидкам нехилый: 💥
➖ Пострадало 647 государственных информационных систем.
➖ 96 из них – "Grade 1", то есть ключевые, от функционирования которых зависят критически важные сервисы, среди которых налоговые системы, государственные порталы, сервисы идентификации граждан, системы статистики и закупок.
➖ На момент публикации восстановлено лишь ~11% сервисов, работу части систем перенесли в другие центры.
➖ Восстановление может занять до 1 месяца (по предварительным оценкам).

Правительство Южной Кореи признало, что планы аварийного восстановления были недостаточными 🖕, а концентрация столь важных сервисов в одном ЦОД создала "единую точку отказа". Очередной президент (после череды импичментов и посадок местных главнокомандующих я уже потерялся в их именах; то ли дело в стабильных экономиках типа Северной Кореи или России) заявил, что он шокирован произошедшим и не ожидал, что страна, претендующая на лидерство в сфере высоких технологий так накосячит, доведя ситуацию до недопустимой (так и сказал) 🤬

Меня в этом кейсе интересует ситуация с кибербезопасностью 🛡 Деталей немного, но вот что удалось найти в разных источниках:
➖ Национальная разведка повысила уровень киберугроз: в условиях хаоса злоумышленники могут воспользоваться уязвимостями во временных или обходных схемах восстановления. Это скорее косвенный признак затронутости контуров ИБ, имеющихся в сгоревшем ЦОДе.
➖ Власти заявили, что "99% ключевого оборудования безопасности" уже восстановлено, но конкретные ИБ-системы не названы и что относится к ключевым не очень понятно 🤷‍♀️
➖ Эксперты, комментирующие инцидент, отмечают, что подобные инциденты иллюстрируют неотделимость кибербезопасности от физической инфраструктуры – пожар или сбой питания могут привести к коллапсу цифровых сервисов, открытым "окнам реализации угроз" и увеличившейся площади атаки ☺️

Длившийся 22 часа пожар в NIRS стал не только технологической, но и ИБшной катастрофой: миллионы граждан временно остались без онлайн-госуслуг, а государству пришлось срочно усиливать защиту и пересматривать планы резервирования и отказоустойчивости 🍑 Ну а мы все получили очередной очевидный урок – распределенная архитектура и реальные планы disaster recovery должны быть обязательными, иначе один инцидент может парализовать целую страну 🌎

#инцидент #недопустимое #непрерывность #киберустойчивость

Пост Лукацкого

30 September 2025 06:40

ФСТЭК 🗂 выпустила методику проведения пентестов, которая применяется в ходе аттестации информационных систем, контроля защищенности и оценки соответствия требования по ИБ и достаточности принимаемых мер по защите. Сам документ ДСПшный и поэтому рассказывать о нем я не буду, но сам факт движения регулятора в сторону практической оценки реального состояния ИБ не может не радовать.

Однако, чтобы не ограничиваться одним лишь только информационным фактом выхода документа, который вы не можете скачать с сайта регулятора, а можете только запросить его в своем территориальном управлении, решил, что было бы неплохо дать список национальных и наднациональных регуляторов / агентств, которые публиковали официальные методики, рекомендации или требования по проведению пентестов, чтобы можно было быстро сравнить с новым документом ФСТЭК, когда он попадет к вам в руки.
1️⃣ NIST (США) – SP 800-115 Technical Guide to Information Security Testing and Assessment – подробное руководством по планированию и проведению оценки защищенности (включая пентесты), правила согласования RoE, методики анализа результатов.
2️⃣ Банк России (Россия) – выпустил "Методические рекомендации Банка России по проведению тестирования на проникновение и анализа уязвимостей информационной безопасности объектов информационной инфраструктуры организаций финансового рынка", о которых я уже писал.
3️⃣ NCSC (Великобритания) – практическое, но не очень большое руководство по проведению пентестов (commissioning, scope, reporting), ориентированное на государственные и частные структуры.
4️⃣ ENISA (ЕС) – хотя ENISA фокусируется шире (кибер-стресс-тесты и киберустойчивость в рамках NIS2), у агентства есть подробные хэндбуки и технические рекомендации, полезные для масштабных и критичных проверок (включая сценарии и методологию тестирования).
5️⃣ BSI (Германия, Федеральное бюро по ИБ) – практические рекомендации (на немецком) по проведению пентестов и проверкам веба; BSI дает практичные указания по организации, частоте и объему тестов, включая требования для операторов КИИ (KRITIS).
6️⃣ ANSSI (Франция) – ANSSI не только и не столько про пентесты, но в своих материалах (EBIOS, PASSI) они прописали требования к аудиторам/оценщикам (PASSI-квалификация), перечень видов тестов (включая пентесты) и методики риск-ориентированной оценки.
7️⃣ PCI Security Standards Council – отдельное официальное руководство по пентестам для организаций, работающих с платежными картами (детализирует требуемый охват, квалификацию тестировщиков и формат отчетов).
8️⃣ CSA / MAS (Сингапур) – сингапурские регуляторы (включая CSA и требования MAS к финсектору) публикуют руководства и условия лицензирования для провайдеров пентестов.
9️⃣ GovCERT / DPO (Гонконг) – практическое руководство "Practice Guide for Penetration Testing" для госорганов.

Если подытожить, то большинство регуляторов идут по одному сценарию: обозначить цель и охват (CDE/критичные сервисы), согласовать RoE/правовые рамки, прописать квалификацию тестировщиков, разделение типов тестов (black/grey/white), требования к отчетности и срокам исправления. ENISA в ЕС 🇪🇺 и некоторые регуляторы (APRA, BSI) сильнее фокусируются на тестировании киберустойчивости и интеграции пентестов в программу непрерывного контроля и стресс-тестирования (кибериспытания).

#регулирование #пентест #оценказащищенности

Пост Лукацкого

29 September 2025 15:42

Интересно девки пляшут 🤦‍♂️ Сначала разработали требования по защите персональных данных и сделали их обязательными. Потом решили, что этого мало, и надо ввести еще и штрафы за инциденты с ПДн; причем независимо от того, как ты их защищаешь. Ну внедряешь ты риск-ориентированный надзор, ну ты хоть прочитай, что это такое. Тут либо обязательные требования и штраф за нарушение требований, либо никакой обязаловки, но штраф за нанесение ущерба субъектам. Но зачем объединять две сущности? Это пошло еще с Банка России с его требованиями по ИБ и по рискам ИБ (ну и по операционной надежности до кучи), но потом плавно перешло и на тему персональных данных. Ну вот и успокоились бы на этом, но нет 🙅‍♂️

Теперь Всероссийский союз страховщиков (ВСС) решил присосаться к этой титьке и тоже подоить операторов ПДн. Но как это сделать? За средства и сервисы защиты бабки стригут вендора и интеграторы 🤑 Штрафы берет себе государство. А как еще остричь эту полуголую овечку? Давайте заставим операторов страховать риски утечки ПДн и пусть это будет обязательной мерой, решили в ВСС 😮 И ладно бы с этой инициативой выступил какой-нибудь Роспотребнадзор, который защищает права потребителей. Так нет же. ВСС защищает интересы страховых компаний и выступает с законодательными инициативами от их имени. То есть желание внедрить обязательное страхование ответственности за утечки личной информации – никак не влияет на защиту прав граждан – это всего лишь способ заработать бабла для страховых 🫢

Ладно, с арифметикой у ВСС не очень (вот я считал и тут); хотя считать они должны уметь 🧮 Но хотя бы подумать о том, что задача защиты прав субъектов ПДн заключается в первую очередь в предотвращении утечки ПДн, а не вероятной компенсации ничтожной суммы денег, они могли бы? Или думать у нас уже не в моде, когда на горизонте триллионы рублей маячат 🤑

#регулирование #ущерб #персональныеданные #киберстрахование

Пост Лукацкого

29 September 2025 10:16

Пишут тут, что некто взломал внутреннюю систему управления учетными записями пользователей в X (бывший Twitter) 📱 Вектор не понятен, но хакер дал понять, что это как-то связано с LinkedIn (может письмо от лже-HR с фейковым тестовым заданием?) 🔓

#инцидент

Пост Лукацкого

28 September 2025 19:37

Вернулся с Underconf 2, прекрасной ламповой ИБ-конференции. Окунулся в атмосферу мероприятий 90-х, без огромных бюджетов, без засилья спонсоров, создаваемые на энтузиазме. И с массой положительных эмоций 🙂

И вот, что я подумал 🤔 Все мероприятия по ИБ, которые мне доводится посещать, можно условно разделить на 4 типа:
1️⃣ Бесплатно для участников, засилье спонсоров, рекламные доклады, генеральские пленарки и вот это вот все. Полезного контента около нуля (исключения только подтверждают правило). Идти имеет смысл ради нетворкинга (шатанов на таких тусовках тоже масса и они вполне гармонично вписываются в атмосферу).
2️⃣ Вендорские семинары и конфы. Ну тут, вроде, все и так понятно.
3️⃣ Платные для участников (перелет и проживание за деньги или «представителям ИБ-компаний за 35000 рублей» не в счет). Тут обычно качественный контент, но мероприятия вообще не массовые. Спонсоры тут редки и нужны только для поддержания базового или среднего уровня организации (а не оплаты участия «генералов»). Рекламы около нуля. И контент, и нетворкинг на уровне.
4️⃣ «Митапы». Обычно проводятся одной компанией или при ее поддержке. Очень душевно, мало людей, на энтузиазме обычно одного человека, который хочет сделать хорошо. И контент, и нетворкинг недурны.

В последнее время все больше хочется именно третьих или четвертых, чтобы была ощутимая польза, а не вот это вот все 🙄 Но у нас такое, к сожалению, огромная редкость. Тем приятнее было в воскресный день посетить Underconf 2, начавшийся с 8.30 утра 😨, который, я надеюсь, продолжит существовать и дальше. Енот, спасибо за приглашение!!! 🤝

Ну а мы готовимся уже к PHDays, в котором пытаемся вобрать лучшее от всех форматов, но без ламповости; при таких масштабах это прям невыполнимая задача; как мне кажется.

ЗЫ. А часть докладов я бы даже пересмотрел 👀 Может в канале выложат ссылки.

#мероприятие

Пост Лукацкого

28 September 2025 14:01

Перефразируя thegrugq и адаптируя к русскому языку:

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

🔤одобрать: подбор паролей (brute force), их угадывание
🔤красть: кража паролдей с помощью вредоносного ПО, перехват паролей в каналах связи
🔤просить: социальный инжиниринг
🔤упить: логи стилеров и брокеры первоначального доступа (IAB).

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

Пост Лукацкого

27 September 2025 19:32

Подписчик, за что ему спасибо, прислал осенне-бюджетное...

#юмор

Пост Лукацкого

27 September 2025 14:05

Издана моя книгу "Опасная профессия. Будни работы в сфере информационных технологий". Издана полностью за свой счет. Книга адресована широкому кругу читателей. В первой части вы найдете примеры жизненных ситуаций, приведших к возбуждению уголовных дел по компьютерным преступлениям. Во второй части рассмотрены примеры участия гражданина в следственных действиях (свидетель, потерпевший, понятой, обвиняемый и т.д.). Описаны следственные мероприятия и меры пресечения. В третьей части — примеры уголовного наказания за компьютерным преступлениям.
Бесплатная электронная версия на сайте издательства https://ridero.ru/books/opasnaya_professiya_1/#reviews
P.S. Канал как и ранее закрыт для новых публикаций.

Пост Лукацкого

27 September 2025 08:40

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

Одна компания заявляет, что на нее совершается кибератак больше, чем на Госуслуги. Другой регулятор хвалится, что в первом полугодии одного года утечек персональных данных уже больше, чем за весь предыдущий год. Вендор системы обнаружения атак утверждает, что он добавил еще стопиццот сигнатур атак в свой продукт, а производитель SIEM бравирует ростом на 146% числа корреляций 📈

И только заказчики хотят, чтобы у них было меньше - меньше атак, меньше уязвимостей, меньше утечек, меньше сработок SIEM, меньше инцидентов... 📉 И чтобы стоило это все меньше. Но цены тоже растут - на бензин, на кофе, на услуги хакерских группировок, на инструменты взлома, на средства ИБ... Так и живем в условиях разнонаправленного движения – одним нужно больше, другим меньше. И конца и края этому не видно... 🔫

#метрики

Пост Лукацкого

26 September 2025 15:42

Ну как так-то? К монитору приклеен стикер с легко угадываемым логином и ооооочень сложным паролем. При этом видно окошко про подключение к удаленному рабочему столу 📱 И все это перед глазами любого посетителя. Вот даже и не знаю, жалко мне будет эту организацию, когда их взломают, или нет?.. 😔

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

Пост Лукацкого

26 September 2025 06:40

11 сентября 2025 года Администрация киберпространства Китая (Cyberspace Administration of China, CAC) утвердила "Меры по управлению отчетностью об инцидентах ИБ", вступающие в силу уже в ноябре этого года (полтора месяца на то, чтобы подготовиться к новой нормативке – очень амбициозно). Всего 14 статей и приложение с классификацией тяжести инцидентов. Основная цель нового регулирования – стандартизировать механизм сообщения о киберинцидентах, ускорить реагирование, снизить ущерб и повысить устойчивость национальной системы кибербезопасности (готовятся они к чему-то что ли?) 🇨🇳

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

Не все инциденты требуют отчета в CAC, а только те, которые достигают порогов "относительно крупный", "крупный" или "особо крупный", согласно приложению по классификации:
✔️ Масштаб влияния на жителей (например, > 50% населения провинции или >10 млн чел. – особо крупный).
✔️ Объем ПДн (≥ 1 млн; ≥ 10 млн; ≥ 100 млн записей). Обратите внимание, что китайцы начинают считать от 1 миллиона, а не 10 тысяч, как в РФ.
✔️ Простой КИИ (например, общий сбой ≥ 10 мин/1 ч/6 ч; отказ ключевых функций ≥ 30 мин/3 ч/24 ч).
✔️ Прямые убытки (≥ 5 млн / ≥ 20 млн / ≥ 100 млн юаней).
✔️ Захват/дефейс порталов властей/СМИ/крупных платформ с "широким" распространением вредного контента (порог по времени/просмотрам/репостам).

Сообщать обязаны любые "сетевые операторы" на материковой территории КНР (владельцы/операторы сетей, провайдеры сетевых услуг), включая КИИ и органы власти. В зависимости от типа оператора и уровня инцидента предусмотрены разные сроки уведомления:
✔️ КИИ: сообщить профильному ведомству и полиции "как можно скорее", не позднее 1 часа; при инцидентах уровня major/especially major – ведомство эскалирует в CAC и МВД КНР "как можно скорее", но не позднее 30 мин.
✔️ Центральные/госорганы: уведомляют свое интернет-информационное подразделение ≤ 2 ч; при инцидентах уровня major/especially major – далее в CAC ≤ 1 ч.
✔️ Иные операторы: в провинциальный интернет-регулятор ≤ 4 ч; при инцидентах уровня major/especially major – провинция эскалирует в CAC ≤ 1 ч.

Содержание уведомления (минимум): кто пострадал; что/где/когда, тип и уровень, ущерб, принятые меры и их эффективность; тренд развития и возможные дальнейшие последствия; первичный разбор причин; если возможно, то зацепки об источнике (атакующие/вектора атак/уязвимости); планируемые меры по восстановлению и взаимодействию с властями; доказательная база; для вымогателей – сумма/метод/время требований. Разрешен "урезанный" первичный отчет с досылкой деталей. Финальный отчет должен отправляться в течение 30 дней после завершения работ по расследованию.

Каналы приема уведомлений об инцидентах от граждан/организаций: единый номер "горячей линии" 12387, официальный сайт CERT (например, cert.org.cn) для отчетности, WeChat-минипрограммa "12387" (может и у нас с НКЦКИ можно будет в MAX общаться когда-нибудь), официальный аккаунт CNCERT в WeChat, e-mail и факс.

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

Если оператор задерживает, скрывает или лжет в уведомлении об инциденте – на него могут быть наложены штрафы; и ответственность могут нести не только юридическое лицо, но и конкретные ответственные лица. Однако если оператор смог доказать, что он применил "разумные и необходимые меры ИБ", своевременно уведомил органы и уменьшил вред – он может быть освобожден от ответственности или получить более мягкую санкцию 🐲

#регулирование #управлениеинцидентами

Пост Лукацкого

25 September 2025 15:32

Депутаты продолжают настаивать на том, что если у россиянина больше 6️⃣1️⃣ банковских карт, то он мошенник и дроппер и надо с такими бороться 😡 Банк России поддерживает эту инициативу.

Интересно, регулятор же изменит свои рекомендации, в которых прямо писал про то, что клиентам банкам стоит заводить виртуальные карты 💳 в целях безопасности, снижающие риски потерь денег? А виртуальных карт только в одном банке может быть с десяток – для каждого сервиса или маркетплейса своя. Тогда, во-первых, для разных сервисов можно свои лимиты устанавливать, а во-вторых, сразу станет понятно, откуда утекли данные, если с карты вдруг начнут пропадать деньги 🤒

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

#регулирование #мошенничество

Пост Лукацкого

25 September 2025 06:40

В комментах попросили прокомментировать тему оффбординга (offboarding) 👋, то есть управляемого "выведения" человека, аккаунта или подрядчика из вашей системы: безопасное прекращение доступа, передача дел и закрытие организационных, административных и юридических вопросов. Цель этой операции заключается в том, чтобы после ухода ничего "не висело": ни доступы, ни токены, ни незакрытые обязанности. В противном случае мы имеем нехилую такую вероятность утечек, саботажа, претензий со стороны клиента и других рисков 🔓

Когда нужен оффбординг:
➡️ Увольнение/разрыв контракта, длительный отпуск/"заморозка".
➡️ Перевод роли или уменьшение ее прав (частичный offboarding старых прав).
➡️ Завершение проекта/подрядных работ, прекращение субподряда 🔚

Триггером для оффбординга (для ИТ, ИБ, HR и, в ряде случаев, менеджера проектов) является создание тикета 🎟 "Leaver" в какой-либо внутренней системе с датой/временем увольнения/завершения проекта/смены роли, списком систем и владельцем. Сразу отмечу, что я не знаю, как на русский переводится "JML-процесс", то есть процесс жизненного цикла роли Joiner-Mover-Leaver (онбоардинг, смена роли, оффбоардинг). Поэтому использую английское название этапов этого процесса ❌

Что будет включаться в оффбординг? Начинается с доступов (ИБ/ИТ), которые надо отключать/удалить/отозвать: 🙈
➡️ Отключить SSO/MFA пользователя (IdP), VPN, почта/чат, таск-треки.
➡️ Удалить из групп/ролей в Git, CI/CD, облаке, WAF/CDN, аналитике, доменах/DNS, CRM, биллинге, менеджерах паролей.
➡️ Отозвать API-токены, SSH-ключи, персональные PAT, ключи KMS/Vault, вебхуки от имени пользователя; пересоздать общие секреты, если были доступны.
➡️ Закрыть внешние SaaS (Notion, Figma, Miro, Холст, Statuspage, мониторинг и т.п.).
➡️ В клиентском окружении надо будет также отозвать доступы (если выдавались), уведомить контакт ИБ клиента (по договору) ❌

❗️ Важно! Отзывая доступ, не забывайте, что иногда (хотя такого быть не должно) работники регистрируются в системах со своих личных аккаунтов, например, с gmail.com, так как "у меня исторически доступ к Github с личной почты". И если мы будем отзывать доступ по маске корпоративного домена, то можем упустить личные учетные записи 📬

Дальше-больше. Надо зачистить устройства и данные: 🔏
➡️ Через MDM: блокирование/очистка (wipe), инвентаризация, возврат техники и аппаратных токенов 2FA.
➡️ Передача артефактов/документов владельцу, перенос прав на репозитории/борды/ИТ/ИБ-системы/оборудование.

Изменение коммуникаций и почты. Вот этого почти нигде никогда не видел, хотя реализуется просто и дает возможность уведомить тех, кто не знает об изменениях 📨 В противном случае можно будет осуществлять фишинговые атаки от имени этого, уже не "нашего" пользователя:
➡️ Автоответчик "контакт изменился", переадресация на его заместителя на 7–14 или более дней.
➡️ Отключить личные переадресации/внешние интеграции.

Юридические и административные вопросы:
➡️ Напоминание об NDA/неразглашении, закрытие финансовых расчетов.
➡️ Акт уничтожения/возврата, отметка в реестре оффбординга, обходной лист 🤑

Проверка и закрытие темы: 😝
➡️ Выгрузка логов входов/действий за последние 7–30 дней (PAM/SIEM/DLP/IdP).
➡️ Проверка "хвостов": нет ли его e-mail в правилах, алиасах, вебхуках, не остались ли созданные ушедшим пользователем учетные записи.
➡️ Закрыть тикет с чек-листом и ссылками-доказательствами.

Частые ошибки, которые совершаются при оффбоардинге: 😱
➡️ Оставили бота/сервисный токен, созданный из личного аккаунта.
➡️ Не убрали доступ к аналитике/рекламным кабинетам и системам управления доменами.
➡️ Забыли отключить внешние SaaS (Notion/Figma и т. п.) – платежи и доступы живут.
➡️ Не сменили владение репозиториями/проектами – блокируются релизы.

ЗЫ. Уходя из Cisco, оставил всех уточек 🛁 в офисе.

#bestpractice

Пост Лукацкого

24 September 2025 15:41

Чем зрелее 📈 программа повышения осведомленности по ИБ, тем более персонализированной она будет. Идея простая (я про нее писал выше). Для разных ролей хакеры используют обычно разные способы атак, а значит требуются и разные методы проверки знаний и навыков, тестирующие разные привычки и защитные меры, присущие каждой роли. Учим не всех всему одинаково, а каждого важному именно для него! 🧑‍💻

Как персонализировать обучение: 🤔
💡 Контент. Примеры из типичных процессов тестируемых (счета/договора для финансовых работников; pull-requests/CI – для разработчиков, резюме/вакансии – для HR, новые требования ФНС и Банка России – для бухгалтеров).
💡 Каналы. Финансистам – в почту и в корпоративный мессенджер; разработчикам – баннер в Git/CI и карточка в issue tracker; подрядчикам – портал поставщика.
💡 Частота. Ролям высокого риска нужны короткие подталкивания чаще, остальным – реже.
💡 Формат. Микровидео/чат-карточка/симуляция – выбираем по данным A/B-тестов.

Например:
📎 Для разработчиков. Основные угрозы связаны с секретами в коде, токенами, цепочкой поставок. Значит мы должны у них сформировать привычки "Не храним секреты в репо", "Подписываем коммиты", "MFA/Passkeys в Git". Как проверяем? Например, сканирование секретов, SSO+MFA к Git/CI, внедряем правило "no-push with secrets" 👨‍💻

📎 Для подрядчиков. Основные угрозы связаны со слабой базовой гигиеной и избыточными доступами. Хотим добиться реализации привычек "Работаем только с корпоративных устройств/VDI", "Доступ – по заявке и с конкретным сроком действия". Соответственно реализуем через JIT/JEA, VDI, изоляцию сетей, обязательный онбординг/оффбординг 🤝

📎 Для финансов/бухгалтерии. Мы боимся BEC и подмены реквизитов в транзакциях и платежных документах. Значит какие привычки нам надо формировать? Правильно. "Не платим по e-mail без независимой верификации", "Звоним по номеру из CRM, а не из письма" и т.п. Защитные меры – двойной контроль платежей, обязательный обратный звонок, белый список поставщиков и т.п. 🤑

Я думаю, суть персонализации, которая начинается на 4-м и продолжается на 5-м уровне модели зрелости повышения осведомленности, понятна из описанного. Дальше ее можно развить уже на свою организацию, свои роли, свои процессы. Это не так сложно, если просто сесть и подумать, провести декомпозицию 🤔 И не так дорого, кстати. Да, займет чуть больше времени на подготовку контента, но зато и эффект выше.

#обучение #awareness

Пост Лукацкого

30 September 2025 19:30

Феликс Эдмундович со своим отлитым в граните:

"Отсутствие у вас судимости – это не ваша заслуга, а наша недоработка"

Пост Лукацкого

30 September 2025 11:34

Итак, я выложил статью про накопители и хранилища для SIEM ✍️ Там и HDD vs SSD, и SAN vs NAS, и Data Lake, и горячие/теплые/холодные корзины, и рекомендации по выбору для компаний разного масштаба. В общем подсобрал все, что у меня было, в один материал. Может и на курсе по SOC смогу про это упомянуть 🤠

#soc #siem

Пост Лукацкого

29 September 2025 19:22

В последней iOS от Apple появились свои фишки по борьбе с телефонным мошенничеством 📞 Пока не пробовал в деле.

#мошенничество

Пост Лукацкого

29 September 2025 11:34

Вы же знаете, как я люблю моделирование угроз? 💋 Поэтому на вчерашнем Underconf 2 я не мог пройти мимо карточной игры, посвященной этому важному процессу, с которого должна начинаться любая ИБ. Это была карточная игра Elevation of Privilege, первоначально разработанная Адамом Шостаком (известный гуру моделирования угроз и ИБ-геймификации), а сейчас переведенная на русский язык коллегами из Ever Secure и которая позволяет проверить свой проект на предмет учета угроз по методике STRIDE. Вешаете на доску архитектуру своей проектируемой или спроектированной системы и вперед, начинаете в игровой форме 🕹 задавать себе важные вопросы, подсвечивающие то, что вы могли упустить и что может привести к реализации негативных, а местами и катастрофических, последствий.

Жду, когда коллеги выпустят эту колоду в мир и ее можно будет купить. Главное, успеть, это сделать, чтобы не попасть в лист ожидания, как с книгой "На⭐️уй безопасность" тех же авторов ⏳

ЗЫ. Кстати, хотите почувствовать себя багхантером? Найдите на одной из фотографию явную ошибку 🤔

#модельугроз #геймификация

Пост Лукацкого

29 September 2025 06:40

6 августа 2025 года Национальный центр кибербезопасности Великобритании (NCSC) 🇬🇧 официально выпустил новую версию Cyber Assessment Framework v4.0 (CAF v4.0), своей рамочной модели ИБ, предназначенной для организаций, особенно тех, кто работает в критически важных секторах (энергетика, транспорт, здравоохранение, цифровая инфраструктура и др.). Этот фреймворк помогает оценивать и управлять киберрисками, выстраивать киберустойчивость и соответствовать нормативным требованиям (например, европейским NIS и NIS2). Новая версия ориентирована на то, чтобы "поднять планку" ожиданий – не просто адаптировать старые требования, а переместить акцент с реактивных мер к более проактивной, интеллектуальной защите.

Из нововведений:
1️⃣ Понимание угроз (новый элемент A2.b "Understanding Threat"). Теперь организациям требуется не просто учитывать актуальные угрозы, но документировать методы анализа угроз, моделировать возможные сценарии атак (например, с помощью "деревьев атак") и демонстрировать четкое понимание мотивов, методов и возможностей злоумышленников. Напоминает отечественную методику оценки угроз ФСТЭК, но не столь детально. Это изменение переводит моделирование угроз из "фоновой" задачи в одну из ключевых составляющих оценки ИБ.

2️⃣ Безопасная разработка и поддержка ПО (новый элемент A4.b "Secure Software Development and Support"). CAF v4.0 требует, чтобы программное обеспечение (как внутренней разработки, так и внешних поставщиков) строилось и обслуживалось с учетом безопасных практик: отслеживание происхождения компонентов, анализ кода (статический/динамический), проверка надежности каналов обновлений, контроль уязвимостей библиотек и зависимостей. Поставщики должны иметь возможность показать, что используют признанные методологии безопасной разработки (например, NIST SSDF, Microsoft SDL).

3️⃣ Усиление мониторинга и охоты за угрозами (C1 и C2). В разделе мониторинга (C1) добавлены требования по оценке поведения пользователей и систем, интеграции данных TI и использованию обнаружения аномалий, а не просто сигнатурных подходов. В разделе threat hunting (C2) появились требования к документированному, повторяемому и улучшаемому подходу: охота за угрозами должна быть основана на данных TI, она должна документироваться, и ее результаты должны трансформироваться в автоматические детекты там, где это возможно. Таким образом, CAF v4.0 подталкивает организации от пассивного к активному поиску скрытых атак, даже тех, которые не попадают под стандартные индикаторы компрометации.

4️⃣ Усиление требований к планированию реагирования и восстановления (D1 и др.). План реагирования на инциденты теперь должен опираться на глубокое понимание инфраструктуры и зависимостей, быть адаптивным, регулярно пересматриваться и включать взаимодействие с поставщиками. Также отмечается, что существует интеграция ИИ-рисков в разные части фреймворка, поскольку технологии автоматизации и ИИ все больше входят в область как защиты, так и атак.

5️⃣ Интеграция рисков, связанных с ИИ и автоматизацией. CAF v4.0 не создает отдельный раздел только для ИИ, но включает требования, чтобы новые и автоматизированные технологии учитывались при управлении рисками, контролировались и проектировались с учетом безопасности (например, предотвращение использования ИИ как вектора атаки).

6️⃣ Уточнение и расширение индикаторов хорошей практики (Indicators of Good Practice, IGP). CAF v4.0 добавляет множество новых IGP, порядка 108 новых элементов – то есть фреймворк стал более детализированным. Эти индикаторы помогают организациям оценивать, достигнут ли тот или иной уровень (achieved / partially achieved / not achieved) по каждому из достигаемых результатов фреймворка. На второй картинке как раз показан пример IGP и можно сразу понять, достигнут у вас уровень зрелости по этому направлению или нет. Вот эти IGP прям хорошая идея для многих регуляторных документов, ибо четко дает понять, выполнен то или иное требование или нет 🤔

#регулирование #framework

Пост Лукацкого

28 September 2025 17:23

Французы знают толк в управлении рисками...

#юмор #риски

Пост Лукацкого

28 September 2025 08:40

Презентация по тенденциям, которые можно учитывать или не учитывать. Читал я ее на КибеРИТорике в Питере три недели назад и первые слайды про большую войну 💪 вызвали у слушателей неоднозначную реакцию. Ну а я считаю, что достаточно странно засовывать голову в песок и не видеть определенных сигналов (их на самом деле больше, чем упомянуто в презентации), коих с момента выступления даже стало больше 🛫 В худшем случае, вы про это будете знать и, может быть, подготовитесь. В лучшем – это все окажется глупостью, несбывшимся прогнозом (хотя вы же помните про мои прогнозы) и вообще всем peace.

#презентация #тенденции

Пост Лукацкого

27 September 2025 16:23

Уже несколько человек попросило мою презентацию с Boost про кибербез для веб-студий и диджитал-агентств. Выкладываю...

#презентация #devsecops

Пост Лукацкого

27 September 2025 14:05

Валера издал книгу 📖, для которой перелопатил огромное количество судебных, административных и уголовных, дел и показал очень интересную сторону жизни людей, связанных и связывающих себя с ИТ и ИБ. Ну и портрет нашей судебной 🧑‍⚖️ и правоохранительной 👮‍♂️ системы тоже можно по этой книге составить.

#книга

Пост Лукацкого

26 September 2025 19:41

⚠️ Вот интересно, если вы зададите себе простой вопрос:

А что если завтра я проснусь, а все ИБ-регуляторы исчезнут вместе со своими нормативами?,

Пост Лукацкого

26 September 2025 11:34

Если резюмировать последнюю нормативку Поднебесной 🇨🇳 в части уведомления об инцидентах и сравнить ее с другими государствами, то мы увидим, что Китай вводит самый "жесткий по часам" режим для тяжелых инцидентов (1–4 ч). В ЕС фиксированная двухступенчатая модель (24 ч / 72 ч / ≤ 1 мес.), в США – сочетание отраслевых (24–72 ч) и публично-рыночных (Коммисия по ценным бумагам SEC – 4 рабочих дня для инцидентов, повлекших существенные материальные последствия) режимов, а в РФ – 24 ч/72 ч для ПДн плюс свои требования для КИИ (3 ч/24 ч) 💬 То есть Россия где-то схожа с Китаем во временных параметрах. И кажется мне, что курс на сокращение времени уведомления станет скоро для всех государств нормой (а значит надо будет выстраивать систему мониторинга и вот это вот все).

Китай указывает числовые пороги для градации инцидентов (ПДн / деньги / простой / дефейс), что упрощает классификацию и облегчает заполнение уведомлений. В ЕС/США/РФ критичность чаще определяется качественным показателями. Требование к подрядчикам сообщать об инцидентах у них – прям хорошая норма, которой нам так не хватает. Ransomware как отдельная строка в первичном уведомлении (указать сумму/метод/временные параметры) – это редкий для законов уровень детализации. У американцев шифровальщики упомянуты только в требованиях CISA по уведомлению об инцидентах (Cyber Incident Reporting for Critical Infrastructure Act of 2022, CIRCIA) 🇺🇸

Кстати, о США. 30 сентября истекает срок действия закона Cybersecurity Information Sharing Act 2015 (CISA 2015) 👨‍💻 Этот закон почти 10 лет был базовым механизмом обмена киберугрозами между бизнесом и государством в Новом Свете. Его утрата, по мнению всполошившихся экспертов:
✔ лишит частный сектор и госорганы правовых гарантий для обмена индикаторами атак и иной информацией об угрозах,
✔ подорвет реализацию AI Action Plan, где предусмотрено расширение практики обмена уязвимостями и инцидентами, связанными с искусственным интеллектом,
✔ осложнит создание центров обмена информацией об угрозах для ИИ и проведение ИИ-хакатонов.

Эксперты отмечают, что так как ИИ внедряется во все отрасли, то и безопасность его должна быть выстроена с самого начала. Для этого нужны проверенные механизмы: disclosure-программы, bug bounty, red-teaming. Без возобновления действия CISA 2015 доверие и кооперация в части обмена данными об атаках, уязвимостях и пр. окажутся под угрозой 👎

Так что, кто-то выпускает новую нормативку, а кто-то борется с тем, чтобы не отменили старую. У всех свои заботы ☕️

#регулирование #threatintelligence

Пост Лукацкого

25 September 2025 19:29

В штаб-квартире ЦРУ 🇺🇸 в Лэнгли стоит известная скульптура Криптос с 4-мя зашифрованными сообщениями, три из которых были разгаданы, а вот 4-е, с момента открытия памятника 3 ноября 1990 года, так и остается неразгаданным. По поводу разгадки зашифрованного послания, автор скульптуры, Джим Санборн, ранее рассказывал, что им были приняты все необходимые меры, чтобы даже его смерть не позволила никому раскрыть полный секрет Криптоса, так как нет ни одного человека, который бы знал полное решение загадки. Он также заявил, что даже он не знает полного решения.

Но вот совсем недавно Санборн сообщил в своем письме в The Washington Post, что его все достало и он устал ждать готов выставить разгадку 🔑 4-го сообщения на аукцион, надеясь, что покупатель все-таки оставит разгадку в секрете, что сохранит ореол таинственности над Криптосом. А пока желающие, включая и подписчиков, пытаются самостоятельно разгадать 35-тилетнюю загадку. Может и вы попробуете?.. 🤔

#криптография #искусство

Пост Лукацкого

25 September 2025 11:34

Финансовый регулятор Сингапура 🇸🇬 подготовил документ по рискам, связанным с дипфейками. Простенько и со вкусом – описаны основные риски (обход биометрической аутентификации, социальный инжиниринг и дезинформация), даны реальные примеры реализации этих рисков и даны рекомендации (не требования), как бороться с этим 🎭

#аутентификация #регулирование #дипфейк

Пост Лукацкого

24 September 2025 19:45

💡 Идея нового мероприятия по антикризисным мероприятиям в ИБ. Оно начинается с регистрации, где каждому участнику со стороны заказчика вручается футболка с одной из двух надписей "Я бдю! Мы бдим! А ты бдишь?" или "Я бздю! Мы бздим! А ты бздишь?". И сразу всем понятно, кто стесняется признаваться в произошедшем у него инциденте, а кто нет. В конце мероприятия так и не распакованная коробка с футболками с первой надписью уезжает на склад до следующего года. Тем, кому не хватило футболок со второй надписью обещают прислать ее курьером 👕

ЗЫ. Чтобы пост был не просто хиханьки-хаханьки, поучаствуйте в опросе у Ники про наличие антикризисного плана коммуникаций на случай инцидента ИБ. Вам всего пару кликов, а отрасли статистические данные 📊

#юмор #антикризис

Пост Лукацкого

24 September 2025 11:34

Видимо так совпало... Вчера днем, в Кибердоме 🏠, обсуждая варианты сотрудничества, всплыла тема с возможными моими встречами перед детьми старших классов и студентов ВУЗов, которые планируют связать свою судьбу с кибербезом. Мол, наставить их на путь истинный, показать перспективу и вот это вот все 👶

Также вчера, но после выступления на Boost'е один из участников спросил меня, какие направления ИБ я считаю наиболее перспективными, так как он среди прочего преподает для детей 👦🏻 старших классов, которые интересуются кибербезом и которых надо направить в нужное русло. А так как выпускниками они станут не раньше 2030-го года, то и направления для них будут не только типовыми (пентесты, ИБ ИИ, ИБ IoT и т.п.), но и более современные (биохакинг, web3 и вот это вот все) 🔮

Наконец, и тоже вчера, мне попалась информация о проводимой в МИФИ Национальной технологической олимпиаде по информационной безопасности для старшеклассников 🏫 Хорошее начинание, как мне кажется. Так что не могу не поддержать коллег и дам ссылку на профиль по ИБ в рамках НТО, а также примеры олимпиадных задач (первая и вторая). Если у вас есть, кому отправить эти ссылки, то не стесняйтесь 🤝 Детей, идущих в ИБ, надо поддерживать!

ЗЫ. Надо будет обновить мою презентацию, которую я перед студентами МФТИ читал – готовить новое поколение ИБшников.

#обучение #работа