А где установлена обязанность проводить анализ качества кода?

А где установлена обязанность проводить анализ качества кода?
Анализ качества кода на Уральском форуме в Магнитогорске стал одной из самых актуальных тем - ему было посвящено целых 3 доклада и отдельные высказывания представителей ГУБиЗИ и ДРР Банка России. С точки зрения здравого смысла очевидно, что анализировать качество кода нужно. Это повышает стабильность, надежность и защищенность готового продукта. Но является ли это обязательным требованием или всего лишь пожеланием со стороны экспертов?

Как это ни странно, но это является требованием не в одном, и даже не в двух нормативных актах. Начнем с СТО БР ИББС 1.0 от 2010-го года. Раздел 7.3.5 гласит буквально следующее: "Также документация на разрабатываемые АБС или приобретаемые готовые АБС и их компоненты должна содержать описание реализованных защитных мер, предпринятых разработ чиком относительно безопасности разработки и безопасности поставки". Иными словами разработчик должен вести безопасную разработку и должен написать про это в документации на поставляемую АБС. Интересно, кто-то когда-то проверял наличие такого раздела в документации на приобретаемые АБС?

А еще у нас есть PCI DSS с его разделами 6.3, 6.5 и 6.6, посвященными как раз качеству кода, безопасной разработке и регулярному тестированию ПО на предмет требований стандарта PCI DSS и других лучших практик. И конечно же стандарт PA DSS, полностью посвященный вопросам разработки платежных приложений; особенно раздел 5. В отличие от СТО БР ИББС стандарты PCI DSS и PA DSS носят обязательный, а не рекомендательный характер.

Но это не все, что ожидает банковские организации и разработчиков платежных приложений в отношении обязательств по анализу качества кода. Вспомним Уральский форум. Заместитель начальника ГУБиЗИ Артем Михайлович Сычев поделился планами по развитию СТО БР ИББС, в числе которых разработка нового документа "Требования к банковским приложениям и разработчикам банковских приложений". Можно предположить, что данный документ включит в себя базовый набор требований к функциональности и процессу разработки платежных приложений, применяемых в российских финансовых организаций. Аналогичные планы есть и у Департамента регулирования расчетов - их озвучил заместитель директора ДРР Андрей Петрович Курило. Правда, ДРР идет чуть дальше ГУБиЗИ и предлагает не только установить требования к разработчикам платежных и финансовых приложений, используемых в рамках Национальной платежной системы, но и проводить оценку их соответствия (возможно, сертификацию) указанным требованиям.

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

Выглядеть фрагмент приказа мог бы так: "В случае определения в соответствии с Требованиями к защите персональных при их обработке в информационных системах персональных данных, утвержденными постановлением Правительства Российской Федерации от 1 ноября 2012 г. № 1119, в качестве актуальных угроз безопасности персональных данных 1-го и 2-го типов дополнительно к мерам по обеспечению персональных данных могут применяться следующие меры: 
  • проверка кода системного и (или) прикладного программного обеспечения на отсутствие недекларированных возможностей с использованием автоматизированных средств (автоматизированная проверка кода);
  • проверка кода системного и (или) прикладного программного обеспечения на отсутствие недекларированных возможностей без использования автоматизированных средств (ручная проверка кода);
  • тестирование информационной системы на проникновения (пинтесты);
  • использование в информационной системе системного и (или) прикладного программного обеспечения, разработанного с использованием методов защищенного программирования". 
Так что тема, которая совсем недавно была уделом немногих продвинутых компаний, задумывающихся о безопасности заказных или своих самописных приложений, может вскоре стать очередным драйвером  развития российского рынка информационной безопасности. И игроки тут уже свои тоже появляются, например, Appercut Security или Positive Technologies . Есть свои фанаты этой тематики, ведущие специализированные блоги, например, Женя Родыгин . Готовятся мероприятия, посвященные анализу кода. Например, этой теме будет посвящена отдельная секция на РусКрипто 2013 .

Так что готовтесь, коллеги...
SDLC оценка соответствия PCI DSS Банк России
Alt text

Мы рассказываем о самых актуальных угрозах и событиях, которые оказывают влияние на обороноспособность стран, бизнес глобальных корпораций и безопасность пользователей по всему миру в нашем Yotube выпуске.