Пора менять подходы к нейтрализации угрозы НДВ

Аватар пользователя alukatsk
Автор: Лукацкий Алексей,
(0)
()

Недавно я писал про недекларированные возможности. Заметка была связана со сложностями в проведении оценки отсутствия недекларированных возможностей для продукции американского происхождения. До этого были и еще записи (тут, тут и тут). На мой взгляд, сейчас назрела необходимость пересмотра этого устаревшего подхода к поиску недокументированных возможностей, как к единственному методу проверки не только функциональности средства защиты, но и защищенности его самого. Частично, этот шаг уже сделан ФСТЭК в 21-м приказе, в котором для актуальных угроз 1-го и 2-го типов (НДВ на системном и прикладном уровне соответственно), предусмотрена не только оценка отсутствия НДВ, как одного из способов нейтрализации угроз 1-го и 2-го типов, но и также:

  • внедрение разработчиками методов защищенного программирования (SDLC)

  • применение тестов на проникновение.



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

Пока "только НДВ" у нас остается для области гостайны и средств защиты информации при определенных классах и уровнях защищенности по 21-му и 17-му приказам ФСТЭК. Да и по линии ФСБ это вещь обязательная. Но как уже было показано ранее, предоставление исходников, без которых провести сертификацию на отсутствие НДВ даже для 4-го класса, задача малореальная для многих разработчиков. Тупик? Пока да.

С другой стороны, поиск недекларированных возможностей и не везде нужен. Ну гостайна ладно. А ПДн? А конфиденциалка в госорганах? Там зачем тратить колоссальные средства на проверку исходников ПО или железа, если угроза явно неактуальна или несопоставима с затратами в поиск НДВ?

Может пора пересмотреть подход? Я бы предложил сначала четко очертить круг организаций, на которых распространяется требование поиска НДВ и, в частности, убрал бы оттуда тему персданных вовсе. Ну не является поиск НДВ (даже в средствах защиты) актуальной мерой нейтрализации угроз для данного вида информации ограниченного доступа. И для банковской тайны тоже. И для налоговой, аудиторской и шести десятков иных тайн тоже. Есть более дешевые и не менее эффективные для данной задачи варианты. И вот тут я бы вспомнил документы американского Минобороны и NIST, о которых уже писал. В них прописано, что для повышения качества кода (с точки зрения его защищенности, надежности, живучести и т.п.), необходимо использовать разные (на выбор заказчика) механизмы:

  • Инструментальные средства анализа кода (не только исходного, но и исполняемого). Именно сюда попадают различные продукты класса SAST/DAST/фаззеры и т.п.

  • Анализ уязвимостей и угроз. Тут все понятно - сканеры защищенности, работающие в режиме black box, grey box или white box.

  • "Ручной" анализ кода.

  • Пентесты.

  • Моделирование угроз. Тут пример может быть таким. Собственная разработка и с разработчиками ведется организационная работа, снижающая вероятность внесения НДВ в код ПО. Или ПО написано на таком старом языке, что никто и не помнит, как им пользоваться и как внести закладки (вспомните, историю с шифровальщиками из индейцев навахо во время второй мировой войны).

  • Проверка области тестирования/анализа.

  • Симуляция /эмуляция.



Наверное, можно придумать и что-то иное для замены не всегда нужной оценки соответствия на отсутствие НДВ. Главное, не стоять на месте и двинуться вперед, предложив потребителю несколько альтернатив и подготовив соответствующую методологическую базу для каждого из предложенных выше вариантов. Тогда и задача оценки качества ПО будет решена и затраты будут более адекватными рискам и претензий со стороны рынка в сторону регуляторов будет меньше.


 
Комментарии в Facebook
 

Вы сообщаете об ошибке в следующем тексте:
Нажмите кнопку «Сообщить об ошибке», чтобы отправить сообщение. Вы также можете добавить комментарий.