Об анализе кода я писал не раз и даже спрогнозировал в конце прошлого года, что тема эта поднимется с колен и начнет свое победное шествие по миру. И дело даже не в том, что по другому очень сложно бороться с НДВ, которое так необдуманно было вставлено в ПП-1119, а в том, что этого требует современное состояние защищенности многих корпоративных приложений.
Ведь не секрет, что абсолютное большинство атак реализуется уже не на сетевом, а на прикладном уровне. Еще в середине 2000-х я выступал с презентациями, в которых приводилась цифра 75% - именно такое количество атак фиксируется на прикладном уровне. Традиционные межсетевые экраны и системы предотвращения вторжений слабо помогают решать эту задачу. Нужные совершенно новые идеи. И одной из них является как раз анализ кода. Когда мы обсуждали , как может реализовываться задача борьбы с НДВ в документах ФСТЭК или ФСБ, то набросали несколько вариантов:
С нового года в США вступил в силу закон под названием " 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:
В случае с NIST SP800-53 анализу подвергается не каждая приобретаемая система, а только некоторые из них, что зависит от класса государственной информационной системы и актуальных угроз.
К чему я это все пишу? Не для регуляторов - они рано или поздно придут к тому же, к чему пришел американские институт стандартов или МинОбороны. И не для вендров - западные и так проводят все эти работы, а отечественных врядли что-то заставит тратить дополнительные ресурсы на неочевидные вещи. Пишу я для потребителей, которые должны задуматься об анализе кода приобретаемых или самописных приложений. Либо с точки зрения регуляторики (уже к концу года стоит ждать документов от Банка России), либо с точки зрения выгоды . Спустить на тормозах эту тему уже не удастся...
Ведь не секрет, что абсолютное большинство атак реализуется уже не на сетевом, а на прикладном уровне. Еще в середине 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:
- средства анализа кода
- анализ уязвимостей и угроз
- независимая оценка плана анализа защищенности
- ручной анализ кода
- пентесты
- моделирование угроз
- проверка области тестирования/анализа.
В случае с NIST SP800-53 анализу подвергается не каждая приобретаемая система, а только некоторые из них, что зависит от класса государственной информационной системы и актуальных угроз.
К чему я это все пишу? Не для регуляторов - они рано или поздно придут к тому же, к чему пришел американские институт стандартов или МинОбороны. И не для вендров - западные и так проводят все эти работы, а отечественных врядли что-то заставит тратить дополнительные ресурсы на неочевидные вещи. Пишу я для потребителей, которые должны задуматься об анализе кода приобретаемых или самописных приложений. Либо с точки зрения регуляторики (уже к концу года стоит ждать документов от Банка России), либо с точки зрения выгоды . Спустить на тормозах эту тему уже не удастся...
