Уникальный контент про кибербезопасность от Алексея Лукацкого (@alukatsk) - мысли, полезные ссылки, комментарии к текущим событиям, юмор и мемасики. Канал личный - мой работодатель никак не влияет на то, что здесь публикуется. Рекламу не размещаю!!!
🇷🇺 Прокуратура Московской области сняла очередной креативный ролик о борьбе с телефонными мошенниками. А могли бы просто видео ракетных ударов по мошенническим колл-центрам показать. Гуманисты...
#мошенничество
Вот так зайдешь кофе попить перед встречей, возьмешь в руки журнальчик для детей полистать, а даже там про защиту информации пишут…
#awareness
Комикс "Безопасность в сети" для детей от отечественной киберполиции (исходники) 👦🏻👧🏼
#awareness
Помните заметку про методику оценки стоимости 🧮 кибератаки от Димы Каталкова, которую он презентовал на PHDays? Так вот пришло время поделиться и инструментом, который позволяет автоматизировать такие расчеты. Веб-версия и исходники доступны на Github.
Сам рассказ про то, как считаются квалификация и временные параметры нарушителя, стоимость инструментов и эксплойтов, инфраструктуры атакующих и зрелость ИБ в компании-жертвах с учетом отраслевой привязки, может быть найден на ресурсах PHDays 🤔
#экономика #метрики #киберпреступность #threatintelligence
Феликс Эдмундович со своим отлитым в граните:
"Отсутствие у вас судимости – это не ваша заслуга, а наша недоработка"
Итак, я выложил статью про накопители и хранилища для SIEM ✍️ Там и HDD vs SSD, и SAN vs NAS, и Data Lake, и горячие/теплые/холодные корзины, и рекомендации по выбору для компаний разного масштаба. В общем подсобрал все, что у меня было, в один материал. Может и на курсе по SOC смогу про это упомянуть 🤠
#soc #siem
В последней iOS от Apple появились свои фишки по борьбе с телефонным мошенничеством 📞 Пока не пробовал в деле.
#мошенничество
Вы же знаете, как я люблю моделирование угроз? 💋 Поэтому на вчерашнем Underconf 2 я не мог пройти мимо карточной игры, посвященной этому важному процессу, с которого должна начинаться любая ИБ. Это была карточная игра Elevation of Privilege, первоначально разработанная Адамом Шостаком (известный гуру моделирования угроз и ИБ-геймификации), а сейчас переведенная на русский язык коллегами из Ever Secure и которая позволяет проверить свой проект на предмет учета угроз по методике STRIDE. Вешаете на доску архитектуру своей проектируемой или спроектированной системы и вперед, начинаете в игровой форме 🕹 задавать себе важные вопросы, подсвечивающие то, что вы могли упустить и что может привести к реализации негативных, а местами и катастрофических, последствий.
Жду, когда коллеги выпустят эту колоду в мир и ее можно будет купить. Главное, успеть, это сделать, чтобы не попасть в лист ожидания, как с книгой "На⭐️уй безопасность" тех же авторов ⏳
ЗЫ. Кстати, хотите почувствовать себя багхантером? Найдите на одной из фотографию явную ошибку 🤔
#модельугроз #геймификация
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
Французы знают толк в управлении рисками...
#юмор #риски
Презентация по тенденциям, которые можно учитывать или не учитывать. Читал я ее на КибеРИТорике в Питере три недели назад и первые слайды про большую войну 💪 вызвали у слушателей неоднозначную реакцию. Ну а я считаю, что достаточно странно засовывать голову в песок и не видеть определенных сигналов (их на самом деле больше, чем упомянуто в презентации), коих с момента выступления даже стало больше 🛫 В худшем случае, вы про это будете знать и, может быть, подготовитесь. В лучшем – это все окажется глупостью, несбывшимся прогнозом (хотя вы же помните про мои прогнозы) и вообще всем peace.
#презентация #тенденции
Уже несколько человек попросило мою презентацию с Boost про кибербез для веб-студий и диджитал-агентств. Выкладываю...
#презентация #devsecops
Валера издал книгу 📖, для которой перелопатил огромное количество судебных, административных и уголовных, дел и показал очень интересную сторону жизни людей, связанных и связывающих себя с ИТ и ИБ. Ну и портрет нашей судебной 🧑⚖️ и правоохранительной 👮♂️ системы тоже можно по этой книге составить.
#книга
⚠️ Вот интересно, если вы зададите себе простой вопрос:
А что если завтра я проснусь, а все ИБ-регуляторы исчезнут вместе со своими нормативами?,
Если резюмировать последнюю нормативку Поднебесной 🇨🇳 в части уведомления об инцидентах и сравнить ее с другими государствами, то мы увидим, что Китай вводит самый "жесткий по часам" режим для тяжелых инцидентов (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
Презентация по упрощенной схеме финанасовой 🍍 оценки ущерба от инцидентов ИБ, которую я читал на КибеРИТорике в Питере 🧮
#презентация #ущерб
Прекрасное подогнал коллега из "the capital of Great Britain" 🇬🇧 В метро прекрасная реклама по ИБ, которая прям очень красиво обыгрывает английский язык, попутно показывая, что кибербезопасность - это не только и не столько про нормативку 🤔
#маркетинг #регулирование
Выкладываю презентацию по когнитивным искажениям (некоторым) в деятельности ИБшника с Positive Tech Day в Санкт-Петербурге 🤯
ЗЫ. Остальные презентации уже тоже на сайте.
#презентация #психология
В середине 20-го века кибернетик Росс Эшби сформулировал закон необходимого разнообразия, суть которого в том, чтобы эффективно контролировать систему, управляющий орган 👉 должен обладать достаточным набором состояний, сопоставимым с числом возможных состояний управляемой системы. Иными словами, если внешняя среда или объект, которым мы управляем, может вести себя множеством способов, то и управляющий механизм должен быть способен реагировать столь же разнообразно, иначе он будет неэффективен. Закон этот применим во многих сферах - в управлении организацией, в биологии и, конечно же, в ИТ и ИБ 🛡
Например, согласно этому закону если атакующий может использовать сотни векторов атак, а защитник строит оборону только от трех-четырех сценариев, то защита будет слабой и неэффективной 🔓 Чтобы быть адекватным угрозам, защита должна обладать сопоставимым "разнообразием" средств: мониторинг, сегментация, резервирование, сценарное моделирование, автоматизация, обучение пользователей, патч-менеджмент, предотвращение угроз, харденинг и т.п. (изучайте, мать его, проекты MITRE - ATT&CK, D3FEND, SHIELD и иже с ними – они как раз для этого и существуют) То есть наличие широкого спектра защитных мер и средств – это не блажь, а требование закона, по которому существует Вселенная 🤹
Отсюда вроде как возникает очевидная проблема – система управления ИБ должна быть не менее сложной, чем множество управляемых ею сущностей 🧘♀️ Но мы же все хотим простоты, которая подразумевает, что система управления ИБ будет максимально унифицированной, автоматизированной, работать по нажатию "одной кнопкой". То есть набор возможных реакций должен быть предельно ограничен, что вступает в конфликт с законом Эшби. Но в реальности все немного иначе 😂
Система может казаться простой снаружи ("одна кнопка", "обнаружить и остановить", автономный SOC), но внутри нее работает множество правил, алгоритмов и сценариев реагирования 🎮 Пользователь видит простое управление, а "разнообразие" скрыто в алгоритмах. Также, не обязательно, чтобы "одна система" содержала все разнообразие. Можно распределить его между слоями: часть ответственности – у продукта ИБ, часть – у SOC, часть – у облачного сервиса. В итоге совокупность экосистемы покрывает разнообразие угроз 🤕
Невозможно создать реально эффективную "одну кнопку" 🔲, которая бы решала все вопросы ИБ. Но можно создать интерфейс одной кнопки, за которым скрывается "оркестр" механизмов, соответствующих закону необходимого разнообразия. Без тех же SIEM/SOAR/мета-продуктов/whatever оператор не смог бы эффективно управлять всем разнообразием: слишком много средств, слишком много сигналов тревоги, слишком много возможных вариантов реагирования – блокировать, детектировать, предупреждать, помещать в карантин, шифровать, изолировать, уведомлять, патчить, контратаковать и т.п. 🚫 Человек бы "тонул" в событиях. SIEM и SOAR – это как раз инструменты реализации закона необходимого разнообразия на практике. Они делают так, чтобы у организации был достаточный набор реакций на угрозы, но при этом оператор не утонул в сложности 🤔
Так что в следующий раз, когда пойдете за защитой бюджета на SIEM 🧬 или SOAR 🚘, ссылайтесь на доказанный математический закон! Вдруг сработает?!
#наука
В Дэчжоне (Южная Корея) 🇰🇷 пару дней назад произошел масштабный пожар в Национальной службе информационных ресурсов (NIRS) – ключевом государственном дата-центре, который представляет собой некий аналог наших Госуслуг. Возгорание началось при перемещении литий-ионных батарей источников бесперебойного питания (UPS): одна из них вспыхнула (в итоге нахрен сгорели все 384 батареи), огонь быстро охватил соседние модули, температура в серверных поднялась до 160 °C 🔥
Масштаб ущерба по первоначальными прикидкам нехилый: 💥
➖ Пострадало 647 государственных информационных систем.
➖ 96 из них – "Grade 1", то есть ключевые, от функционирования которых зависят критически важные сервисы, среди которых налоговые системы, государственные порталы, сервисы идентификации граждан, системы статистики и закупок.
➖ На момент публикации восстановлено лишь ~11% сервисов, работу части систем перенесли в другие центры.
➖ Восстановление может занять до 1 месяца (по предварительным оценкам).
Правительство Южной Кореи признало, что планы аварийного восстановления были недостаточными 🖕, а концентрация столь важных сервисов в одном ЦОД создала "единую точку отказа". Очередной президент (после череды импичментов и посадок местных главнокомандующих я уже потерялся в их именах; то ли дело в стабильных экономиках типа Северной Кореи или России) заявил, что он шокирован произошедшим и не ожидал, что страна, претендующая на лидерство в сфере высоких технологий так накосячит, доведя ситуацию до недопустимой (так и сказал) 🤬
Меня в этом кейсе интересует ситуация с кибербезопасностью 🛡 Деталей немного, но вот что удалось найти в разных источниках:
➖ Национальная разведка повысила уровень киберугроз: в условиях хаоса злоумышленники могут воспользоваться уязвимостями во временных или обходных схемах восстановления. Это скорее косвенный признак затронутости контуров ИБ, имеющихся в сгоревшем ЦОДе.
➖ Власти заявили, что "99% ключевого оборудования безопасности" уже восстановлено, но конкретные ИБ-системы не названы и что относится к ключевым не очень понятно 🤷♀️
➖ Эксперты, комментирующие инцидент, отмечают, что подобные инциденты иллюстрируют неотделимость кибербезопасности от физической инфраструктуры – пожар или сбой питания могут привести к коллапсу цифровых сервисов, открытым "окнам реализации угроз" и увеличившейся площади атаки ☺️
Длившийся 22 часа пожар в NIRS стал не только технологической, но и ИБшной катастрофой: миллионы граждан временно остались без онлайн-госуслуг, а государству пришлось срочно усиливать защиту и пересматривать планы резервирования и отказоустойчивости 🍑 Ну а мы все получили очередной очевидный урок – распределенная архитектура и реальные планы disaster recovery должны быть обязательными, иначе один инцидент может парализовать целую страну 🌎
#инцидент #недопустимое #непрерывность #киберустойчивость
ФСТЭК 🗂 выпустила методику проведения пентестов, которая применяется в ходе аттестации информационных систем, контроля защищенности и оценки соответствия требования по ИБ и достаточности принимаемых мер по защите. Сам документ ДСПшный и поэтому рассказывать о нем я не буду, но сам факт движения регулятора в сторону практической оценки реального состояния ИБ не может не радовать.
Однако, чтобы не ограничиваться одним лишь только информационным фактом выхода документа, который вы не можете скачать с сайта регулятора, а можете только запросить его в своем территориальном управлении, решил, что было бы неплохо дать список национальных и наднациональных регуляторов / агентств, которые публиковали официальные методики, рекомендации или требования по проведению пентестов, чтобы можно было быстро сравнить с новым документом ФСТЭК, когда он попадет к вам в руки.
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) сильнее фокусируются на тестировании киберустойчивости и интеграции пентестов в программу непрерывного контроля и стресс-тестирования (кибериспытания).
#регулирование #пентест #оценказащищенности
Интересно девки пляшут 🤦♂️ Сначала разработали требования по защите персональных данных и сделали их обязательными. Потом решили, что этого мало, и надо ввести еще и штрафы за инциденты с ПДн; причем независимо от того, как ты их защищаешь. Ну внедряешь ты риск-ориентированный надзор, ну ты хоть прочитай, что это такое. Тут либо обязательные требования и штраф за нарушение требований, либо никакой обязаловки, но штраф за нанесение ущерба субъектам. Но зачем объединять две сущности? Это пошло еще с Банка России с его требованиями по ИБ и по рискам ИБ (ну и по операционной надежности до кучи), но потом плавно перешло и на тему персональных данных. Ну вот и успокоились бы на этом, но нет 🙅♂️
Теперь Всероссийский союз страховщиков (ВСС) решил присосаться к этой титьке и тоже подоить операторов ПДн. Но как это сделать? За средства и сервисы защиты бабки стригут вендора и интеграторы 🤑 Штрафы берет себе государство. А как еще остричь эту полуголую овечку? Давайте заставим операторов страховать риски утечки ПДн и пусть это будет обязательной мерой, решили в ВСС 😮 И ладно бы с этой инициативой выступил какой-нибудь Роспотребнадзор, который защищает права потребителей. Так нет же. ВСС защищает интересы страховых компаний и выступает с законодательными инициативами от их имени. То есть желание внедрить обязательное страхование ответственности за утечки личной информации – никак не влияет на защиту прав граждан – это всего лишь способ заработать бабла для страховых 🫢
Ладно, с арифметикой у ВСС не очень (вот я считал и тут); хотя считать они должны уметь 🧮 Но хотя бы подумать о том, что задача защиты прав субъектов ПДн заключается в первую очередь в предотвращении утечки ПДн, а не вероятной компенсации ничтожной суммы денег, они могли бы? Или думать у нас уже не в моде, когда на горизонте триллионы рублей маячат 🤑
#регулирование #ущерб #персональныеданные #киберстрахование
Пишут тут, что некто взломал внутреннюю систему управления учетными записями пользователей в X (бывший Twitter) 📱 Вектор не понятен, но хакер дал понять, что это как-то связано с LinkedIn (может письмо от лже-HR с фейковым тестовым заданием?) 🔓
#инцидент
Вернулся с Underconf 2, прекрасной ламповой ИБ-конференции. Окунулся в атмосферу мероприятий 90-х, без огромных бюджетов, без засилья спонсоров, создаваемые на энтузиазме. И с массой положительных эмоций 🙂
И вот, что я подумал 🤔 Все мероприятия по ИБ, которые мне доводится посещать, можно условно разделить на 4 типа:
1️⃣ Бесплатно для участников, засилье спонсоров, рекламные доклады, генеральские пленарки и вот это вот все. Полезного контента около нуля (исключения только подтверждают правило). Идти имеет смысл ради нетворкинга (шатанов на таких тусовках тоже масса и они вполне гармонично вписываются в атмосферу).
2️⃣ Вендорские семинары и конфы. Ну тут, вроде, все и так понятно.
3️⃣ Платные для участников (перелет и проживание за деньги или «представителям ИБ-компаний за 35000 рублей» не в счет). Тут обычно качественный контент, но мероприятия вообще не массовые. Спонсоры тут редки и нужны только для поддержания базового или среднего уровня организации (а не оплаты участия «генералов»). Рекламы около нуля. И контент, и нетворкинг на уровне.
4️⃣ «Митапы». Обычно проводятся одной компанией или при ее поддержке. Очень душевно, мало людей, на энтузиазме обычно одного человека, который хочет сделать хорошо. И контент, и нетворкинг недурны.
В последнее время все больше хочется именно третьих или четвертых, чтобы была ощутимая польза, а не вот это вот все 🙄 Но у нас такое, к сожалению, огромная редкость. Тем приятнее было в воскресный день посетить Underconf 2, начавшийся с 8.30 утра 😨, который, я надеюсь, продолжит существовать и дальше. Енот, спасибо за приглашение!!! 🤝
Ну а мы готовимся уже к PHDays, в котором пытаемся вобрать лучшее от всех форматов, но без ламповости; при таких масштабах это прям невыполнимая задача; как мне кажется.
ЗЫ. А часть докладов я бы даже пересмотрел 👀 Может в канале выложат ссылки.
#мероприятие
Перефразируя thegrugq и адаптируя к русскому языку:
Модель основных способов получения учетных записей для взлома 🔤🔤🔤🔤, которая расшифровывается как:
🔤одобрать: подбор паролей (brute force), их угадывание
🔤красть: кража паролдей с помощью вредоносного ПО, перехват паролей в каналах связи
🔤просить: социальный инжиниринг
🔤упить: логи стилеров и брокеры первоначального доступа (IAB).
#аутентификация #ttp
Подписчик, за что ему спасибо, прислал осенне-бюджетное...
#юмор
Издана моя книгу "Опасная профессия. Будни работы в сфере информационных технологий". Издана полностью за свой счет. Книга адресована широкому кругу читателей. В первой части вы найдете примеры жизненных ситуаций, приведших к возбуждению уголовных дел по компьютерным преступлениям. Во второй части рассмотрены примеры участия гражданина в следственных действиях (свидетель, потерпевший, понятой, обвиняемый и т.д.). Описаны следственные мероприятия и меры пресечения. В третьей части — примеры уголовного наказания за компьютерным преступлениям.
Бесплатная электронная версия на сайте издательства https://ridero.ru/books/opasnaya_professiya_1/#reviews
P.S. Канал как и ранее закрыт для новых публикаций.
Почему-то многие индустрии в какой-то момент времени начинают походить на чиновников и представителей государственных органов, которые начинают меряться "у кого больше" 📈 вместо того, чтобы оценивать "у кого эффективнее" или "у кого оптимальнее".
Одна компания заявляет, что на нее совершается кибератак больше, чем на Госуслуги. Другой регулятор хвалится, что в первом полугодии одного года утечек персональных данных уже больше, чем за весь предыдущий год. Вендор системы обнаружения атак утверждает, что он добавил еще стопиццот сигнатур атак в свой продукт, а производитель SIEM бравирует ростом на 146% числа корреляций 📈
И только заказчики хотят, чтобы у них было меньше - меньше атак, меньше уязвимостей, меньше утечек, меньше сработок SIEM, меньше инцидентов... 📉 И чтобы стоило это все меньше. Но цены тоже растут - на бензин, на кофе, на услуги хакерских группировок, на инструменты взлома, на средства ИБ... Так и живем в условиях разнонаправленного движения – одним нужно больше, другим меньше. И конца и края этому не видно... 🔫
#метрики
Ну как так-то? К монитору приклеен стикер с легко угадываемым логином и ооооочень сложным паролем. При этом видно окошко про подключение к удаленному рабочему столу 📱 И все это перед глазами любого посетителя. Вот даже и не знаю, жалко мне будет эту организацию, когда их взломают, или нет?.. 😔
#аутентификация
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 и факс.
Если оператор использует сторонних поставщиков (например, услуги по эксплуатации, безопасности, обслуживанию), то оператор обязан предусмотреть в контрактах с ними обязанность своевременного сообщения о инцидентах и координации в расследовании. Эта мера направлена на то, чтобы цепочка реагирования была непрерывной, и оператор мог выполнить свои обязательства даже если часть инфраструктуры обслуживают третьи лица.
Если оператор задерживает, скрывает или лжет в уведомлении об инциденте – на него могут быть наложены штрафы; и ответственность могут нести не только юридическое лицо, но и конкретные ответственные лица. Однако если оператор смог доказать, что он применил "разумные и необходимые меры ИБ", своевременно уведомил органы и уменьшил вред – он может быть освобожден от ответственности или получить более мягкую санкцию 🐲
#регулирование #управлениеинцидентами