Если вам есть, что сказать сообществу профессионалов ИБ и ИТ – заведите здесь свой блог

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

Аватар пользователя alukatsk
Автор: Лукацкий Алексей,
(0)
()
Опубликовано в:
Анализ качества кода на Уральском форуме в Магнитогорске стал одной из самых актуальных тем - ему было посвящено целых 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.

Так что готовтесь, коллеги...
Оцените материал:
Total votes: 45
 
Комментарии в Facebook
 

Вы сообщаете об ошибке в следующем тексте:
Нажмите кнопку «Сообщить об ошибке», чтобы отправить сообщение. Вы также можете добавить комментарий.