понедельник, 24 апреля 2017 г.

ИБ. НПА. Анализ уязвимостей ГИС


Продолжаем рассматривать недавние изменения в приказ ФСТЭК России №17. В этот раз – анализ уязвимостей ГИС.
Теперь анализ уязвимостей ГИС требуется проводить на 3 из 6 этапах жизненного цикла системы защиты ГИС: формирования требований, внедрения и аттестации.

1. На этапе анализа угроз безопасности информации ГИС, необходимо провести анализ возможных уязвимостей ИС, используя при этом БДУ ФСТЭК России, а также иные источники данных об уязвимостях в качестве исходных данных. В модель угроз нужно включить описание возможных уязвимостей ИС.
Основное отличие от других этапов кроется в слове “возможных”. Не фактических, а именно возможных. А при наличие хорошей фантазии, у нас будет возможно всё. На сколько я понимаю, тут нужна некая классификация всех возможных уязвимостей и исключение неподходящих типов уязвимостей по определенным причинам (отсутствие объекта воздействия, определенные структурные характеристики, неиспользуемые ИТ). 
Проблема в том, что в БДУ ФСТЭК в разделе Уязвимости отсутствует подобная классификация уязвимостей. Кроме того, разделе Уязвимости приведены только фактические уязвимости ПО. А как же уязвимости ГИС в целом? Недостатки орг. мер?
На самом деле, перечень таких возможных уязвимостей скрывается в неструктурированном виде в тексте угроз БДУ ФСТЭК: “Данная угроза обусловлена уязвимостями некоторых системных (материнских) плат – наличием механизмов аппаратного сброса паролей, установленных в BIOS/UEFI” или “Данная угроза обусловлена слабостями механизмов фильтрации сетевого трафика и антивирусного контроля на уровне организации”.

2. На этапе внедрения системы защиты информации требуется провести уже фактический анализ уязвимостей.
“При анализе уязвимостей информационной системы проверяется отсутствие известных уязвимостей средств защиты информации, технических средств и программного обеспечения, в том числе с учетом информации, имеющейся у разработчиков и полученной из других общедоступных источников, правильность установки и настройки средств защиты информации, технических средств и программного обеспечения, а также корректность работы средств защиты информации при их взаимодействии с техническими средствами и программным обеспечением.
По результатам анализа уязвимостей должно быть подтверждено, что в информационной системе отсутствуют уязвимости, содержащиеся в банке данных угроз безопасности информации ФСТЭК России, а также в иных источниках, или их использование (эксплуатация) нарушителем невозможно.”
Тут уже речь о других уязвимостях – известных или фактических уязвимостях. При этом нужно проверить как минимум все уязвимости из БДУ. Выгружаем в XLS . И ставим + - напротив уязвимостей J


Но хорошо, что уязвимости имеют такие поля как Производитель, Наименование ПО, Версия ПО. Составив заранее полный перечень ПО, можно сделать выборку нужных уязвимостей. Но что делать с результатами? Например, для Windows 8.1 – 247 уязвимостей в БДУ. Далее нужно в каждой пройти по ссылке на внешние источники и проверить что там предлагалось для устранения уязвимостей, проверить наличие установленных обновлений для данных уязвимостей.

Вручную - сложно. Хотелось бы, чтобы сканнеры уязвимостей могли работать с БДУ и делать всё за нас. Давайте посмотрим…
RedCheck от Алтекс-Софт : “RedCheck производит поиск уязвимостей по нашей базе ovaldb которая синхронизируется с БД угроз безопасности информации ФСТЭК России! Список уязвимостей Вы можете посмотреть на сайте базы данных https://ovaldb.altx-soft.ru/Definitions.aspx?refsource=FSTEC .”
Вроде ок. (UPDATE) за 2017 г. в базе RedCheck уже 372 уязвимости из БДУ ФСТЭК.
Ревизор Сети 3.0 от ЦБИ: “Ревизор Сети изначально осуществляет поиск включенных в БДУ ФСТЭК России (http://bdu.fstec.ru) уязвимостей, содержащихся в операционных системах Windows и функционирующих в них приложениях и средствах защиты информации, в том числе российской разработки. Помимо поиска уязвимостей из базы данных уязвимостей ФСТЭК России Сетевой сканер «Ревизор Сети» версии 3.0 осуществляет поиск уязвимостей, содержащихся в таких источниках, как cve.mitre.org, ovaldb.altx-soft.ru, microsoft.com и других источниках. ”
XSpider от Positive Technologies “Обязательно такая возможность будет. В июне в рамках пересертификации XSpider будет передана в испытательную лабораторию ФСТЭК сборка уже с таким функционалом ”.
Сканер-ВС от Эшелон “Сканер-ВС поддерживает поиск уязвимостей по БДУ ФСТЭК России”. Правда опыт показал, что текущая, сертифицированная версия – не поддерживает.
Итого, в перспективе возможно за нас всё будут делать сканеры, но в данный момент готового отчета, подтверждающего отсутствие уязвимостей из БДУ ФСТЭК я не обнаружил. С актуальностью баз остаются вопросы – возможно придется проверять результаты и последние уязвимости просматривать вручную.
Кроме того, не забываем, что в анализ уязвимостей входит ещё анализ настройки СЗИ, ПО и ТС и анализ корректности работы СЗИ.

3. На этапе аттестации требуется провести следующие испытания “анализ уязвимостей информационной системы, в том числе вызванных неправильной настройкой (конфигурированием) программного обеспечения и средств защиты информации” при этом в качестве исходных данных используются “результаты анализа уязвимостей информационной системы”. Это как вообще?
Просто повторяем то что делали на этапе внедрения? С учетом последних требований к разделению аттестаторов и внедренцев, видимо тут расчет на выборочный независимый дублирующий анализ.  


3 комментария:

Zakhar Mikhaylov комментирует...

Сергей! Вот это утверждение явно неверное: "Жаль только последняя уязвимость по ссылке – от 2016 г. А в БДУ уже куча за 2017 г." Если пройти по ссылке https://ovaldb.altx-soft.ru/Definitions.aspx?refsource=FSTEC и вбить в поле "Title"
"2017" найдутся 372 ссылки с уязвимостями 2017 года. Мы работаем с БДУ ФСТЭК http://bdu.fstec.ru/vul непрерывно и поддерживаем корреляцию с этой базой с момента её создания.https://www.altx-soft.ru/news/show-169.htm

Сергей Борисов комментирует...

Прошу прощения, Захар. Моя ошибка. Просматривал уязвимости в базе с максимальными номерами OVALid 46950-47250, рассчитывал что они и будут последними по времени.

Александр Германович комментирует...

По идее, в ходе аттестации ИС нужно проверить, устранены ли уязвимости, найденные на этапе "внедрение системы ЗИ".
Тем более, что в новой версии приказа подразумевается, что этим должны заниматься разные люди: внедрением занимаются разработчики, а аттестацией - аттестаторы.
Скорее всего, речь идет именно о дублирующем анализе. И правильнее было бы проверить не только устранение тех уязвимостей, которые были выявлены ранее, но и вообще "с начала".