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

Достаточно часто возникающая проблема при подключении к облачным SIEMам или внешним SOCам, передаче логов вендорам для траблшутинга или просто анализа, – как не отправить чувствительную информацию, к которой относятся секреты, сессионные куки, платежная информация, персональные данные, IP/MAC/DNS-адреса, имена хостов и FQDN, имена и e-mail пользователей, геолокация и т.п. И вот коллеги из SOC Prime выложили санитайзер, не привязанный ни к какому специфическому продукту или фреймворку. Реализованный в виде библиотеки, санитайзер запускается в обычном браузере и позволяет удалить конфиденциальные данные перед отправкой третьим лицам. Можно развернуть в изолированной среде, включая и air-gap сегменты. Можно создавать свои собственные правила и шаблоны для очистки (например, идентификаторы тикетов внутреннего SOC). Так что, если вам предлагают подключиться к ИБшному озеру данных внешнего поставщика услуг, но вы опасаетесь передавать туда чувствительную информацию, данная библиотека может вам помочь соблюсти внутренние политики и получить преимущества внешнего анализа, в том числе и с помощью ИИ 🧹 #soc #автоматизация

АНБ выпустило достаточно неплохой документ с базовыми рекомендациями по кибергигиене для компаний. Несмотря на всякие APT и ИИ, достаточно соблюдать простые меры защиты, чтобы сильно усложнить жизнь хакерам. При это АНБ разделилр все свои рекомендации на 4 уровня (от Tier 0 до Tier 3), рекомендуя начать с основ (нулевой уровень), в который включены следующие меры: 6️⃣ Инвентаризация сетевых активов 2️⃣ Защитить привилегированные учетные записи 3️⃣ Сегментировать сети 4️⃣ Внедрить защиту уровня приложений 5️⃣ Автоматически патчить системы и управлять их конфигурациями 6️⃣ Многофакторная аутентификация 7️⃣ Внедрить SIEM и завести на нее логи 8️⃣ Отслеживать и блокировать ненужные сетевые соединения между сегментами 9️⃣ Контролировать аномалии на сетевом уровне и в активности пользователей 6️⃣1️⃣ Оптимизировать EDR для обнаружения аномалий и интегрировать его в поиск угроз (hunting) 6️⃣6️⃣ Ввести белый список приложений 6️⃣2️⃣ Реализовать процессы реагирования на инциденты и наладить контакты с компаниями, которые могут помочь провести расследование. Нехилый такой список гигиенических мер защиты (для Tier 1-3 там совсем немного добавлено нового). Существенно отличается от того же списка австралийских мер защиты, который включает обновление ПО и приложений, многофакторную аутентификацию и защиту макросов MS Office. Но, как написано в преамбуле к документу, этот список базируется на результатах расследований множества инцидентов и выявления слабых мест в защите пострадавших компаний. Так что имеет смысл прислушаться – АНБ плохого не посоветует 🇺🇸 #bestpractice

Одна проукраинская группировка заявила о том, что им в руки попали чувствительные данные компании Metascan, отечественного ИБ-разработчика, – не только внутренние документы, персональные данные и переписка сотрудников, но и, что самое неприятное, исходники продуктов Metascan, планы их развития, а также результаты сканирования заказчиков с полным описанием найденных уязвимостей, включая и критические. Среди упоминаемых клиентов – ВТБ, Сбер, Ростелеком, Норникель, Лукойл, Лента, Вайлдберриз, Селектел и т.д. Metascan уже прокомментировал произошедшее и по их версии никакого взлома не было. Речь идет не о компрометации внешними хакерами, а действии инсайдера. Непрошедший испытательный срок и уже уволенный сотрудник, имевший доступ к части исходных кодов, а также иной выложенной в специально созданном Telegram-канале информации, пытался шантажировать работодателя, но эта попытка закончилась неуспешно, после чего уволенный сотрудник все слил злоумышленникам. По заявлению Metascan, доступа к отчетам об анализе защищенности нарушитель не имел, а то, что было выложено, – результат безалаберности сотрудников, которые обменивались такими документами в рабочих чатах, к которым имели доступ все. Пока это все, что есть про данный кейс. Одни заявляют: "мы теперь воспользуемся сведениями об уязвимостях, чтобы взломать этих клиентов", другие – "ничего не было, просто набор случайностей и внутренних косяков". К позиции Metascan у меня есть вопросы – в глаза бросаются некоторые нестыковки в их заявлении (тем более, что хакеры в своем канале публикуют достаточно нелицеприятные детали, которые якобы имели место в утекших данных). Но компания заявила, что уже работает с правоохранительными органами. Так что стоит немного подождать, когда компания будет готова раскрыть детали проводимого расследования. А пока напомню, что год назад Metascan уже сталкивался с попыткой внедрения вредоносного кода в свой конвейер разработки со стороны нанятого джуна. И снова кейс связан с проблемой найма?.. 👨‍💻 #инцидент #проблемыибкомпаний #утечка #insider #антикризис

Из забавного. На Рыбачьем, в 25 км от норвежской границы, не работает мобильная связь. По крайней мере два моих оператора не ловили, с чем я столкнулся еще лет 10-15 назад, когда первый раз ездил в автопоход по Среднему и Рыбачьему с коллегами-ИБшниками 🐋 Сейчас ситуация изменилась мало и связи тут нет... исключая норвежских операторов, которые вполне себе ловят, если забраться на хребет Муста-Тунтури (иногда, вроде как пробивается Мегафон). Но пост не об этом. У меня не было обратного билета и я решил, что возьму билет на самолет за пару дней до вылета. Но меня ждал сюрприз, зайти в личный кабинет Аэрофлота можно только введя одноразовый код, получаемый… по СМС, который до точки моего отдыха не доходит. Интернет есть, а мобильной связи нет. Такой вот парадокс. А у Аэрофлота, что характерно, нет резервного способа входа в свою учетную запись (вариант "через Госуслуги" и "через Сбер ID" к таковым я не отношу). К чему эта зарисовка? Если вы проектируете архитектуру доступа к ресурсам, требующую аутентификации пользователей, предусмотрите резервный способ/канал (можно и не один) для этого. Самый простой вариант, неподвластный никаким Роскомнадзорам, – электронная почта. Ну или OTP, как у тех же Госуслуг. На крайний случай – мессенджер (хотя я вряд ли поставлю ради этого "мессенджер, который нельзя называть"). Да, билет я все-таки купил, но это уже другая история... А еще, я вернулся и затишье в канале завершается 🤔 #аутентификация #архитектура

По результатам обучения в НИУ ВШЭ по безопасности ИИ для руководителей пришла обратная связь от слушателей:

Оценка работы преподавателя 5 (из 5) Оценка пользы от лекции 5 (из 5) Весь материал Алексея полезный, применимый as-is, показал точки в проекте где нужно особое внимание. Топ спикер! По теме, очень полезно! И вторая: Оценка работы преподавателя 5 (из 5) Оценка пользы от лекции 5 (из 5) Это топ! Очень интересно и полезно

А я переживал, что новый контент (пример 1, 2, 3, 4 и 5) может не зайти. Ну и хорошо. Двигаемся дальше. ЗЫ. А плану «Ковер» насрать на все эти ваши ИИ. Рейс в Мурманск не просто перенесли, а совсем отменили. Полтора десятка ИБшников сначала пыталась взять прайвет-джет или вертолет, но на них тоже план «Ковер» распространяется. В итоге, едем до Питера на поезде, оттуда до Мурманска на автобусе и потом на машинах до точки назначения. А вы говорите, тяжелые на подъем… #ии #обучение

Если вернуться к 17-тилетней давности предложениям по реформированию отрасли ИБ, то в отличие от ряда других инициатив, где число предложений измерялось десятками, и учитывая адресата, в 2009-м году мы предложили всего 4 инициативы (за каждым пунктом был более детальный план действий): ➡️ Передать разработку стандартов и регламентов в области ИБ профессиональным отраслевым сообществам при сохранении государственного регулирования в формировании только базовых требований. ➡️ Создать Экспертный совет по информационной безопасности при Правительстве РФ, объединяющий признанных экспертов в области корпоративной и ведомственной информационной безопасности. ➡️ Создать национальную сеть Центров реагирования на угрозы информационной безопасности для мониторинга и защиты киберпространства России, контроля соответствия требованиям и организации сервисов по защите малого и среднего бизнеса, который не в состоянии самостоятельно обеспечить адекватный уровень информационной безопасности ➡️ Развитие Программы осведомленности в вопросах информационной безопасности для всех участников киберпространства России. В проекте были также идеи убрать госрегулирование отовсюду кроме гостайны, стимулировать развитие и приобретение перспективных технологий, определить требования к базовому уровню ИБ, но от них в итоге отказались, так как первым лицам государства предлагать неконкретные требования было неправильно. Как видно, ни один из пунктов так и не был реализован. Так и живем... #регулирование #история

Я обычно не пишу про продукты 🤟, но тут они скорее стали поводом для размышлений. Итак, Позитив сертифицировал свой антивирус в ФСТЭК и получил сертификат регулятора на EDR (первыми в России). И СМИ стали писать, что консервативный антивирусный рынок ждет встряска и передел. И вот тут у меня, конечно, пригорело немного. Такое впечатление, что до получения сертификата продукта как бы не существовало и его нельзя было использовать для обнаружения и нейтрализации вредоносной активности. Но ведь мы понимаем, что это совсем не так. Почему только получение бумажки с голограммой перестает делать продукт невидимым для рынка и пользователей? Да, понятно, что для некоторых заказчиков (очень небольшого числа) есть требования государства – применять только сертифицированные решения. Но для других-то таких требований нет. Почему у всех в головах ставится знак равенства между "есть сертификат" и "продукт может реально защищать"? Это же бред. Другой вчерашний пример. У нас создается прототип новой технологии на базе ИИ для поиска уязвимостей в исходном коде ПО. У нее еще нет названия – это пока бета-версия. И вот в процессе ее тестирования мы выявили критичную уязвимость (CVSS 10.0) в проекте Prompty от Microsoft. Бета-версия продукта без сертификата нашла крит в ПО. Наличие или отсутствие сертификата что-то изменило бы? Нет. Качество продукта не определяется бумагой с голограммой. Но мы по-прежнему ждем, когда некий продукт получит этот сертификат, а без него опасаемся применять решение ИБ. Мы стали заложником этой неверной парадигмы, которая родилась в иных условиях и для иных задач, но которая сейчас только расширяется на все сферы ИБ. Мы боимся не угроз со стороны хакеров или реализации недопустимых событий. Мы гораздо больше боимся отсутствия официальной бумаги и претензий со стороны регулятора. Та же история с оценкой защищенности – вместо проведения кибериспытаний, эмулирующих реальные действия хакеров, мы молимся на аттестат, так как он выдается аккредитованной организацией-лицензиатом. Есть бумажка? Мы чисты перед... регулятором. И кому какое дело, что хакер будет ломать совсем не так, как написано в методике, которая обновляется гораздо реже, чем даже та же MIRE ATT&CK. Та же история с подтверждением квалификации компетенций по ИБ и с другими темами... Откуда у нас такое идолопоклонение перед бумагой? Ладно, хоть кто-нибудь отвечал за то, что написано в сертификате/дипломе/лицензии/аттестате, ну так нет же. Если вас взломают через сертифицированный продукт, испытательная лаборатория и орган по сертификации не несут за это никакой ответственности. Если вы получили диплом о высшем образовании в ИБ даже не понимая отличия между аутентификацией и авторизацией, то к ВУЗе нельзя предъявить претензии. И список можно продолжать... ЗЫ. За коллег из команды Endpoint Security я могу только порадоваться – и бумага есть, и продукт хороший. Но что делать другим вендорам, которые не обладают ресурсами для сертификации своих решений и тем самым теряют российского потребителя?.. Вопрос риторический. #рефлексия #оценказащищенности

Не успел вернуться с Хибин, как снова собираюсь в дорогу; в этот раз на Баренцево море 🌊 И стоя перед горой снаряги и пустым рюкзаком, вдруг подумалось, что нам не хватает в ИБ концепции "киберрюкзака". Ведь собираясь в путешествие, ты сначала набиваешь рюкзак барахлом, половина которого тебе не понадобится. Но если у тебя большой рюкзак (как мой на 120 литров), ты его набиваешь и тащишь, мучаясь на подъемах и спусках. И в следующий раз ты начинаешь освобождаться от лишнего, оптимизировать список необходимого, снижать вес снаряги и т.п. И в ИБ мы тоже покупаем дофига всего разного, что "может быть" понадобиться для защиты инфраструктуры, но не используем и половины того, что у нас есть, думая "авось, пригодится". А все это требует поддержки, обновления, закупки новых лицензий, обучения персонала и т.п. Ну или эти средства просто стоят... на шкафу и ими никто не пользуется. Но деньги-то потрачены. Может нам тоже пора учиться ходить в ИБ "налегке"? Не в смысле отказаться от защиты и оставить один NGFW на всю компанию. А периодически вытряхивать содержимое своего киберрюкзака на пол и честно спрашивать про каждую вещь: зачем мы это тащим? Какую задачу она решает? Когда мы последний раз этим пользовались? Что случится, если мы это выложим? И нет ли у нас уже трех других средств, которые делают примерно то же самое? Причем хороший походник оптимизирует не только количество вещей. Он ищет более легкую палатку, заменяет три предмета одним универсальным, отказывается от дублирования и учится лучше пользоваться тем, что уже взял. В ИБ, кажется, ровно та же история: иногда выгоднее не купить очередное средство защиты, а нормально настроить уже имеющееся, включить купленную пять лет назад, но так и не используемую функцию или научить людей пользоваться тем, за что компания уже платит. И, пожалуй, зрелость ИБ можно измерять не только тем, сколько средств защиты компания сумела купить и внедрить. А еще и тем, насколько маленький "рюкзак" она способна нести, при этом действительно защищая то, что для бизнеса важно. Потому что в горах лишние пять килограммов довольно быстро позволяют понять разницу между "может пригодиться" и "действительно нужно". Возможно, бюджет ИБ иногда должен делать то же самое. #аналогии #рефлексия

По мотивам моего выступления "Не конкурируй с ИИ – управляй им. Как специалисту по ИБ остаться востребованным в эпоху ИИ-агентов" на Standoff Talks с рассказом о применении ИИ в деятельности ИБшника, был написан материал, который мы разместили на Хабре. Приятного чтения 🤩 #статья #ии #bestpractice

3 года назад мы в 🤟 пытались придумать систему классификации автономного ИИ, взяв за основу систему классификации автопилота в автомобилях (SAE), но к единому мнению не пришли ввиду сложности задачи – мы пытались разложить сложную систему (а тогда еще даже ИИ-агентов не было) в одномерном пространстве из пяти уровней автономности. На Jet CyberCamp я вновь попытался вернуться к этой истории, предложив двумерное пространство классификации ИИ-агентов в контексте ИБ, – 6 параметров с соответствующими градациями. И вот новый подход, от Ленни Зельцера, который предлагает свою систему категоризации, но не для агента целиком, а для каждого типа его действий отдельно. Этот подход, получивший название Security Autonomy Matrix, не просто выделяет 5 уровней автономности (по аналогии с SAE), но и применяет их к пяти классам действий – читать, писать, отправлять, тратить, удалять. Уровень автономности для каждого действия ИИ-агента зависит от оценки по двум параметрам: ➡️ Blast radius – насколько далеко распространятся последствия ошибки ➡️ Reversibility – насколько быстро ошибку можно отменить относительно скорости распространения ущерба. Отсюда и основная идея матрицы – чем менее обратимо действие и чем больше его blast radius, тем сильнее должен быть человеческий контроль. Если внимательно почитать предлагаемый фреймворк, то становится очевидным, как классический совет многих рекомендаций про human-in-the-loop раскладывается на вполне понятные действия, которые могут быть реализованы через AI Policy Engine. Например, ИИ-агент занимается очисткой старых правил PT NGFW и обнаруживает правило, которое не использовалось 90 дней. Можно дать ему: ➡️ Read L4, чтобы самостоятельно анализировать правила ➡️ Write L3, чтобы самостоятельно отключить правило ➡️ Delete L2, чтобы окончательно удалить только после подтверждения инженером ИБ. Почему так? Потому что отключение обратимо (отключили → какое-то приложение сломалось → включили обратно), а удаление – это одностороннее действие. Ну а если несколько кварталов ИИ-агент безошибочно справляется со своей задачей, то Delete теоретически тоже можно повысить до L3. Дополнительно, Ленни предлагает фиксировать еще четыре вещи: ➡️ Ответственный. Кто персонально отвечает за действия агента. Не "SOC", не "команда ИИ", а конкретная роль. ➡️ Точка контроля. Где именно человек подтверждает, отменяет или откатывает действие. ➡️ Остаточный риск + защитные меры. Что все равно может пойти не так и чем мы ограничиваем ущерб. ➡️ Правила и сроки пересмотра. Когда разрешение агенту должно быть пересмотрено. В общем, интересная динамическая модель доверия ИИ-агентам, которая позволяет задавать правильный вопрос: для какого действия, при каком уровне риска, с каким blast radius, при какой обратимости и при каких доказательствах надежности нужен человек? Берем на вооружение пока не придумали еще что-нибудь 🤔 #ии #framework

🆕 Дело было вечером, делать было есть чего... Раз победить нормативку пока не получается, то взял и навайбкодил калькулятор оценки зрелости по новой методике ФСТЭК. Разместил у себя на сайте – можно оценивать свою зрелость. Вы отвечаете на вопросы, ваш текущий профиль рассчитывается по методике ФСТЭК, а целевой уровень зрелости вы задаете самостоятельно. Никакая регистрация не нужна 🆓 При этом вся методика "от и до" целиком не реализована и вот почему. Инструмент охватывает ее расчетную часть, но не полную формальную процедуру. Сейчас отсутствуют: ➡️ автоматические рекомендации целевых уровней по классу/уровню защищенности ГИС и ИСПДн или категории значимости объекта КИИ из п. 11, так как я не собираю ваш текущий класс/уровень/категорию защищенности/значимости ➡️ добавление дополнительных направлений деятельности по ИБ из п. 13, так как неизвестно, что может быть добавлено ➡️ сбор и проверка подтверждающих документов по пп. 19–26, так как это ваши конфиденциальные документы ➡️ ретроспективное сравнение нескольких оценок по п. 33, так как я ничего на сервере не храню ➡️ полноценный план мероприятий по достижению целей, так как это оооооочень сильно зависит от вашей внутрянки ➡️ формальный отчет раздела VI со сведениями об участниках, доказательствах, рекомендациях, подписанием и утверждением. Сразу отмечу важный момент: ваши ответы на сервер не попадают и нигде не сохраняются – все обрабатывается и хранится в вашем браузере. Закроете вкладку – все введенные вами данные будут утеряны. ПерезагрУзите браузер – данные тоже могут быть утеряны. Такова плата за конфиденциальность. По результатам оценки мини-отчет можно распечатать или сохранить в PDF. Пока все это эксперименты с вайбкодингом, но надеюсь, этот калькулятор https://jeopardy.lukatsky.ru/maturity/ будет полезен. В планах еще всякое поделать, поэкспериментировать с автоматизацией разных задач 🖥 ЗЫ. Если будут замечания и предложения, то пишите в комментариях ✏️ #оценказащищенности #регулирование #автоматизация

Было дело… 17 лет назад. Одна из попыток узкого круга экспертов повлиять на ситуацию с ИБ в стране. Отправляли на первых лиц свои предложения, но канули они в Лету. И до, и после их тоже еще было. И хотя «…а караван идет», оптимизма не теряю и надежду сохраняю. А иначе, зачем это все… #регулирование #история

#обучение

Есть такое правило – не класть все яйца в одну корзину, которое применимо ко многим аспектам нашей жизни – от резервирования данных до личных финансов. И вот я читаю предложение Минцифры про выделение IP-адресов белого списка в отдельные подсети, чтобы лучше бороться с наркошопами, порносайтами и VPN-сервисами. Требование просьба касается хостинг- и CDN-провайдеров, а также сервисов веб-безопасности, что по мнение министерства цифрового РАЗВИТИЯ должно помогать точнее бороться с нелегальным контентом. Я оставлю в стороне вопрос, каким макаром вообще регистрируются/создаются нелегальные ресурсы в стране, которая жестко цензурирует все, заставляет подтверждать владение доменами через ЕСИА и т.п. Тут вопрос в другом. Цифровизаторы всея Руси понимают, что таким образом они кладут все яйцы в одну корзину и дают в руки противнику прекрасный козырь – вместо того, чтобы бить по площадям, можно будет сразу сфокусировать DDoS на диапазоне "белых" адресов? Это как вместо тысяч складов маркетплейса по стране создать всего с десяток мегаскладов и позвать туда дроноводов. Или как перенести портал Госуслуг, ядро НСПК, ЕСИА/ЕБС, "ГАС Выборы" в один ЦОД и вырубить там электропитание. Или как оставить один канал соединения Рунета со всем миром, который перережут на той стороне... С точки зрения управления это, конечно же, гораздо удобнее. Но кто-нибудь оценивал риски целенаправленного удара по таким диапазонам и, самое главное, последствиям от этого? Как по мне, так сделано это не для борьбы с наркошопами или порносайтами, а потому что ТСПУ просто не справляются с нагрузкой из-за постоянно растущего списка адресов, которые надо блокировать. Я вот вчера настраивал на маршрутизаторе "ваш путь наружу" и вносил в таблицу маршрутизации адреса и диапазоны для Youtube, Telegram, видео-сервисов, новостных ресурсов, ИБ-сайтов и т.п. Для достаточно небольшого списка сервисов у меня таблица маршрутизации содержит тысячу с лишним адресов и GUI роутера ощутимо подтормаживает в процессе настройке. Что уж говорить о ТСПУ, которые явно спроектированы под совершенно иную нагрузку и условия функционирования. Отсюда и запрос Минцифры. Будем посмотреть, чем это все закончится. Следующий шаг после реализации ПРОСЬБЫ министерства – оставить доступными только ресурсы из белого списка, а все остальное тупо заблокировать. Нет ресурсов – нет проблем; и ТСПУ не тормозят. Бинго! Но... есть и положительный момент во всей этой истории. Если оно заработает, то потом эту технологию и устройства можно будет задорого продавать в дружественные страны, с чего и начнется наш путь уже не импортозамещения, а экспортопригодности российских ИТ и ИБ, о которых в 22-23-м годах говорил министр! А это можно только приветствовать! Главное, дожить! 💪 #суверенитет #интернет

Интересная статья от практикующего исследователя уязвимостей, который делится своим ощущением от использования LLM, которая превращает человека из искателя в триажера. Автор пишет не о том, что LLM повышает производительность и число найденных дыр, сколько о том, что из работы исчезает прежнее ощущение "я сам это нашел" и ранее получаемый дофамин от обнаруженного уже не поступает. Для большинства не слишком больших и сложных проектов, по наблюдению автора, фундаментальная модель плюс правильно поставленные вопросы позволяют провести значительную часть code review в диалоге с LLM. Иногда исследователь вообще не читает код подробно: получает от модели PoC, проверяет его и убеждается, что уязвимость действительно существует и модель не "схитрила". И возникает парадокс: критических уязвимостей исследователь находит больше, чем раньше, а удовольствия от работы получает меньше! Дальше автор задается логичным вопросом – а почему бы не отказаться от LLM, раз она не дарит удовольствие от работы. Ведь шахматисты продолжают играть в шахматы, хотя компьютер давно играет лучше человека. И сам же отвечает – люди ездят верхом для удовольствия, но почти никто не ездит на лошади на работу. Это в искусстве, играх и хобби ценность заключается в самом процессе, выполняемом человеком (я вот люблю писать, не доверяя этот процесс ИИ, хотя могу). В исследованиях уязвимостей конечному результату все равно, кто нашел дыру – человек или машина. Если задача – первым найти 0-day, романтика ручного поиска становится конкурентным недостатком. Но автор не впадает в отчаяние и прогнозирует появление двух новых ролей в области исследования уязвимостей... о которых вы можете прочитать в оригинальной статье (а то, что это я за вас все пересказываю 🤠). А дальше вам предлагается ответить на "простой" вопрос: "Какие проблемы являются самыми важными в вашей области – и почему вы над ними не работаете?" И здесь LLM неожиданно оказываются не угрозой профессии, как иногда это преподносится, а способом освободить человека от большого объема рутинной работы. И можно переживать факт отъема любимой работы. А можно спросить, что теперь стало возможным вам делать нового, потому что прежнюю работу делает машина? ЗЫ. Прикольный момент. Перед началом написания статьи автор попросил Codex поискать в фоне критические уязвимости в очередном проекте. И в середине текста ИИ-агент отчитался о том, что нашел очередной крит. В конце автор пишет, что, дописав статью, он проверил крит и тот и правда подтвердился... 🤷‍♂️ #рефлексия #оценказащищенности #ии

Был у меня опыт хождения в одиночные походы. И хотя я только вернулся с Хибин, сразу скажу, что пост будет не про "найти и проверить себя", а про кибербез, как и все в этом канале. Когда ты один на один с природой, со стихией, то ты ведешь себя немного иначе, чем в группе. Во-первых, твои движения и действия гораздо более взвешенные и осмысленные. Ты не будешь орать, увидев медведя в уральской тайге, и не будешь бежать по курумнику к базовому лагерю в конце дня, не будешь штурмовать перевал или взбираться на хребет за 2 часа до наступления темноты в расчете на "авось успею спуститься". Ты можешь рассчитывать только на себя, а не "того парня". И в кибербезе, ИБшники, которые в одиночку защищают свои компании, обладают, как мне кажется, куда большей ценностью, чем члены больших ИБ-команд, где у каждого своя роль, свой круг задач, свой инструментарий, своя ответственность... и своя зашоренность. У одиночки-ибшника "все в одном" – он и жнец, и швец, и на дуде игрец. Переходя на работу в крупные команды, он может привнести очень многое, так как имеет не только широкий кругозор и насмотренность, но и умеет достигать результата меньшими затратами (хотя и большими личными усилиями). Только представьте, что идя в группе, можно распределить кучу снаряги между всеми участниками, а в одиночку ты тащишь все на себе и поэтому более грамотно подходишь к выбору снаряжения. Кстати, о снаряжении. Когда я начинал ходить в походы (так и хочется добавить "в прошлом веке", что будет истинной правдой), в продаже не было нормальной снаряги и почти все приходилось делать своими силами. Я таким образом научился шить и до сих пор иногда пользуюсь рюкзаком и анораком, которые сделал своими руками. Да, возможно этот самопал был не столь красив, как современные бренды, но свои задачи он решал прекрасно. А сейчас ты можешь пойти в Кант, АльпИндустрию, Спорт-Марафон или даже Спортмастер и купить себе все, что душа пожелает, а кошелек потянет… и достичь того же результата, что и самодельное снаряжение. К чему это я? К тому, что в ИБ у нас ведь тоже самое – есть дорогостоящие бренды, есть решения второго эшелона для тех, кто "победнее", и есть open source и самописное ПО. И их результативность часто определяется не ценой, а руками, в которые они попали. С вайбкодингом сегодня стало проще и можно автоматизировать простые задачи без заказной разработки и покупки решений по прайс-листу. Да, выглядит оно может быть некузяво, вряд ли портируемо в другую инфраструктуру, но это и не надо. Это к разговору о том, что многое решает не инструментарий, а навыки людей, их опыт и результаты учений (участия в соревнованиях и походах выходного дня). Хотя и фактор неожиданности сбрасывать со счетов нельзя – достаточно вспомнить "Перевал Дятлова", "Вертикальный предел", "Вертикаль" и другие фильмы, снятые с разницей в 50 лет, но показывающие одно и тоже - можно иметь миллиарды, но не выжить в инциденте. В общем, качайте навыки, а не только гоняйтесь за инвентарем изучайте современные средства защиты. С отработанными навыками вы сможете работать с любыми средствами ИБ. А вот без навыков, никакое средство вам не поможет (особенно если оно откажет в самый неподходящий момент) или полностью вас заменит (привет, ИИ). Такие вот мысли возникли, когда я готовился к очередному потоку курса про SOC 2.0 (некоторая часть контента там будет и моего авторства), который у нас вот-вот начнется. Мы его проектировали как раз больше про то КАК и ЗАЧЕМ, а не с помощью ЧЕГО 🏜 Да, кстати. Если уж упомянул тему SOC, то playbook'и в одиночном и групповом походе тоже разные, как и в ИБ-жизни. Поэтому бессмысленно копировать чужие руководства – нужно писать свои, исходя из имеющегося количества людей, инструментов, инфраструктуры и других параметров, включая и опыт. ЗЫ. Весь этот сумбур - сугубо мое имхо, навеянное походом в горы. #аналогии #soc #обучение

Представим гипотетическую ситуацию. Апрель 2026 года, некий украинский пранкер проникает на закрытое онлайн-совещание одного российского министерства, на котором обсуждаются вопросы импортозамещения микроэлектроники и запчастей при изготовлении дронов. Запись ВКС выкладывается публично и по ней можно сделать выводы об участниках, их ФИО и должностях. Август 2026, тот же пранкер вновь проникает на секретную ВКС того же ведомства и вновь не только записывает обсуждение ситуации с дроностроением и необходимость рисовать фейковые отчеты для руководства страны, но и выкладывает эту запись в Интернет. Это, конечно же, никакой не реальный случай (как вы вообще могли такое подумать) – это просто такой сценарий для штабных киберучений 🤠 Налицо утечка… не знаю насчет секретных сведений, но персданных вероятно да. Ведь, как мы помним из ФЗ-152 и разъяснений РКН (в том числе и на последнем Дне открытых дверей), ПДн - это ЛЮБЫЕ сведения о субъекте, в том числе сюда попадает и факт участия в совещании. То есть имеет место повторное разглашение охраняемых законом сведений. Внимание вопрос. Должен ли РКН инициировать процессуальные действия по ч.16 и 18 ст.13.11 (оборотный штраф при повторной утечке информации)? Ответ: нет, не должен, так как утекло данных менее 1000 субъектов. Но если бы инцидент был признан, то попал бы он в статистику РКН? А кто же тогда должен проводить расследование повторного гипотетического, конечно же, взлома российского министерства, произошедшего спустя 4 месяца после предыдущего инцидента ИБ на том же объекте КИИ? И что за ВКС использовалась гипотетическим российским министерством? Не TrueConf ли, о критических уязвимостях в котором на днях даже сообщала “американская ФСТЭК” CISA, а не только НКЦКИ? 🤔 ЗЫ. Вообще занятно, что американская госуха использует отечественное ПО для ВКС 😂 #персональныеданные #утечка #ответственность #инцидент

Ну что, дам правильный ответ на предыдущий опрос. Это 21-й порт! Большинство ответивших про 23-й порт право с точки зрения теории, которая гласит, что согласно RFC 854 за Telnet действительно закреплен 23-й порт, но... Вопрос звучал немного иначе, а именно, через какой порт проходит больше всего трафика Telnet в реальном Интернет. И тут стоит вспомнить RFC 959 на протокол FTP, который говорит нам, что управляющее соединение FTP следует протоколу Telnet. И обмен каждой командой FTP идет по правилам NVT, который является частью протокола Telnet. Именно поэтому больше всего Telnet-трафика (именно трафика) идет через 21-й порт. Если бы Telnet, как средство удаленного доступа, был популярен, то, возможно, ответ был бы иным, но увы, от чистого Telnet многие уже давно отказались, заменив его на SSH (22 порт). А так как FTP сегодня все еще популярен при работе с хостингом (не все используют SFTP внутри SSH), то ответ будет именно 21, а не 23. Кто дал самый популярный ответ - 80-й порт, также сделали классическую ошибку из области когнитивных искажений. Действительно, telnet на 80-й порт часто используется для проверки доступности веб-сервера, но проверка эта идет не по протоколу Telnet (то есть Telnet-трафик там не передается), а по обычному TCP, а Telnet используется именно как утилита для проверки соединения, не более. Этот опрос и ответы на него очень хорошо иллюстрируют отличия двух понятий – "знание" и "мышление". В первом случае мы просто извлекаем из памяти то, что учили на курсах по сетевым технологиям (Telnet – значит 23-й порт). Во-втором – мы начинаем не быстро кликать на нужный чекбокс опроса, а размышлять, что в итоге и приводит нас к правильному ответу. Первое – признак джуна (или менеджера с техническим бэкграундом), второе отличает мидла и синьора. Если честно, то когда я увидел этот вопрос в Интернете, мое первое желание тоже было ответить 23. Потом я одернул руку и включил уже процесс размышлений и поисков. Я не помнил на память ни номера RFC (я даже их текущее число не знаю), ни спецификацию на FTP, но, как говорится, Гугл (а кому-то и ChatGPT) в помощь. Такой и аналогичные вопросы полезно задавать аналитикам SOC, чтобы проверять их способность не тупо писать правила "по учебнику" и разбирать события "как учили на курсах по SIEM", а действительно задавать самому себе вопрос: "А не херню ли я творю все правильно ли я делаю?" и "Не упускаю ли я что-то важное?" 🤔 #soc #обучение #психология