Как построить доверенную систему из недоверенных элементов?

Во время недавней поездки в США мне довелось поучаствовать в дискуссии на тему использования коммерческих продуктов по ИБ (для них обычно используется аббревиатура COTS — commercial of-the-shelf) в критичных приложениях и системах. Сейчас это достаточно распространенная тенденция в США, которые во многих случаях отказываются от применения специально разработанных приложений в пользу того, что доступно на рынке. Я спросил коллег, что они делают в таких случаях? Ведь исходных кодов зачастую нет; свидетельств грамотно выстроенного процесса разработки тоже. Да и вообще проверить, как разрабатывается приложение зачастую невозможно, т.к. эта деятельность осуществляется за пределами США и переносить разработку внутрь страны производитель не планируют по причине отсутствия серьезного бизнес-кейса. Во ФСТЭК бы сказали, что сертифицировать такую продукцию, как и обеспечить ее инспекционный контроль невозможно. Знакомая ситуация, не правда ли?

Ответ был прост — мы используем подход V-RATE (Vendor Risk Assessment and Threat Evaluation), предложенный еще в конце 90-х — начале 2000-х Институтом Карнеги-Меллона. Идея метода проста — компенсировать отсутствие исходных кодов и доказательств процесса разработки анализом рисков для самого производителя. На выходе мы получаем профиль рисков, состоящий из нескольких областей, в каждой из которых могут быть предусмотрены те или иные меры по снижению неудовлетворительного уровня проанализированных рисков.

В рамках V-RATE профиль рисков делится на две части:

  1. Элементы рисков, присущих производителю
  2. Элементы рисков, связанные с вашими навыками управления рисками при работе с производителями.

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

  1.  Элементы рисков, присущих производителю
    •  Видимость
      • Открытость — насколько открыт и доступен процесс дизайна и разработки продукта ?
      • Независимость испытательных лабораторий, оценивающих продукт (имеет значение, например, при использовании решений, сертифицированных по «Общим критериям»)
    • Техническая компетенция 
      • История сертификаций продукции
      • Свидетельство приверженности стандартам и требованиям регуляторов
      • Разнообразие продуктов и услуг разработчика
      • Наличие отдельной команды, отвечающей за безопасность и надежность
    • Соответствие
      • Реагирование на запросы со стороны пользователей в части безопасности и надежности
      • Реагирование на запросы новых функций и улучшений
      • Готовность к сотрудничеству со сторонними испытательными и сертификационными лабораториями
    • Репутация
    • Уровень менеджмента
      • Финансовая стабильность
      • Условия работы с поставщиками и контрагентами
  2. Элементы рисков, связанные с вашими навыками управления рисками при работе с производителями
    • Ваша квалификация в области оценки качества продукта по различным показателям (безопасность, надежность и т.д.)
    • Ваша квалификация в области оценки компетенции производителя (по идее испытатель должен быть квалифицированнее испытуемого)
    • Ваше понимание существующих сертификаций и рейтингов производителя
    • Ваша независимость
    • Ваши навыки ведения переговоров

Пример раздела «Соответствие» профиля V-RATE:

  • патчи выпускаютсямаксимально быстро после обнаружения ошибки или уязвимости
  • пользователь может отключить ненужные функции, тем самым снизив риски от их использования
  • встроенные механизмы восстановления, например, автоматическое резервирование конфигурационных данных и восстановление состояния соединений
  • встроенные механизмы защиты, например, шифрование канала управление и защита паролей
  • следование практике SDLC и обучение разработчиков производителя вопросам безопасности и защищенного программирования (Cisco SecCon, как пример такого мероприятия).
Оцените статью
Бизнес без опасности
Есть что добавить? Добавьте!

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

  1. Анонимный

    мерси хороший материал…

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

    Спасибо

    Ответить