четверг, 5 декабря 2013 г.

СОИБ. Анализ. Мои предложения к Методическим рекомендациям ФСТЭК по защите ГИС.


Замечания и предложения:
1.      Мерам защиты – короткие и запоминающиеся имена.
Разработчики документов ФСТЭК загнали себя в терминологическую ловушку. По закону они должны были разработать состав и содержание мер защиты. По логике они должны были для начала придумать понятные и удобные наименования для мер защиты. Они попытались это совместить. Вышло неудачно.

Например “ЗИС.28. Воспроизведение ложных и (или) скрытие истинных отдельных информационных технологий и (или) структурно-функциональных характеристик информационной системы или ее сегментов, обеспечивающее навязывание нарушителю ложного представления об истинных информационных технологиях и (или) структурно-функциональных характеристиках информационной системы”

Почему не годится такое наименование меры? Потому что в процессе жизненного цикла СОИБ участвует большое количество лиц: регулятор, разработчик средств защиты, оператор, обработчик, проектировщик, поставщик, аутсорсер, эксплуатирующий средства защиты, аудитор.

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

Кроме того, ГИС – это только одна из множества ИС Организации. (например, 10%). ИСПДн – это тоже одна из множества ИС Организации (например, 10%). Остальные системы Организация тоже хочет защищать и наверняка будет использовать для этого какие-то стандарты: ИСО серии 27000, Cobit, NIST.

Для того чтобы оператор мог сопоставлять стандарты и использовать сходные меры для защиты всех ИС, необходимо использовать обще-употребимые наименования.

Кстати, ранее я уже делал сопоставление мер из Top 20 от NIST и мер защиты из приказа 21 ФСТЭК. Но лучше если такое сопоставление будет идти от группы экспертов и регулятора.

Предложение 1. Дать каждой базовой мере защиты короткое наименование. Предпочтительно на английском языке. В крайнем случае можно на русском.

Пример:
Условное обозначение и номер меры
Наименование Меры защиты информации в информационных системах
Определение Меры защиты информации в информационных системах
ИАФ.1
Идентификация и аутентификация пользователей
Identification and Authentication (Organizational Users)
Идентификация и аутентификация пользователей, являющихся работниками оператора
ИАФ.2
Идентификация и аутентификация устройств
Device Identification and Authentication
Идентификация и аутентификация устройств, в том числе стационарных, мобильных и портативных
ИАФ.3
Управление идентификаторами
Identifier Management
Управление идентификаторами, в том числе создание, присвоение, уничтожение идентификаторов
ИАФ.4
Управление аутентификацией
Authentificator   Management
Управление средствами аутентификации, в том числе хранение выдача, инициализация, блокирование средств аутентификации и принятие мер в случае утраты и (или) компрометации средств аутентификации

Предложение 2. Разработать в качестве приложения к методическому документу – таблицу соответствия базовых мер защиты и мер из стандартов ИСО серии 27000, Cobit, NIST.

2.      Адаптации – дефиницию!!!

В разделе 2.3 б) не определено как именно учитываются цели, задачи и перечень мероприятий.
“2.3 б)
При адаптации базового набора мер защиты информации учитываются:
цели и задачи защиты информации в информационной системе;
перечень мероприятий проводимых оператором по обеспечению безопасности в рамках организации в целом;”

Не определены характеристики ИС и связь между характеристиками и мерами защиты
“2.3 б)
Адаптация базового набора мер защиты информации предусматривает исключение мер, непосредственно связанных с информационными технологиями, не используемыми в информационной системе, или структурно-функциональными характеристиками, не свойственными информационной системе.”

Предложение 3. Необходимо привести базовый набор “целей” и “задач защиты информации в ИС”, типы “мероприятий по обеспечению безопасности в рамках организации в целом”. Дать целям и задачам идентификаторы.
Необходимо для каждой базовой меры защиты информации определить, каким целям и задачам она соответствует. А так-же провести связь между “мероприятиями по ... в целом” и базовыми мерами защиты информации. В каких случаях мероприятие может исключать меры защиты?

Предложение 4.
Необходимо определить базовый набор структурно-функциональных  характеристик. Дать им идентификаторы.
Необходимо привести зависимость между базовыми мерами защиты и структурно-функциональными характеристиками. В каких случаях наличие определенных характеристик может исключать меры защиты?  Это все можно привести в описании меры защиты.

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

От Оператора требуется сопоставлять меры и угрозы, а документах ФСТЭК такой взаимосвязи между угрозами и мерами не приводится. Таким образом, документы ФСТЭК не облегчают, а затрудняют работу оператора по определению необходимых мер и проектированию СОИБ. Ведь в отсутствии каталога мер защиты, оператор мог бы для каждой актуальной угрозы самостоятельно придумать подходящее название и содержание. А теперь ему придется для каждой угрозы перебирать все 111 базовых мер и каким-то образом пытаться определить соответствие.
Предложение 5. Для каждой базовой меры защиты определить базовый набор угроз, для блокирования которых (или для снижения вероятности которых) может использоваться данная мера.

4.      Отсутствуют метрики и процедуры для оценки меры.
В соответствии с приказом 17 ФСТЭК в рамках внедрения мы должны проверять работоспособность системы защиты информации, в рамках аттестации – оценивать и в рамках эксплуатации СОИБ регулярно анализировать и оценивать СОИБ:
“16.4. Предварительные испытания системы защиты информации информационной системы ... включают проверку работоспособности системы защиты информации информационной системы,  ...
18.14 В ходе контроля (мониторинга) за обеспечением уровня защищенности информации, содержащейся в информационной системе, осуществляются:
анализ и оценка функционирования системы защиты информации информационной системы, включая выявление, анализ и устранение недостатков в функционировании системы защиты информации информационной системы;
принятие решения по результатам контроля (мониторинга) за обеспечением уровня защищенности информации о доработке (модернизации) системы защиты информации информационной системы, повторной аттестации информационной системы или проведении дополнительных аттестационных испытаний.”

В описании базовых мер защиты отсутствует описание метрик и процедур оценки работоспособности базовых мер защиты или обеспечения ими уровня защищенности. Данное упущение может стать проблемой или даже коррупциогенным фактором при внешнем аудите или проверке Регулятора, так как разные специалисты будут трактовать работоспособность меры по-своему.
Предложение 6. Для каждой базовой меры защиты определить метрики и процедуры анализа работоспособности. Например, можно использовать одну из лучших мировых практик «Critical Controls for Effective Cyber Defence» от SANS.

PS:
Так и не успел добраться до замечаний к самим мерам. Об этом в следующей заметке.

В данной заметке только замечания. Значит ли это, что у меня негативное отношение к документу? Вовсе нет. Я благодарен ФСТЭК и группе экспертов разработчиков за то что документ в принципе появился на свет. А он мог и не появится. 

Но от этих же лиц зависит, будет ли этот документ валятся в пыли или активно использоваться при создании систем защиты информации. А если будет использоваться, то в 5% или в 50% работ?
Хотелось бы вариант документа, которым буду пользоваться регулярно при создании и эксплуатации СОИБ, а иначе зачем вообще всё это затеяно?

Ну а чтобы этот методический документ приобрел статус "лучшей практики" есть следующее: 
Предложение 7. В информационном письме или пояснительной записке к документу привести следующую информацию:
·        кто (какие эксперты или организации) разрабатывал данный документ?
·        как осуществлялся отбор лиц для участия в разработке документа?
·        на какой основе эти лица участвовали в разработке? Платно или бесплатно? Если платно, то по какому конкурсу, тендеру?

PSS: Также комментарии и замечания (но пока без предложений) к данному документу можно почитать у Алексея Лукацкого и Андрея Прозорова.

5 комментариев:

Алексей Лукацкий комментирует...

У меня предложений пока нет - пишутся

Михаил Новокрещенов комментирует...

Буду краток - дельно..

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

Алексей, а вы разве предложения в рамках закрытой группы не подавали?

Кстати интересно было бы услышать про внутреннюю кухну. Как проходил краудсорсинг. что улучшить в организации разработки можно было?
Почему не использовали какое-то приложение для совместной работы над документом? Чтобы в нем отражались изменения сделанные каждым участником. Были ли голосования за правки?

Михаил: Ты что-нибудь напишешь?

Михаил Новокрещенов комментирует...

Сумасшедший аврал, в таких условиях сконцентрироваться для серьезной аналитики просто не смогу

Andrey Prozorov комментирует...

Сергей, вот немного про разработку:
- кто (какие эксперты или организации) разрабатывал данный документ? Были приглашены все эксперты (8), которые принимали участие в обсуждении и правках Приказа 21. Однако, большинство из нас практически не принимали участия, не приходили на совещания. Например, я посетил только треть встреч, замечания прислал лишь по 2\3 мер. Совещаний было много, очень трудозатратно. Да и общего количества экспертов было более, чем достаточно, т.к. также были приглашены эксперты рядка компаний интеграторов, вендоров, и крупного бизнеса. В основном активная позиция была именно у интеграторов и вендоров, больше всех предложений и замечаний, активное обсуждение. Обычно на встречах было ~30 человек. Не думаю, что очень эффективно, но достаточно продуктивно.

- как осуществлялся отбор лиц для участия в разработке документа?
Некоторым экспертам, например мне, ФСТЭК присылал приглашения по эл.почте напрямую. Многим компаниям были высланы официальные приглашения принять участие, но т.к. высылали в бумажном виде, то письмо, например, в нашу компанию пришло с большим запозданием (прошло уже 2 совещания).

- на какой основе эти лица участвовали в разработке? Платно или бесплатно? Если платно, то по какому конкурсу, тендеру?

Участвовали бесплатно, на добровольной основе.