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

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

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

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

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

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

  • Инструментальные средства анализа кода (не только исходного, но и исполняемого). Именно сюда попадают различные продукты класса SAST/DAST/фаззеры и т.п.
  • Анализ уязвимостей и угроз. Тут все понятно — сканеры защищенности, работающие в режиме black box, grey box или white box.
  • «Ручной» анализ кода.
  • Пентесты.
  • Моделирование угроз. Тут пример может быть таким. Собственная разработка и с разработчиками ведется организационная работа, снижающая вероятность внесения НДВ в код ПО. Или ПО написано на таком старом языке, что никто и не помнит, как им пользоваться и как внести закладки (вспомните, историю с шифровальщиками из индейцев навахо во время второй мировой войны).
  • Проверка области тестирования/анализа.
  • Симуляция /эмуляция.

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

Оцените статью
Бизнес без опасности
Есть что добавить? Добавьте!

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

  1. Сергей

    А какая разница между доверием к производителю и доверием к испытательной лаборатории(органу по сертификации)? В РБК сегодня увидел интересную статью про Росаккредитацию — количество "липовых" сертификатов поражает.

    Ответить
  2. Алексей Лукацкий

    Никакой — по жизни. Все лажают

    Ответить
  3. Tomas

    Алексей, вы с грифами разными по ГТ работали (секретно, сов.секретно, особой важности)?
    Они все защищаются одними и теми же средствами по большей части, разница в настройках, в дальности ПЭМИН и т.д. Пришли иностранные производители 9с хорошими нароботками) и вытесняют тех, кто годами делал поделки для ГТ с рынка для конф., а еще и "утечку мозгов" организовали. Надо же хоть как-то и своих производителей подтягивать 9хотябы для ГТ) — вот НДВ это прямой способ узнать как что сделано у иностранцев))) Кроме того, банковская тайна о счете какого-нибудь политика может спровоцировать революционные настроения, а это плавно перетекает в национальную безопасноть… А информация о состоянии здоровья Фиделя Кастро, например…
    Разное все и ПДн и налоговая и банковская тайна.
    Согласен, подход надо менять. Самая действенная на мой взгляд, мера — деньги. Например страхование ответственности производителя ПО (он тогда сам будет SDLC применять).

    Ответить
  4. Анонимный

    Остапа понесло…

    1. "устаревшего подхода к поиску недокументированных возможностей, как к единственному методу проверки не только функциональности средства защиты, но и защищенности его самого"

    — Это никак не единственный метод! Тот же РД СВТ предполагает тестирование, включающее "перехват явных и скрытых запросов на доступ, правильное распознавание санкционированных и несанкционированных запросов, средства защиты механизма разграничения доступа, санкционированные изменения ПРД"

    2. Да, про SDLC пока намек, но во что он выльется пока не ясно, но это и намек на парадигму ответственности Разработчика! А это новость!

    3. Применение тестов на проникновение — скорее косвенная мера относящаяся к системе в целом. Может потянуть за собой комплекс компенсирующих мер, что так же интересно.

    4. вот следующую цитату я вообще не понял… для кого малореальная для кого возможная, для кого то невозможная… запутываешь ?

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

    5. "зачем тратить колоссальные средства на проверку исходников ПО или железа"

    — при чем тут железо ?

    6. Ты как то ведешь к мысли что уязвимости, недостатки и т.п. искать не надо? Странно…

    7. "Может пора пересмотреть подход? Я бы предложил сначала четко очертить круг организаций.."
    — очень странно ты предлагаешь поменять подход! Не сфера а организации…

    8. "Ну не является поиск НДВ (даже в средствах защиты) актуальной мерой нейтрализации угроз для данного вида информации ограниченного доступа"
    — если угрозы наличия дырки в СрЗИ (есть в ней обход) не является актуальной — то пожалуй не нужно вообще использовать средства защиты!

    9. Теперь по "американского Минобороны и NIST"
    9.1 "Инструментальные средства анализа кода" — применяются при НДВ да еще и сертифицированные!
    9.2 "Анализ уязвимостей и угроз" — применяются!
    9.3 ""Ручной" анализ кода" — применяется!
    9.4. "Пентесты" — применяй нехочу! Хочешь сделать обязательным?
    9.5 "Моделирование угроз" — см. РД и Гарантии проектирования!
    9.6 "Проверка области тестирования/анализа" — смотри РД!
    9.7. "Симуляция /эмуляция" — так же применяется, и в тех же случаях!

    10. "Наверное, можно придумать и что-то иное для замены не всегда нужной оценки соответствия на отсутствие НДВ."
    — смотри в комплексе… все есть! Кроме НДВ полно проверок которые ты сейчас размазал в направление НДВ!

    11. "Тогда и задача оценки качества ПО будет решена"

    — не нужно путать качество ПО и безопасность ПО!

    Ответить
  5. Анонимный

    Конечно, оператор не может самостоятельно разрулить вопрос с НДВ. Я предлагаю рассматривать этот вопрос в таком ключе: http://kaskadsecurity.blogspot.ru/2013/02/1119.html

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

    Ответить
  6. Анонимный

    И конечно нужно помнить что НДВ: Функциональные возможности ПО, не описанные или не соответствующие описанным в документации, при использовании которых возможно нарушение конфиденциальности, доступности или целостности обрабатываемой информации.

    Иными словами угроза того, что разработчик сокрыл от потребителя(архитектора СЗИ) функциональные возможности, архитектор СЗИ их не учел и целевая система ку ку…

    Ответить