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

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