Контроль качества ПО с точки зрения ИБ становится обязаловкой?!

Ведь не секрет, что абсолютное большинство атак реализуется уже не на сетевом, а на прикладном уровне. Еще в середине 2000-х я выступал с презентациями, в которых приводилась цифра 75% — именно такое количество атак фиксируется на прикладном уровне. Традиционные межсетевые экраны и системы предотвращения вторжений слабо помогают решать эту задачу. Нужные совершенно новые идеи. И одной из них является как раз анализ кода. Когда мы обсуждали, как может реализовываться задача борьбы с НДВ в документах ФСТЭК или ФСБ, то набросали несколько вариантов:

• внедрение приемов «защищенного» программирования (SDLC)
• проверка кода на предмет НДВ с помощью автоматизированных
  инструментов (например, Appercut Security)
• ручная проверка кода на предмет НДВ с помощью специализированных
  компаний (например, Positive Technologies и т.п.) или в рамках
  сертификационных испытаний ФСТЭК/ФСБ/МО
• услуги по анализу защищенности приложений и операционных систем, включая пентесты
• доверенная аппаратная платформа с функциями защиты от НДВ на системном и прикладном уровне
• страхование соответствующих информационных рисков.

Но ни одна из этих идей не прошла (для ФСТЭК времени было мало, а мотивация ФСБ так и осталась для меня загадкой при выборе ими защитных мер от НДВ системного или прикладного уровня), но регуляторы задумались. Об этом задумалась ФСТЭК. Об этом задумался Банк России, который планирует в этом году разработать отдельный документ с требованиями к банковским приложениям (на Инфофоруме в начале недели вообще прозвучала идея об отдельной сертификации финансовых приложений). Уникальны ли мы в этом вопросе? Нет!

С нового года в США вступил в силу закон под названием «Defense National Defense Authorization Act of 2013«, который устанавливает определенные требования к продукции, поставляемой по оборонному заказу. Среди прочего (к слову сказать, закон занимает 681 страницу А4) есть там и раздел 933 «IMPROVEMENTS IN ASSURANCE OF COMPUTER SOFTWARE
PROCURED BY THE DEPARTMENT OF DEFENSE», в котором говорится об обязательном контроле качестве ПО, приобретаемом Министерством Обороны. Достигается эта задача применением автоматизированных сканеров безопасности, тестированием, анализом кода и т.д. При этом действует это требование не для всех систем, приобретаемых американским МинОбороны (слишком уж накладно было бы), а только для определенных категорий — т.н. основных, систем, связанных с национальной безопасностью, и систем категории I по классификации МинОбороны США.

Но не только американская военщина озабочено анализом кода. 5-го февраля NIST опубликовал 4-ю версию своего документа SP800-53 «Security and Privacy Control for Federal Information Systems and Organizations», содержащего полный перечень мер для защиты государственных информационных систем США. Из этого перечня в зависимости от класса информационной системы с помощью SP800-60 и выбираются нужные механизмы обеспечения ИБ. Среди прочего есть там группа мер под названием «Systems and Service Acquisition», т.е. что делать при приобретении систем или услуг. А внутри группы SA есть блок SA-11 «Developer Security Testing and Evaluation», который появился только в 4-й редакции и содержит, собственно, меры по анализу качества приобретаемого ПО. Таких мер 7:

• средства анализа кода
• анализ уязвимостей и угроз
• независимая оценка плана анализа защищенности
• ручной анализ кода
• пентесты
• моделирование угроз
• проверка области тестирования/анализа.

Еще один новый блок связан с угрозами в цепочке поставок. Это SA-12 и в нем тоже присутствуют тематика анализа кода. Вы уверены, что в приобретенном вами коде нет случайных или намеренных закладок? Чтобы ответить на этот вопрос и нужны меры из SA-12, в частности оценка ДО выбора системы, ДО ее использования и ДО ее обновления. А среди инструментов такой оценки NIST предлагает статический и динамический анализ, симуляцию, тестирование в режиме «белого»/»серого»/»черного» ящика, пентесты, fuzz testing, криптографические хэши и т.д.

В случае с NIST SP800-53 анализу подвергается не каждая приобретаемая система, а только некоторые из них, что зависит от класса государственной информационной системы и актуальных угроз.

К чему я это все пишу? Не для регуляторов — они рано или поздно придут к тому же, к чему пришел американские институт стандартов или МинОбороны. И не для вендров — западные и так проводят все эти работы, а отечественных врядли что-то заставит тратить дополнительные ресурсы на неочевидные вещи. Пишу я для потребителей, которые должны задуматься об анализе кода приобретаемых или самописных приложений. Либо с точки зрения регуляторики (уже к концу года стоит ждать документов от Банка России), либо с точки зрения выгоды. Спустить на тормозах эту тему уже не удастся…