СОИБ. Анализ. Рекомендации по жизненному циклу приложений, тестированию и каталог уязвимостей

31 июля 2014 г. Банк России опубликовал документ «Обеспечение информационной безопасности организаций банковской системы Российской Федерации. Обеспечение информационной безопасности на стадиях жизненного цикла автоматизированных банковских систем» (РС БР ИББС-2.6-2014)», который вводится в действие с 1 сентября 2014 г.

Не часто нас балуют рекомендациями по ИБ подобного типа, поэтому давайте его рассмотрим подробнее.

Есть основной стандарт СТО БР ИББС-1.0-2014, в котором есть раздел требований “7.3. Общие требования по обеспечению информационной безопасности автоматизированных банковских систем на стадиях жизненного цикла”.

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

“1) разработка технического задания (ТЗ);

2) проектирование;

3) создание и тестирование;

4) приемка и ввод в действие;

5) эксплуатация;

6) сопровождение и модернизация;

7) снятие с эксплуатации.”

Но есть в документах и нестыковочки:

СТО БР ИББС-1.0-2014 в целом использует термин процедуры, а в частности требования к процедурам обеспечения ИБ на разных стадиях АБС приводятся в пунктах: 7.3.9, 7.3.10, 7.3.11, 7.3.13, 7.3.14, 7.3.15, 7.3.16.  

РС БР ИББС-2.6-2014 в основном оперирует термином “задачи в части обеспечения ИБ”. Например, на стадии эксплуатации никаких процедур не предусмотрено. Только задачи.

Например, СТО требует чтобы на стадии эксплуатации были определена и выполнялась процедура:

“контроля необходимого обновления программного обеспечения АБС, включая программное обеспечение технических защитных мер.”

В РС на этой стадии про обновления – ни слова, зато есть периодическая оценка защищенности и мониторинг сообщений об уязвимостях.

СТО:

 “7.3.10. На стадии эксплуатации АБС должны быть определены, выполняться, регистрироваться и контролироваться процедуры, необходимые для обеспечения восстановления всех реализованных функций по обеспечению ИБ.

7.3.11. На стадии эксплуатации АБС должны быть определены, выполняться и регистрироваться процедуры контроля состава устанавливаемого и (или) используемого ПО АБС.

7.3.13. На стадии эксплуатации АБС должны быть определены, выполняться и контролироваться процедуры, необходимые для обеспечения сохранности носителей защищаемой информации.”

По этим процедурам на стадии эксплуатации АБС в РС так-же не приводится ни слова уточнений или рекомендаций. Из этого видно что только РС БР ИББС-2.6-2014 недостаточно для обеспечения ИБ на стадиях жизненного цикла АБС. Некоторые процедуры придется определять самостоятельно.

Это всё о грустном, дальше только плюсы:

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

·         Документом с небольшими изменениями можно руководствоваться при разработке ИС любых типов

·        РС фактически содержит в себе отдельный под-документ: каталог типов уязвимостей (недостатков) ИС.

До этого публичные каталоги типов уязвимостей можно было найти только в западных источниках - каталогах уязвимостей, каталогах угроз, методиках тестирования: WASC, OWASP, Simplicable, BSI, ISMS. Теперь есть локальный публичный источник.

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

·        РС фактически содержит в себе ещё три отдельных под-документа: Рекомендации к проведению контроля исходного кода, Рекомендации к проведению оценки защищенности, Рекомендации к проведению контроля параметров настроек технических защитных мер

Данные рекомендации с небольшими корректировками можно применять и для любых ИС компаний из других отраслей. Так как меры по контролю исходного кода, оценке защищенности и контролю конфигурации требуются для ИСПДн, ГИС и АСУ ТП, то такие рекомендации не будут лишними.

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