Аттестация ГИС: а ваша система соответствует закону?

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

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

Если говорить просто, аттестация информационных систем – это набор организационных и технических мероприятий, которые подтверждают, что система защиты информации соответствует требованиям. Вся процедура описана в приказе ФСТЭК №77 от 29 апреля 2021 года. Он действует для всех новых договоров по аттестации. Но по старым договорам все еще можно использовать документы, принятые в 1994 году Гостехкомиссией. Также есть пара национальных стандартов, которые регулируют общие вопросы аттестации и определяют требования к ее проведению. Эти стандарты будут действовать до тех пор, пока все старые обязательства не будут выполнены.

Требования к защитным мерам, которые нужно подтвердить при аттестации, прописаны в нескольких законодательных актах. Например, жизненный цикл ГИС регулируется Постановлением Правительства РФ №676 от 6 июля 2015 года, а требования к защите таких систем – приказом ФСТЭК России №17 от 11 февраля 2013 года. Кроме того, требования к сертификации средств защиты закреплены в приказе ФСТЭК №55 от 3 апреля 2018 года. Далее я расскажу, когда аттестация обязательна, кто может ее проводить и как она проходит по шагам.

Когда нужна аттестация

Объекты, которые нужно аттестовать в обязательном порядке, можно поделить на три категории:

• государственные и муниципальные информационные системы, особенно те, где обрабатываются персональные данные;
• системы управления на предприятиях оборонной промышленности;
• помещения для конфиденциальных переговоров;

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

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

Подготовка к аттестации: как сэкономить и избежать лишних трат

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

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

Кто может проводить аттестацию

По приказу ФСТЭК №77, аттестацию могут проводить только организации, у которых есть лицензия на работы по защите конфиденциальной информации (ТЗКИ). В лицензии четко прописано, что они могут проводить «аттестационные испытания и аттестацию на соответствие требованиям по защите информации.

Но есть один момент: органы госвласти могут аттестовать свои собственные системы без лицензии. Полный список организаций, имеющих право на такие работы, можно найти на сайте ФСТЭК.

Чтобы избежать влияния владельцев системы на результаты аттестации, ФСТЭК ввела требование к независимости экспертов, которые проводят проверку. Это значит, что в комиссии могут работать только специалисты, не зависящие от владельца системы. В документе не раскрывается, как именно это должно работать на практике, но если посмотреть в Федеральный закон «Об аудиторской деятельности», там говорится, что аудитор не может проверять ни дочерние, ни родительские компании.

Вопрос в том, могут ли аттестаторы проверять системы внутри холдинга? Согласно приказу ФСТЭК №17, аттестатор не может быть тем, кто участвовал в разработке или внедрении системы защиты. Если он не был задействован в этих процессах, его можно включить в состав комиссии.

Из каких этапов состоит аттестация

Аттестация ГИС проходит в несколько этапов. Сначала специалисты определяют, каким требованиям безопасности должна соответствовать система. Далее проверяют документы, чтобы удостовериться, что все меры защиты корректно оформлены и реализованы. Когда все документы в порядке, комиссия приступает к проверке того, насколько они соответствуют реальной эксплуатации системы.

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

Что проверяют в документах

Когда проводится документарная проверка, аттестационная комиссия оценивает большой набор бумаг, список которых прописан в приказах ФСТЭК №17 и №77. Вот основные документы, которые обычно проверяются:

• Технический паспорт на объект информатизации.
• Акт классификации системы или акт категорирования значимого объекта КИИ.
• Модель угроз безопасности информации.
• Техническое задание на создание или модернизацию объекта информатизации, а также системы защиты.
• Проектная документация на систему защиты информации.
• Эксплуатационная документация на систему защиты и средства защиты.
• Организационно-распорядительные документы по защите информации.
• Результаты анализа уязвимостей и приемочных испытаний системы защиты.
• План мероприятий по защите информации.
• Документы, касающиеся оценки угроз безопасности.
• Бумаги по управлению системой защиты и конфигурацией объекта.
• Документы по реагированию на инциденты безопасности.
• Бумаги по обучению и информированию персонала.
• Документы по контролю уровня защиты информации.

С введением приказа ФСТЭК №77 новых обязательных документов особо не появилось – все эти бумаги проверялись и раньше. Но теперь стало четко понятно, кто должен предоставлять результаты инструментального сканирования.

Раньше по этому поводу возникали споры: некоторые компании считали, что это задача экспертов аттестационной комиссии, а органы по аттестации настаивали, что сканирование должны проводить владельцы системы. Теперь в приказе ясно сказано: результаты сканирования предоставляет сам владелец объекта.

Нейтрализация угроз безопасности: что важно прописать

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

Особенно важно учесть угрозы, связанные с контейнеризацией. В последнее время ФСТЭК часто возвращает документы на доработку, если такие угрозы не учтены. Ведомство даже выпустило рекомендации для госорганов по защите информации при использовании технологий контейнеризации в ГИС. Если нет сертифицированных средств защиты, можно использовать компенсирующие меры, что мы и рекомендуем делать, исходя из практики.

Требования к сторонним компонентам

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

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

Таким образом, важно учитывать требования эксплуатационной документации к сторонним компонентам, даже если они не явно указаны в приказе №77.

Когда в отчете об анализе могут быть уязвимости

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

Также можно обосновать, что уязвимость существует, но ее невозможно эксплуатировать. Например, может возникнуть ситуация: сканер находит самоподписанный сертификат, и теоретически злоумышленник мог бы перехватить данные с помощью атаки MITM (man-in-the-middle). Но если система вообще не использует PKI (инфраструктуру открытых ключей) для работы с данными, то эта уязвимость существует лишь на бумаге и не представляет опасности.

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

Еще один вариант – персональное указание ФСТЭК. Недавно регулятор запретил некоторым госорганам устанавливать обновления безопасности на иностранное ПО из-за санкций. В таком случае, если организация получила такое указание, она может предоставить отчет с не устраненными уязвимостями.

Проверка реальных условий эксплуатации системы

Система в реальной эксплуатации должна полностью соответствовать тому, что прописано в документации. Но на практике часто бывает иначе: например, в документах нет ни слова про удаленный доступ, а на объекте обнаруживается модем с SIM-картой, который администратор использует для удаленного доступа. В таких случаях приходится отключать это устройство, а иногда даже корректировать модель угроз и проектные решения.

Проверка на объекте проводится по программе и методикам аттестационных испытаний (ПМИ). В отличие от итоговых документов вроде протокола или заключения, ПМИ согласовывается с владельцем системы. Более того, ПМИ может корректироваться по ходу испытаний, что удобно: если что-то идет не так, можно скорректировать метод проверки. В ходе аудита эксперты оценивают, как реализована защита от актуальных угроз безопасности.

Рекомендуется сохранять журналы, записи интервью, скриншоты и записи работы с компонентами системы во время проверки. Хотя по закону это не обязательно, такие записи могут пригодиться для разрешения спорных моментов.

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

Отправка документов во ФСТЭК России

Есть некоторые тонкости по поводу отправки документов в ФСТЭК после аттестации. Во-первых, владелец системы должен дать органу по аттестации разрешение на передачу всех документов, включая акт классификации, техпаспорт и другие чувствительные сведения (которые содержатся в ПМИ, протоколе и заключении) в ФСТЭК. Мы рекомендуем прописывать такое разрешение в договоре на этапе аттестации.

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

Формат предоставления документов не строго регламентирован (подойдут doc, docx, pdf и другие). Мы советуем отправлять сопроводительное письмо на бумаге с приложением электронных файлов в формате, который легко читается на любых устройствах: например, pdf, png или jpeg. Это позволит избежать проблем, если у регулятора другая версия ПО.

Что происходит после аттестации

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

Дальнейшая нагрузка по поддержанию безопасности ложится на владельца системы. Закон требует регулярных процедур: патч-менеджмент, мониторинг инцидентов, управление изменениями и другие задачи. Эти мероприятия нужно проводить постоянно, ведь срок службы системы может составлять десятилетия.

Для каждой аттестованной системы нужно проводить контрольные проверки как минимум раз в два года и сообщать о результатах во ФСТЭК. А если система относится к ГИС первого класса, проверки нужно проводить ежегодно.

После аттестации система, как правило, развивается и модернизируется.

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

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