Экспертиза

Самостоятельный анализ уязвимостей ПО на ОУД4

Анастасия Харыбина
директор по комплексным проектам Компании «Актив», директор по развитию AKTIV.CONSULTING

Павел Семёнов
Консультант по информационной безопасности, CISM AKTIV.CONSULTING

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Вернуться к списку экспертиз

Подписаться

Подпишитесь на нашу рассылку, чтобы быть в курсе новостей АБИСС