Позавчера я рассмотрел проект методики моделирования угроз, а сегодня хочу систематизировать то, что мне в проекте методики не понравилось или не хватило:
- Мне показалось ограниченной привязка к классической триаде "конфиденциальность-целостность-доступность". Даже в документах ФСБ по персданным от 2008-го года говорилось о большем количестве свойств информации, которые надо обеспечивать в рамках ИБ. За рамки триады выходит и ГОСТ Р ИСО/МЭК 13335, которые не ограничивается только КДЦ, но также упоминает подотчетности, аутентичность и т.п. Правда, надо признать, что спор о том, все ли можно свести к триаде или нет, - старый. Мы его еще в 2012-м году в блоге вели. Но я остаюсь при своем мнении - триадой все не ограничивается и есть угрозы, которые выходят за ее рамки.
- Технократичность методики является следствием ее привязки к триаде. Допустим, приход регулятора, просроченный сертификат, отсутствие лицензии ФСБ на деятельность в области шифрования, внесение изменений в аттестованный объект информатизации, снижение бюджета на ИБ, сокращение персонала отдела защиты информации... По мне, так это все угрозы, которые попадают в поле зрения специалиста по ИБ и, зачастую, они даже более важны, чем угрозы КДЦ. Но в методику они совсем не попали. Причина этого, конечно, понятна, но все-таки оставляет чувство некоторой незавершенности.
- Меня смущает отсутствие примеров. И хотя формализм - это традиция в документах ФСТЭК, хотелось бы увидеть большее число примеров, чем в текущем варианте. В конце концов мы говорим о методическим документе, а не бюрократическом приказе. Задача методички - разъяснить и показать "как надо", а это сложно сделать без примеров. Примеры сильно улучшили бы текст методички.
- Отсутствие нумерации. Когда Банк России выпускал 5-ю редакцию своего СТО, он переиграл почти всю нумерацию и те, кто делал маппинг из требований СТОv4 в другие стандарты и требования вынуждены были все переделывать заново. В методике ФСТЭК другая проблема - полное отсутствие сквозной нумерации. Очень сложно ссылаться на разделы такого документа.
- Отсутствие иллюстраций. Понятно, что в ФСТЭК нет выпускников Строгановского училища, но хотя бы блок-схемы типовой информационной системы и каналов/векторов реализации атак на нее, не помешали бы.
- Коль скоро мы говорим о методичке, которая призвана снизить число ошибок при моделировании угроз, то неплохо было бы в приложение включить список типичных ошибок при составлении списка актуальных угроз. Тем более, что у ФСТЭК этот список есть - они его представляли на своей конференции. Почему бы не включить? Лишним он точно не будет.
- Но, пожалуй, самое серьезное нарекание у меня вызывает итоговая таблица 8, которая, собственно, и отделяет актуальные угрозы от неактуальных. У меня такая же претензия было 7 лет назад, к прошлой методике определения актуальных угроз. Неравномерно в матрице/таблице проходит граница между актуальными и неактуальными угрозами; неравномерно. Число актуальных угроз явно завышается и делается это специально. В причины я вдаваться не готов - мне они понятны, хотя я их и не разделяю.
По сути, каких-либо серьезных претензий к проекту документа у меня нет. Все мои замечания касаются скорее удобства пользования им.
19 коммент.:
Алексей, по поводу абзаца: "•Технократичность методики является следствием ее привязки к триаде. Допустим, приход регулятора, просроченный сертификат, отсутствие лицензии ФСБ на деятельность в области шифрования, внесение изменений в аттестованный объект информатизации, снижение бюджета на ИБ, сокращение персонала отдела защиты информации... По мне, так это все угрозы, которые попадают в поле зрения специалиста по ИБ и, зачастую, они даже более важны, чем угрозы КДЦ. Но в методику они совсем не попали. Причина этого, конечно, понятна, но все-таки оставляет чувство некоторой незавершенности".
Угрозы-то это угрозы. Но чему (или кому)? Проект методики оценивает угрозы ИНФОРМАЦИИ, а в этом абзаце говорится об угрозах ОПЕРАТОРУ. А это суть разные вещи.
Согласен со всем. И действительно, можно рассматривать "уровень автоматизации" моделирования. Иными словами - насколько просто сделать программу автоматизации моделирования. Чем легче - тем она пригоднее в реальных условиях.
Ну и про КЦД - Алексей прав, но это "хотелка" с учетом того, для кого этот документ обязателен. И опять, же по традиции ФСТЭК - никто не мешает зрелым компаниям руководствоваться со своими грамотными аддонами за рамками триады.
Мне кажется наиболее проблемным местом в документе является "уровень защищенности" и "уровень проектной защищенности". Определение уровня защищенности на стр.25 документа - не совсем ясно как на практике это оценить... По поводу проектной защищенности тоже возникает вопрос - например, по табл.3 определяем, что уровень защищенности низкий, т.к. все показатели попали в третий столбец, кроме п.6 (все ТС у нас в контролируемой зоне). И по табл. 4 для угроз физического доступа к оборудованию получим высокую степень их реализации при любом потенциале нарушителя... не логично как-то.
Да, с "уровнем проектной защищенности" авторы перемудрили.
Непонятно, как достичь высокого уровня исходной (проектной) защищенности. Судя по таблице 3, никак. Впрочем, и среднего в мало-мальски крупной ИС тоже не достигнешь. Да и от потенциала нарушителя этот уровень не зависит. А не достигнув высокого уровня, ИС нельзя вводить в эксплуатацию:
«ввод в эксплуатацию информационной системы осуществляется при условии достижения высокого уровня исходной защищенности информационной системы от нарушителя с заданным потенциалом».
Термин "границы информационной системы" тоже доставляет. Сотрудник, зашедший в помещение, где установлена рабочая станция ИС, пересек границу ИС или нет? Неясно. А от этого будет зависеть, внешний он или внутренний.
В общем, в руках проверяющих появится ооочень гибкий инструмент...
По поводу границ. Смотрим проект:
внешние нарушители (тип I) – лица, не имеющие права доступа к ИС, ее отдельным компонентам и реализующие угрозы безопасности информации из-за границ ИС;
внутренние нарушители (тип II) – лица, имеющие право постоянного или разового доступа к ИС, ее отдельным компонентам".
То есть тип нарушителя (внутренний/внешний) определяется не доступом в помещение, а правом доступа к информации или элементам ИС...
2 vsv
ОК. Т.е при сдаче железа в ремонт к нему получают доступ внутренние нарушители?
А при сдаче железа в ремонт смотрим п. 19.2 Приказа ФСТЭК № 17...
"А при сдаче железа в ремонт смотрим п. 19.2 Приказа ФСТЭК № 17..."
Здорово. А что, в железе, помимо носителей, больше ничего нет? Нарушитель только на информацию, хранящуюся на носителях, может воздействовать?
А это уже п. 17.5 того же приказа...
п. 17.5. " Ввод в действие информационной системы осуществляется в соответствии с законодательством Российской Федерации об информации, информационных технологиях и о защите информации и с учетом ГОСТ 34.601 и при наличии аттестата соответствия."
Очень познавательно, спасибо.
Выскажу пару существенных замечаний по проекту методике.
1) Методика определила какие разделы должны быть в модели угроз. Но структура модели угроз ранее была также описана в окончательной редакции проекта национального стандарта ГОСТ Р «Защита информации. Информационные системы и объекты информатизации. Угрозы безопасности информации. Общие положения» (ТК 362 Защита информации). Стандарт обсуждался, увязан с другим стандартами, дошел до окончательной редакции. Видно забыли про него ... И теперь методика и стандарт не согласуются между собой. На мой взгляд в стандарте этот момент описан лучше.
2) В методике степень возможного ущерба от реализации угрозы безопасности информации определяется степенью негативных последствий от нарушения конфиденциальности, целостности или доступности каждого вида информации, содержащейся в информационной системе. Причем в качестве единой шкалы измерения степени негативных последствий принимаются значения «незначительные», «умеренные» и «существенные» негативные последствия. Но в качестве одного из критериев отнесения угрозы к актуальным использован термин «неприемлемое» негативное последствие (ущерб). Но методика не оговаривает как и кто будет оценивать эту «неприемлемость». Можно ли ставить знак равенства между «существенным» и «неприемлемым»? На мой взгляд нет. В итоге на выходе модели мы не можем сделать корректное заключение о списке актуальных угроз.
Сергей Викторович, разговоры только про "информацию" - это дань истории. ФСТЭК также активно смотрит на угрозы информационным системам. Надо еще шаг сделать и смотреть на угрозы оператору ;-)
Сергей Викторович, а отказ вендора от обновления СрЗИ - это угроза чему? ИС или оператору?
Уважаемые коллеги! хотелось-бы обратить внимание на практическую проблему оценки значимости государственных информационных ресурсов/ степени вероятного ущерба.
Методика, как и 17 приказ ФСТЭК, предназначена в первую очередь именно для государственных информационных систем (информационного ресурса).
При определении актуальных угроз, как и при определении класса защищенности ГИС, параметр значимости/ ущерба предлагается оценивать самостоятельно.
В результате, на практике, мы имеем необоснованный разброс оценок. Например, разброс требований к идентичным объектовым ГИС может включать крайние значения (были случаи, когда уровень значимости информации ИС «Бухгалтерия и кадры» оценили как УЗ-1 и просили обосновать обратное со ссылкой на какой-нибудь правовой акт).
Самостоятельная оценка значимости/ ущерба, даже с привлечением лицензиатов, сталкивается с проблемой: чиновнику (гос.служащему) нужна ссылка на правовой акт (методику, приказ и т.п.)
Надеялись увидеть какие-то указания (рекомендации) в Методике.
Оценка ущерба ИБ - задача непростая, а при отсутствии норм/ критериев хотя-бы для типовых ГИС (ГИР) - сложно реализуемая.
Спасибо за внимание. Очень проблемный практический вопрос!
Николай, ваши предложения?
Решение вопроса возможно в поле Минкомсвязи.
в приказе от 22 августа 2013 г. N 220 Минкомсвязь приводит рекомендации для ОГВ по учету ИС и компонентов ИТКИ. В развитие данных рекомендаций можно добавить приложение в виде таблицы: типовой информационный ресурс – масштаб ИС - значимость.
Имея постоянную практику работы с федеральными и региональными ИС ОГВ готовы оказать помощь в разработке материалов.
Пробовали заинтересовать данной проблемой ГНИИИ ПТЗИ ФСТЭК России – без успеха.
Так надо в ФСТЭК писать
Алексей, подскажите вышеуказанный проект МЕТОДИКИ ОПРЕДЕЛЕНИЯ УГРОЗ БЕЗОПАСНОСТИ ИНФОРМАЦИИ В ИНФОРМАЦИОННЫХ СИСТЕМАХ ФСТЭК утвердил или нет? На сайте службы никакой информации не нашел
Совсем скоро
Отправить комментарий