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

Об анализе кода я писал не раз и даже спрогнозировал в конце прошлого года, что тема эта поднимется с колен и начнет свое победное шествие по миру. И дело даже не в том, что по другому очень сложно бороться с НДВ, которое так необдуманно было вставлено в ПП-1119, а в том, что этого требует современное состояние защищенности многих корпоративных приложений.

Ведь не секрет, что абсолютное большинство атак реализуется уже не на сетевом, а на прикладном уровне. Еще в середине 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 анализу подвергается не каждая приобретаемая система, а только некоторые из них, что зависит от класса государственной информационной системы и актуальных угроз.

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