В западных стандартах и учебниках написано,  что безопасность программного обеспечения невозможна без Code Review. А что это такое? Исследование? Анализ? Обзор? Эстрадное представление? Наконец-то есть ответ русским языком коротко и ясно – в Рекомендациях Банка России РС БР ИББС-2.6-2014. С разрешения Банка России BIS Journal перепечатывает Приложение 2 Рекомендаций в области стандартизации Банка России  «РС БР ИББС-2.6-2014 Обеспечение информационной безопасности на этапах жизненного цикла автоматизированных банковских систем». Адрес полного текста Рекомендаций на сайте Банка России:  http://www.cbr.ru/credit/Gubzi_docs/rs-26-14.pdf.

 

РС БР ИББС-2.6-2014, Приложение 2.
Рекомендации к проведению контроля исходного кода

1. ОБЩИЕ ПОЛОЖЕНИЯ

1.1. Контроль кода (code review) – мероприятия, осуществляемые в отношении определенных частей исходного текста (исходного кода) программы для ЭВМ, созданных одним или несколькими разработчиками, другим (не создававшим эту часть кодов) разработчиком или назначенным в установленном порядке иным имеющим требуемую подготовку специалистом, и которые состоят в детальной проверке (изучении, анализе, исследовании) соответствующих исходных кодов с целью выявления неизвестных уязвимостей, в том числе связанных с ошибками программирования, нарушений установленных требований, а также иных существенных дефектов.

1.2. Объектом исследования являются тексты программ разрабатываемых компонентов АБС, в первую очередь тексты программ специализированных банковских приложений.

1.3. Контроль кода может в обоснованных случаях проводиться несколькими лицами, в том числе при участии создавшего и (или) модифицировавшего проверяемый код разработчика.

1.4. Контроль кода может осуществляться лицом, проверяющим код, как вручную, в том числе с использованием приемов эффективного чтения программного кода (code reading), так и с применением методов и средств автоматизированного анализа исходного кода, в том числе обеспечивающих:

• статический анализ кода;
• динамический анализ кода.

2. КОНТРОЛЬ КОДА ВРУЧНУЮ

2.1. Контроль (проверка) исходного кода вручную обеспечивается просмотром, изучением и оценкой кода лицом, отличным от его разработчика. Оценка кода может включать в себя:

• оценку соответствия кода требованиям, предъявляемым к структурированию и оформлению кода, именованию объектов, разделению на модули, использованию специальных средств обеспечения качества кода, предусмотренных используемыми языками программирования и средствами разработки;
• оценку полноты и качества документирования кода, включая документирование заголовков программных модулей, прототипов функций и структур данных, комментарии к выполнению существенных операций;
• оценку соответствия алгоритмов, реализованных в исходном коде, программной документации, в том числе выявление явных недекларированных возможностей (программных закладок), ошибок программного кода, попыток запутывания (обфускации) программного кода и использования иных приемов, затрудняющих проведение контроля.

2.2. Методы эффективного чтения кода включают двойное чтение (сначала понять общую структуру, запомнить основные обозначения и соглашения, затем читать снова, выявляя дефекты, несоответствия), использование сценариев и др.

2.3. Помимо приемов индивидуальной проверки кода, существуют методы эффективной организации взаимодействия участников контроля кода, в том числе прослеживания (walkthrough), инспекции кода (code inspections) и др. Они являются достаточно ресурсоемкими и для их применения нужны соответствующие навыки, но при рациональном использовании они могут быть весьма эффективны в случаях, требующих особого внимания.

3. СТАТИЧЕСКИЙ АНАЛИЗ КОДА

3.1. Статический анализ кода (static program analysis) проводится с использованием автоматизированных средств (программных инструментов) и направлен на идентификацию потенциально опасных фрагментов кода, в том числе:

• вызовов функций, методов, процедур (далее – функции) с передачей им в качестве аргументов данных, вводимых пользователем или принимаемых из внешних источников;
• текстов функций преобразования форматов данных;
• вызовов системных функций и функций обеспечения ИБ разделяемых обеспечивающих компонентов АБС, в том числе функций обеспечения ИБ операционной системы и специализированных технических защитных мер, функций ввода/вывода, управления памятью и системными ресурсами;
• текстов функций, осуществляющих проверку прав доступа и принятие решений, основанных на значениях атрибутов безопасности;
• текстов функций, самостоятельно реализующих функциональность обеспечения ИБ, в том числе криптографические функции, аутентификацию пользователей и проверку прав доступа, генерацию данных мониторинга ИБ;
• текстов функций, предусматривающих установление соединения с внешними компонентами с передачей им аутентификационных данных;
• текстов обработчиков ошибок и исключений.

3.2. В ходе статического анализа кода рекомендуется проводить поиск типовых ошибок программирования (недостаточная проверка входных параметров функций, включение аутентификационных данных непосредственно в текст программ, некорректное преобразование типов, недостаточная обработка ошибок и исключений), а также определяются статические пути исполнения программы.

4. ДИНАМИЧЕСКИЙ АНАЛИЗ КОДА

4.1. Динамический анализ кода осуществляется путем выполнения или эмуляции выполнения программы на определенной совокупности наборов тестовых исходных данных. Перед выполнением или в процессе выполнения программа иногда инструментируется путем дополнения ее функциями трассировки выполнения для задания и контроля инвариантов, предусловий, постусловий и др. Динамический контроль проводится с использованием специализированных автоматизированных средств и может включать в себя, в частности:

• исследование особенностей исполнения потенциально опасных функций при задании заведомо некорректных аргументов;
• построение динамических путей исполнения программы и идентификацию точек принятия решений, существенных для выполнения функций обеспечения ИБ;
• поиск чувствительной информации в оперативной памяти и в аргументах функций;
• исследование особенностей исполнения программы при типовых атаках (переполнение буфера, внедрение операторов SQL в данные, используемые для формирования запросов к СУБД).

5. ДОПОЛНИТЕЛЬНЫЕ ПРАКТИЧЕСКИЕ АСПЕКТЫ КОНТРОЛЯ КОДА

5.1. Вне зависимости от применяемых способов и методов анализа кода при его осуществлении рекомендуется использование классификаторов типовых ошибок программирования, а также способов выявления различных типов ошибок [...].

5.2. Выявленным в рамках контроля кода уязвимостям в коде разрабатываемых компонентов АБС целесообразно присваивать оценку степени их критичности (например, высокая, средняя, низкая) для обеспечения ИБ организации [...]. Для каждой выявленной уязвимости с учетом ее критичности принимается решение о доработке программного компонента АБС (и о приоритетности доработки) или о принятии рисков, связанных с наличием уязвимости.

5.3. Результаты контроля кодов оформляются протоколами контроля кода (название этих документов может быть иным), подписываемыми разработчиками – непосредственными исполнителями разработки проверенного исходного кода и лицами, участвовавшими в его проверке (контролерами кода), с отражением в протоколе сведений о дате мероприятия, проверенной части исходных кодов, выявленных уязвимостях и иных дефектах (при наличии), повторном контроле кодов с подтверждением устранения выявленных уязвимостей, дефектов.

Примечание. Протоколы контроля кода и иные подобные документы целесообразно оформлять в виде информации в электронной форме, созданной, переданной и надежно сохраненной в предусмотренной для данного вида информации (документов) системе электронного документооборота (например, в архиве сообщений электронной почты), с реквизитами (название, уникальный номер, подписи, даты и др.), позволяющими при аудите предъявлять ее в качестве электронного документа (комплекта документов), подписанного простыми электронными подписями, а также при необходимости изготавливать и заверять ее копии на бумажном носителе. (Требование об оформлении протоколов изначально на бумажном носителе или с усиленными электронными подписями может блокировать систематическое выполнение контроля кода.)

5.4. Мероприятия по контролю кода планируются и осуществляются в отношении всего подлежащего контролю измененного или вновь созданного исходного кода с уведомлением и в необходимых случаях при участии представителей службы ИБ в качестве контролеров кода.

 

BIS-КОММЕНТАРИИ

Алексей ЧАПАЕВ,
руководитель группы проектирования и разработки информационных систем ЗАО «Райффайзенбанк»:

− Очевидно, что выполнение Рекомендаций по Контролю кода (CodeReview) «по полной программе» следует применять только для тех компонентов систем, которые имеют высшую категорию с точки зрения обеспечения информационной защищённости. Потому что это существенно удорожит и замедлит производство и сопровождение программного обеспечения (ПО) автоматизированных банковских систем (АБС) в связи с потребностью в дополнительных тестовых и исследовательских стендах, высококвалифицированном персонале, специальном дорогостоящем исследовательском ПО.

Контроль кода, безусловно, обладает положительными качествами и в настоящее время встраивается в производственный процесс и выполняется как минимум чтением и верификацией модифицированного кода перед выпуском релизов. Не только с  прямой целью обеспечения безопасности, но и с такими важными целями как обучение приёмам и стандартам разработки, обмен опытом и распространение «лучших практик», изучение системы большим числом разработчиков, что поднимает значение коэффициента «автобусного фактора» [Bus Factor – «количество разработчиков команды программистов, после "попадания" которых "под автобус" ... проект не может быть дальше продолжен», – из Википедии. Прим. ред.].

 

Сергей ПАЗИЗИН,
заместитель руководителя службы – начальник отдела защиты прикладных задач Управления по обеспечению информационной безопасности
ОАО «Банк ВТБ»:

– В приведённом Приложении к Рекомендациям в области стандартизации Банка России РС БР ИББС-2.6-2014  «Обеспечение информационной безопасности на этапах жизненного цикла автоматизированных банковских систем» коротко и системно изложен современный взгляд на анализ программного  кода, приведена классификация видов такого анализа.

Следует отметить, что в отечественной практике предъявления требований к программному обеспечению имеется определенный дисбаланс между функциональными требованиями и требованиями гарантий выполнения требований. Принятие данных рекомендаций Банком России и, в частности, «Рекомендаций к проведению контроля исходного кода» является существенным шагом к устранению такого дисбаланса.

Вместе с тем, на пути широкого внедрения в банках практики проведения анализа программного кода объективно возникнет ряд существенных проблем, а именно:

1. Потребуются значительные затраты квалифицированного и, как следствие, высокооплачиваемого рабочего времени в связи с огромным объёмом программного кода банковских приложений. Применение средств автоматизации полностью не решит эту проблему из-за неизбежного возникновения при таком анализе ложных срабатываний, разбираться с которыми придётся опять же вручную. Кроме того, стоимость подобных средств автоматизации значительна в связи с необходимостью поддержки разнообразных платформ разработки и постоянного сопровождения и обновления.
2. Неизбежно возникнут сложности, связанные с получением исходного кода от сторонних разработчиков.
3. Необходимость обеспечения эффективного взаимодействия между подразделением (или организацией), проводящим анализ исходного кода, и его разработчиком. Должны быть обеспечены действенные рычаги воздействия по результатам анализа.
4. Возникновение задержек внедрения, что особенно критично в отношении  патчей с исправлениями.

Попытка директивного внедрения процедур анализа кода может привести к более высоким издержкам, чем величина снижения рисков. Что не отменяет эффективность такой процедуры при продуманном выборе области применения и разумной организации  процесса, в частности, при проведении оценок соответствия компаниями –  разработчиками банковского программного обеспечения, а также в ряде областей, имеющих наиболее высокие риски использования злоумышленниками недостатков программного кода.

 

Вячеслав МАКСИМОВ,
заместитель генерального директора по направлению защиты процессов,
компания «Андэк»:

− Я приветствую включение «Рекомендаций к проведению контроля исходного кода» в Комплекс БР ИББС. Пусть документ получился и небольшой (всего две страницы), но он может оказаться крайне полезен очень многим. Выполнение предложенных в Рекомендациях процедур способно снизить многие риски информационной безопасности, возникающие при разработке программного обеспечения.

Кстати, стоит отметить, что хотя Банк России и рекомендовал организациям банковской системы признавать неактуальными угрозы утечки персональных данных, связанные с наличием не декларированных возможностей в прикладном ПО, само существование этих угроз он не отрицает, а предложенные документом меры могут позволить снизить соответствующие риски для прикладного ПО, разрабатываемого банками или для банков. Кроме того, как действующий QSA-аудитор замечу, что Рекомендации не противоречат требованиям, выдвигаемым стандартом PCI DSS к контролю кода, и могут быть использованы компаниями, для которых соответствие этому стандарту необходимо. Замечу также, что процедуры контроля исходного кода не столь чувствительны к отрасли, в которой они применяются. Поэтому я убежден, что этот документ найдет своего пользователя и за рамками сотрудников компаний финансового сектора.

 

Алексей БАБЕНКО,
руководитель направления отдела безопасности банковских систем,
компания «Информзащита»:

– Контроль исходного кода – один из ключевых этапов в наиболее авторитетных и популярных циклах безопасной разработки: Microsoft SDL, Cisco SDL, требования стандартов PCI DSS и PA-DSS. При этом почти неизменно к процессу Code Review предъявляют требования:

• анализ кода должен осуществляться сотрудником, не участвующим в его создании;
• контролер должен обладать достаточным опытом в области безопасного программирования;
• контроль кода должен осуществляться для всех изменений;
• результаты контроля кода необходимо учитывать до выпуска релиза.

Рекомендации Банка России являются отражением лучших практик и в целом повторяют мировой опыт. Следование общемировым стандартам, несомненно, будет способствовать повышению общего уровня информационной безопасности разрабатываемого для банковской сферы программного обеспечения.

В ходе работ по сертификации платёжных приложений мне часто приходилось сталкиваться с неверной трактовкой понятия анализа кода. Например, код контролировался лишь для новых сотрудников, критерии оценки не включали в себя требования по безопасности, а контроль осуществлялся выборочно. Практическое руководство Банка России на русском языке должно внести – и внесет – ясность в понятие контроля исходного кода.

Отдельно хотелось бы отметить автоматизированные средства (АС) анализа. Несмотря на существенный рост специализированного программного обеспечения и повышение качества их работы, АС – всего лишь инструмент в руках специалиста. «Слепое» использование программного продукта, без корректной трактовки результатов и ручных проверок, часто даёт ложное ощущение защищённости. Но при верном использовании данные средства могут стать отличным подспорьем в кропотливой работе специалиста.

Хорошей практикой является внедрение дополнительных автоматизированных средств контроля на этапе сборки итогового релиза. Данные средства не заменяют этап контроля кода, но позволяют контролировать его выполнение. Если простое автоматизированное средство выявило слабости в уже проанализированном коде, велика вероятность того, что контроль был выполнен плохо, либо вообще не выполнялся.

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