Внедряем госстандарты информационной безопасности в продукты: почему, как и зачем?

Банк России в 2020 году выпустил методический документ с требованиями безопасности для разработчиков ПО, касающегося компаний, которые работают с финансовыми операциями. Он получил название «Профиль защиты» и был основан на требованиях национального стандарта РФ 15408-3-2013 «Критерии оценки безопасности информационных технологий». Внутри можно найти большой перечень требований безопасности.

Требования – пункты для выявления соответствий (или несоответствий) в функционале и цикле разработки ПО. Задача в том, чтобы доработать уже существующие нормы безопасности и сделать таким, как требует Банк России. Затем аудиторская проверка решит, действительно ли разработанное ПО отвечает стандартам.

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

Подготовка

Анализ требований из исходного документа;
Распределение требований на составляющие системы (backend приложения, инфраструктурные/серверные сегменты и т.д.);
Составление чек-листа, в котором требования из исходного документа сгруппированы и верхнеуровнево прокомментированы.

Мы сформировали задачи для наших разработчиков и инфраструктуры заказчика, опираясь на чек-лист. В нем все еще были сложные для понимания формулировки, но ясности добавляли пояснительные комментарии, которыми мы дополнили требования в ходе их анализа. Они позволяли понять кому направлять каждую из задач.

Как формировали задачи для разработчиков

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

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

Например, система защиты приложения может быть выставлена на сетевом уровне перед нашим сервисом в инфраструктуре заказчика. Поэтому вносить изменения в нее с нашей стороны мы не можем. При этом требования безопасности «Профиля защиты» к этой системе все равно предъявляются. Мы так же осмысляем их, формулируя задачу, только спускаем ее не на нашу внутреннюю разработку, а в инфраструктуру заказчика. Выглядит это примерно так:

Анализ требований «Профиля защиты» также показал, что для соответствия некоторым из них нужно приложить усилия одновременно на нашей стороне, на стороне разработки и в инфраструктуре заказчика. Такие требования мы также осмыслили и сформулировали из них задачи для каждой из сторон.

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

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