Как мы писали ранее, кроме сертификации ПО во ФСТЭК и привлечения внешнего подрядчика есть и третий путь – самостоятельный анализ уязвимостей ПО по требованиям ОУД4. Изначально этот вариант был доступен только НФО. Тем не менее Банком России в июле подготовлены изменения в Положение 683-П, разрешающие кредитным организациям проводить анализ своими силами.

Ресурсы для проведения анализа

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

• наличие методики проведения анализа;
• наличие описания этапов проведения работ в методике;
• наличие специализированного инструментария;
• наличие квалифицированных специалистов.

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

Таким образом, первое, что необходимо сделать – это выяснить, есть ли в организации требуемый инструментарий и персонал с нужной квалификацией. Если нет,следует совместно с ИТ-подразделением проработать вопрос об эффективности их приобретения или найма. Вполне вероятно, что высокие финансовые затраты удастся оправдать, но вопрос сроков реализации, скорее всего, останется открытым.

Встраивание анализа в релизный процесс ПО

После того, как необходимый инструментарий и ресурсы будут выделены или приобретены, следует разработать методику проведения анализа уязвимостей (подробнее в предыдущей статье) и встроить сам анализ в релизный процесс ПО с генерацией отчёта о соответствии ОУД4. Необходимо это сделать не только для нового разрабатываемого ПО, но и для крупных обновлений существующего. Например, в задачи на разработку ПО следует добавить пункты о подготовке документации, а также убедиться в том, что исходный код хранится в надёжном месте с резервным копированием.

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

Что же делать с тем программным обеспечением, которое уже сейчас находится в промышленной эксплуатации? Его потребуется проанализировать точно так же, как и описано выше для нового разрабатываемого ПО: с использованием той же методики и последующей подготовкой отчёта о его соответствии ОУД4. После этого необходимо встроить анализ данного ПО в релизный процесс, начиная со следующего крупного обновления, поддерживая тем самым заданный уровень безопасности.

Новая культура разработки ПО

Зачастую комплаенс нагрузка на ИБ рассматривается в разрыве от так называемой реальной безопасности и тем более от бизнес-целей организации. В случае с внедрением анализа кода в релизный процесс ПО это может стать первым шагом для трансформации функции ИБ в бизнес-функцию финансовой организации. Речь идет о встраивании процессов безопасной разработки (SecureSDLC), которые очевидным образом повышают уровень зрелости ИТ/ИБ процессов компании. Фреймворк ГОСТ/ИСО 15408, в соответствии с которым необходимо делать анализ уязвимостей ПО на ОУД4, хорошо ложится, например, в широко известное описание процесса SecureSDLC от компании Microsoft. Он точно так же предусматривает подготовку требований к ПО с учётом потенциальных нарушителей и применение инструментов статического и динамического анализа.

При этом не обязательно ориентироваться на описание SecureSDLCименно от вышеупомянутой компании. Любой встроенный в соответствии с лучшими практиками SecureSDLCпроцесс разработки ПО, даже с полной автоматизацией DevOps-конвейера, автоматизированным тестированием и релизами каждые 3 часа, удовлетворит требованиям ОУД4 и даже более строгим. И здесь мы уже говорим не только о выполнении регуляторных требований Банка России, но и об участии ИТ/ИБ-функции в формировании качественного продукта для клиентов, что ставит ее на один уровень с бизнес-функциями организации. Об этом мы обязательно подробнее поговорим в других статьях.

В качестве резюме

Самостоятельный анализ уязвимостей ПО на ОУД4 хоть и требует значительных дополнительных ресуров, но может быть реализован самостоятельно при выполнении следующих условий:

• наличие методики анализа уязвимостей;
• наличие инструментов для анализа кода и квалифицированного персонала;
• наличие встроенного процесса анализа в релизный процесс ПО.

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

Источник: IB-BANK.RU