НДВ, SDLC, fuzzing и всякое такое

Нахожусь я сейчас на ежегодной конференции Cisco SecCon 2012, которая как и всегда посвящена совершенно различным аспектам обеспечения информационной безопасности. О прошлогодней конференции я уже писал; теперь обращусь к тому, что говорилось на этой (в первый день).Тон задала Reeny Sondhi (фиг знает, как индийские имена переводятся на русский), директор по качеству безопасности продуктов EMC.

Она рассказывала о проблемах с качеством безопасности (не знаю как нормально на русский перевести security assurance) в современных ИТ-продуктах. Привела достаточно интересную модель зрелости процесса оценки качества ИБ, и место ИТ-лидеров современности на ней. Большинство игроков (Cisco, EMC, Microsoft и другие) уже давно находятся на 3-м уровне, постепенно сдвигаясь к 4-му уровню (всего уровней пять). Если вкратце, то уровни следующие:

1. Выставление требований по безопасности к разрабатываемому продукту при почти полном отсутствии контроля реализации (включая и качество) этих требований.
2. Базовая оценка качества в виде различных процедур Quality Assurance; в первую очередь базовый анализ исполняемого кода пост-фактум.
3. Внедрение SDLC и практик code review в разработку ПО. Собственно этому уровню и был посвящен первый день конференции. Докладчики из различных подразделений Cisco, EMC, Microsoft и других компаний делились своим опытом внедрения SDLC, анализа кода, устранения проблем и т.д.
4. Учет рисков supply chain management. В первую очередь это касается производителей "железа", которые осуществляют сборку или получают запчасти для своих заводов преимущественно из Китая. Последние публичные и не очень скандалы с китайскими закладками в сетевом оборудовании, в процессорах и т.д. очень серьезно обостряют проблему. И если сама проблема не нова, то только сейчас она вышла на такой уровень, что необходимо ее как-то регулировать.
5. Высший уровень (по версии EMC) правильно выстроенного процесса повышения качества ПО с точки зрения безопасности - передача его внешним организациям для тестирования. Но именно как независимая оценка того, что уже правильно было разработано (SDLC) и проверялось самим разработчиком (code review). Просто передача кода для анализа в специалилизрованные компании (завтра будет выступать, например,  Coverity) - это не совсем то, что директор направления EMC относит к 5-му уровню модели зрелости. В России такие решения тоже появляются, что не может не радовать.

И вот тут опять стоит сравнить то, что делается на Западе с тем, что делается в России. Особенно в контексте ПП-1119 и появления в нем темы с угрозами НДВ. Собственно недекларированные возможности могут быть, на мой взгляд, случайными (уязвимости) или целенаправленными (закладками). Возникает вопрос - как с ними бороться? Планируемые документы регуляторов на этот вопрос, к сожалению, не отвечают. Хотя варианты предлагались им различные.

Но это потребует от регуляторов смены всей парадигмы регулирования ИБ и переход от реактивного подхода, заключающегося в требовании реагирования на инциденты, в сторону проактивного, когда мы устраняем саму причину возникновения и развития инцидента. И речь не о идее навесной системы защиты, которую так активно двигают ФСТЭК и ФСБ, а о рекомендациях внедрения SDLC всеми разработчиками российских средств защиты и, возможно, разработчиками иного ПО. Безопасность должна быть интегрированной, а не наложенной. Но это потребует от регуляторов смены парадигмы - необходимо менять акцент и более глубоко копать тему SDLC, code review, agile-разработка и т.д. Совершенно иные компетенции, иные знания, иная квалификация. Но без этого никуда. Чем дальше, тем сложнее будет бороться с новыми угрозами, 0Day-уязвимостями, APT и т.д. Особенно в условиях неразвитости отечественного рынка средств защиты.

Но и не одни только регуляторы должны что-то делать. Движение должно идти с двух сторон. Cами разработчики (и СЗИ и другого ПО), которые должны для себя понять, что внедрение SDLC выгоднее, чем устранение последствий от выявленных уязвимостей или закладок. Правда, пока, и это надо признать, это не более чем разговоры. В России пока невыгодно заниматься этими вопросами. Ведь никто никакой ответственности не несет. Разработчик продает свой софт "as is". Испытательная лаборатория не гарантирует качества своей работы. Орган по сертификации тоже не несет ответственности за выданные им сертификаты соответствия.

Достаточно вспомнить недавний случай с одним из отечественных VPN-продуктов. Через 2 дня после появления пресс-релиза о получении VPN-продуктом очередного сертификата ФСБ на одном из хакерских форумов появляется сообщение о взломе данного продукта. И ничего... Все спущено было на тормозах. Вполне допускаю, что разработчик устранил источник проблемы. Но никакой ответственности он не понес. Сертификат никто не отозвал. Регулятор может и вообще не в курсе, что в Интернете ходят рекомендации по способам обхода сертифицированной СКЗИ.

Понятия "репутация" у нас пока тоже в среде разработчиков не сильно популярно. В условиях отсутствия серьезной конкуренции на рынке и выборе продуктов по наличию бумажки, а не реального функционала, никто сильно заморачиваться не будет. Ну или почти никто. Компании, смотрящие на Запад, вполне могут задуматься об этом, но это пока единицы. Действия (или точнее бездействия) регуляторов только способствуют продолжению нахождения российского рынка ИБ в такой ситуации. До первого серьезного (очень серьезного) инцидента... Или до смены поколения-двух в наших регуляторах. Первое, с учетом скорости развития технологий, не за горами. Второе... Я не доживу, наверное. Остается надеяться на здравый смысл регуляторов и разработчиков и появления у них желания сдвинуться с удобного тепленького местечка и начать более активно заниматься тем, чем на Западе занимаются уже несколько лет.