19.12.2011

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

Во время недавней поездки в США мне довелось поучаствовать в дискуссии на тему использования коммерческих продуктов по ИБ (для них обычно используется аббревиатура 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, как пример такого мероприятия).

2 коммент.:

Евгений Родыгин комментирует...

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

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

Спасибо