Приказ № 239 / Главная ошибка — это требование: «всё ПО должно быть сертифицировано ФСТЭК» Это неверно. Приказ №239 требует реализовать меры защиты, а не использовать исключительно сертифицированные продукты. Сертификация нужна, только если ПО = средство защиты информации (СЗИ) Точно нужно сертифицировать: межсетевые экраны (МЭ) антивирус / EDR IDS/IPS СЗИ от НСД (доступ, аутентификация) СКЗИ (VPN, шифрование) Не требует сертификации: backup (резервное копирование) SIEM (в большинстве случаев) мониторинг (Zabbix и др.) сканеры уязвимостей Это не СЗИ, а эксплуатация и анализ Пограничные случаи: IAM / PAM DLP NAC Зависит от роли: если реально ограничивают/защищают → может потребоваться сертификация Главный принцип: Не “что за продукт”, а “выполняет ли он функцию защиты” Почему требуют «всё сертифицированное»: страх проверок лень обосновывать архитектуру перестраховка закупок Итог: Сертифицируются СЗИ Не всё ПО на КИИ Backup ≠ СЗИ → сертификация не обязательна #РазборНПА
АНО ДПО "Международная академия современного образования"
Нет
подписчиков
Мы лицензированное образовательное учреждение в сфере информационной безопасности. АНО ДПО "МАСО" работает с 1998 года и специализируется на многопрофильном обучении в сферах дополнительного профессионального образования, повышения квалификации и профессиональной переподготовки.
Кто такой аналитик DLP: чем он занимается, какая база нужна и сколько можно зарабатывать
Аналитик DLP — одна из тех ролей в информационной безопасности, о которой часто судят слишком упрощенно. Со стороны может показаться, что это специалист, который просто просматривает сработки системы и проверяет, кто, куда и что отправил. Но на практике все сложнее и интереснее.
Сегодня аналитик DLP — это специалист на стыке мониторинга, расследования инцидентов, настройки политик безопасности и внутреннего консалтинга для бизнеса. Он помогает компании не просто реагировать на возможные утечки,...
В России представлен проект федерального закона об искусственном интеллекте Правительство РФ внесло масштабный законопроект, который определяет правила разработки, внедрения и использования технологий ИИ в стране Ключевые моменты: Установлены базовые понятия: ИИ, модели, системы, данные Вводится риск-ориентированный подход к регулированию Делается акцент на технологическом суверенитете и национальных моделях Появится реестр «доверенных» моделей ИИ для госиспользования Закрепляются права граждан (информирование, отказ от ИИ, обжалование решений) Устанавливаются обязанности разработчиков, операторов и пользователей Вводится маркировка AI-контента (борьба с дипфейками) Определяется ответственность за вред от использования ИИ Особое внимание уделено безопасности, этике и защите данных 🌍 Также документ затрагивает международное сотрудничество и экспорт российских ИИ-технологий В случае принятия закон вступит в силу с 1 сентября 2027 года #ИИ #закон #технологии #AI
ФСТЭК обновил форму сведений об объектах КИИ: что изменилось и как теперь заполнять документы
В 2025 году ФСТЭК России обновил форму направления сведений о результатах категорирования объектов критической информационной инфраструктуры, а затем отдельно выпустил разъяснения по её заполнению. Уже в 2026 году нормативный контекст дополнился утверждением перечня типовых отраслевых объектов КИИ распоряжением Правительства РФ № 360-р от 26 февраля 2026 года. Поэтому сегодня вопрос стоит уже не в том, “что имел в виду регулятор”, а в том, какие сведения субъектам КИИ нужно перепроверить и актуализировать прямо сейчас...
️ В конце декабря 2025 ФСБ выпустила пакет приказов по ГосСОПКА — что важно субъектам КИИ Вышли сразу несколько документов, которые «собирают в систему» взаимодействие с ГосСОПКА: как получать информацию об угрозах, как обмениваться данными об атаках/инцидентах, как уведомлять, и какими должны быть средства обнаружения/реагирования. Приказ №539 — описывает, как субъектам КИИ получать информацию о средствах/способах атак и методах их предупреждения/обнаружения (в т.ч. через инфраструктуру НКЦКИ и ресурсы cert.gov.ru). Приказ №546 — новый порядок обмена информацией о компьютерных атаках и инцидентах (внутри РФ и по отдельным сценариям — с зарубежными организациями реагирования). Приказ №547 — новый порядок информирования ФСБ о компьютерных атаках/инцидентах + требования к реагированию и ликвидации последствий (в т.ч. через НКЦКИ/форматы ГосСОПКА). Приказ №548 — закрепляет непрерывное взаимодействие с ГосСОПКА (получение предупреждений/индикаторов и обратная связь о принятых мерах, «личный кабинет» и регламент взаимодействия). Приказ №553 — порядок и технические условия установки/эксплуатации средств, предназначенных для обнаружения/предупреждения/реагирования (в т.ч. средств поиска признаков атак; кроме телеком-сетей, где отдельная специфика). Приказ №554 — требования к средствам обнаружения/реагирования и к средствам поиска признаков атак (функциональные требования к возможностям таких средств). Что сделать на практике (быстрый чек для ИБ/ИТ): обновить внутренние регламенты взаимодействия с НКЦКИ/ГосСОПКА (каналы, роли, сроки) актуализировать план реагирования и шаблоны уведомлений/отчётности под новые порядки проверить, что «дежурка» и ответственные знают когда/куда/в каком формате отправлять сведения провести ревизию используемых средств обнаружения/реагирования: соответствие требованиям + эксплуатация по техусловиям
Вопрос от подписчика. Добрый день! Вопрос: средство резервного копирования обязательно должно быть и сертифицировано и в реестре отечественного ПО (к примеру КИИ 3 кат)? По хорошему это не СрЗИ. А то, как то получается монополия (программное изделие «Система резервного копирования «RuBackup»). Ответ от эксперта. Короткий ответ: нет, средство резервного копирования (СРК) для КИИ 3 категории не обязано одновременно быть и сертифицированным ФСТЭК, и включённым в реестр отечественного ПО. Подробнее: Система резервного копирования (СРК) для КИИ 3 категории: не обязана быть сертифицированной ФСТЭК, т.к. это не СЗИ не обязана одновременно быть и сертифицированной, и в реестре Что реально требуется: резервное копирование как мера (обязательно) желательно/фактически требуется ПО из реестра отечественного ПО Когда нужна сертификация: если СРК выполняет функции СЗИ (шифрование, контроль доступа) или это прямо прописано в ТЗ / модели угроз Почему кажется, что “только RuBackup”: заказчики перестраховываются пишут требования: «реестр + сертификация» таких продуктов мало → создаётся эффект монополии Итог: Требование «и сертификация, и реестр» — это не обязательная норма, а чаще перестраховка закупщиков, а не прямое требование регулятора.
Очевидное и невероятное (минутка юмора) Современный рынок труда — удивительное место, где реальность давно уступила место фантазии работодателя. Вакансия сегодня — это уже не просто объявление, а целый жанр абсурдной литературы. Требуется 20-летний специалист с двумя высшими образованиями , 30-летним опытом, стрессоустойчивостью монаха и знанием 25 языков, включая мёртвые и вымышленные. Желательно, чтобы кандидат уже работал у нас последние десять лет, но при этом был «молодым и энергичным». Работа в дружном коллективе — обязательный пункт. Под «дружным» обычно понимается коллектив, где переработки считаются нормой , личные границы — слабостью , а фраза «мы же семья» служит универсальным аргументом против повышения зарплаты. Ведь в семье, как известно, за деньги не работают… Оплата — печеньками. Иногда — «конкурентная», но почему-то конкурентная только с прожиточным минимумом. Деньги, по мнению некоторых работодателей, вообще портят людей. Гораздо важнее «стабильность», «опыт» и «возможность расти», правда, расти предлагается исключительно вширь — за счёт дополнительных обязанностей. Особенно трогает пункт: «Если вас интересуют деньги — вы нам не подходите». Спасибо за честность. Редко кто так открыто признаётся, что труд должен быть бескорыстным, желательно круглосуточным и с энтузиазмом. При этом компания, разумеется, коммерческая, и прибыль её почему-то интересует очень даже сильно. Работодатели любят говорить о лояльности, забывая, что это улица с двусторонним движением . Нельзя требовать вовлечённости, ответственности и самоотдачи, предлагая взамен только «опыт», «строчку в резюме» и чашку кофе по пятницам. И пока одни продолжают писать вакансии в стиле «найдём супергероя за спасибо» , другие искренне удивляются: «А где же кадры?» Наверное, там же, где и адекватные условия труда — в параллельной реальности. Но ничего. Главное — коллектив дружный. А печеньки… печеньки всегда можно заменить обещаниями Коллеги, немного юмора — конечно, такого не может быть. Если вдруг узнали себя на собеседовании… это просто совпадение
Короткий внедренческий чек-лист (КИИ / февраль 2026): что обновить в документах, процессах и СЗИ drive.google.com/...ing
Распоряжение № 360-р и категорирование КИИ: практический алгоритм Главная идея: Распоряжение Правительства РФ № 360-р не присваивает категории значимости. Оно лишь определяет, какие системы должны пройти процедуру категорирования. А Постановление № 127 уже отвечает на вопрос: какая категория значимости присваивается объекту. Таким образом, процедура категорирования КИИ выглядит так: 1) Выявление объектов КИИ (360-р) Сначала комиссия делает инвентаризацию информационных систем, ИТКС и АСУ. На этом этапе не нужно сразу определять критичность — проверяется соответствие типовым объектам отраслевого перечня. Примеры по отраслям: Энергетика АСУ ТП подстанций Системы диспетчеризации электростанций Системы мониторинга КИИ Транспорт Системы управления движением на железной дороге или в авиации Системы диспетчеризации городского транспорта Связь Сети передачи данных для работы телеком-операторов Системы маршрутизации и управления сетевыми сервисами Не включаются без обоснования: бухгалтерские системы, локальные офисные сервисы. Совет эксперта: системы, которые формально не в перечне, но могут влиять на критические процессы, включаются только с экспертным заключением. 2) Формирование перечня объектов для категорирования Список составляется исходя из отраслевого перечня, а не из собственного мнения о критичности. Важно документировать, почему системы включены или исключены. Примеры включения: Энергетика: АСУ ТП и системы диспетчеризации Транспорт: управление движением поездов или авиарейсов Связь: центральные узлы передачи данных Примеры исключения: Бухгалтерские системы Локальные офисные сервисы 3) Оценка последствий по Постановлению № 127 Комиссия оценивает возможные последствия компьютерного инцидента: Социальные (например, аварии в транспорте) Политические (сбой работы критических сетей связи) Экономические (остановка энергосетей) Экологические (аварии на промышленных объектах) Экспертная оценка особенно важна для систем вне перечня, но потенциально значимых. На основе оценки присваивается категория. Если ни один критерий не достиг порога — фиксируется решение о непринадлежности к категории. 4) Оформление результатов и направление во ФСТЭК Комиссия оформляет акт категорирования Руководитель организации утверждает акт Сведения направляются во ФСТЭК России в течение 10 рабочих дней, даже если категория не присвоена Важно: статья 7 ФЗ № 187-ФЗ связывает категорию с проверкой правильности присвоения по типовым объектам отраслей. Практические рекомендации 360-р — фильтр отбора объектов ПП № 127 — определяет категорию значимости после оценки последствий Экспертное заключение необходимо для систем вне перечня, но значимых для процессов Ошибки, которых стоит избегать: Использовать 360-р как таблицу категорий Игнорировать перечни и оценивать только критические процессы Включать все системы без обоснования Отсутствие документации по включению/исключению Вывод: 360-р применяется в начале процедуры ПП № 127 — на этапе оценки последствий и присвоения категории Экспертная оценка ключевая для правомерного включения объектов вне перечней
Вопрос от подписчика. "Добрый день! Возник такой вопрос. Нарушение работы объекта КИИ из-за стихийных бедствий является компьютерным инцидентом? Если судить по определению, то да. Но все равно хотелось бы услышать Вашу точку зрения." Ответ эксперта. Да, формально это компьютерный инцидент (КИ), даже если причина — стихия. Но это не компьютерная атака. Разберём по полочкам. Почему “да” по КИ: В 187-ФЗ “компьютерный инцидент” — это факт нарушения/прекращения функционирования объекта КИИ и/или нарушение безопасности информации. И отдельно сказано “в том числе в результате компьютерной атаки” → атака не обязательна. Почему “не атака”: “Компьютерная атака” — это целенаправленное воздействие программными/программно-аппаратными средствами. Наводнение/пожар/ураган не являются целевым кибервоздействием → значит, инцидент есть, атаки нет. Как правильно вести на практике (коротко): 1) Фиксируем как КИ (есть факт нарушения функционирования). 2) Ставим причину: неатаковый (стихийное бедствие/авария инженерки). 3) Делаем минимальную киберпроверку, чтобы исключить “смешанный” сценарий (логи/EDR, аномальный трафик, компрометация учёток). 4) Если объект значимый и вы в контуре уведомлений: сообщаем как “КИ без признаков атаки” (причина — стихия, признаки атаки не выявлены/проверка продолжается). Итог: Стихийное бедствие → компьютерный инцидент (как факт остановки/нарушения работы), но НЕ компьютерная атака.
Категорирование объектов КИИ с учётом отраслевых перечней, ПП РФ №127 и методических рекомендаций отраслевых регуляторов
Практическая методика для организаций
Категорирование объектов критической информационной инфраструктуры (КИИ) — ключевая обязанность субъектов КИИ по Федеральному закону №187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации».
На практике многие проводят категорирование «по шаблону»: описали систему, заполнили показатели значимости и отправили материалы. Но после появления типовых отраслевых перечней объектов КИИ, уточнений по методологии и роста требований к обоснованиям подход стал заметно более структурированным...
Коллеги, подготовили чек-лист по категорированию объектов КИИ Он подходит и для внутренней работы, и для слушателей наших курсов: чекбоксы кликабельные, можно отмечать прямо в PDF и использовать как рабочую шпаргалку/контроль выполнения. drive.google.com/...ing