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

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

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

Оцените статью
Бизнес без опасности
Есть что добавить? Добавьте!

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

  1. Алексей Т.

    Спасибо, еще и для того, чтобы уже сейчас попытаться исключить или хотя бы определиться с угрозами недокументированных возможностей в системном или прикладном ПО — рынок не может ждать документов регуляторов, надо работать и выбирать наконец уровень защищенности. 🙂

    Ответить