Банки и некредитные финансовые организации все чаще задаются вопросом, как провести анализ программного обеспечения в соответствии с требованиями ОУД4 ГОСТ Р 15408-3. С января этого года вступили в силу требования положений Банка России 683-П, 684-П и 382-П об анализе уязвимостей ПО финансовых организаций в соответствии с ОУД4. Интерпретация этих требований вызывает противоречия и многочисленные дискуссии у экспертов сообщества. 

У Банка России есть официальные и неофициальные разъяснения по этому вопросу. Кулуарные обсуждения на отраслевых мероприятиях и в банковском сообществе заслуживают отдельного внимания: все участники рынка понимают сложность сложившейся ситуации и пытаются найти разумный компромисс между необходимым и достаточным. При этом финансовым организациям сложно разобраться с тонкостями выполнения требований регулятора. И как правило, опыт и помощь российских специалистов и консультантов здесь становятся эффективным решением.

Мы решили поделиться нашим видением ситуации и подготовили для безопасников цикл материалов, которые помогут ответить на вопросы: какое имеющееся ПО надо анализировать по ОУД4, как его анализировать и какими ресурсами?

 

С чего начать процесс анализа ПО? 

В первом материале представляем пошаговую инструкцию: с чего начать процесс анализа ПО. Любая финансовая организация обладает обширным парком ПО и автоматизированных систем (АС). Так что же из этого парка подлежит анализу уязвимостей по ОУД4?

Для начала определяемся, какие операции проводятся в организации, и есть ли среди них те, о которых говорят 683/684-П и 382-П. Это банковские (переводы денежных средств, открытие счетов, генерация выписок и прочее, для банков) или другие финансовые операции, например, покупка страхового полиса, покупка/продажа активов на бирже, платежи за накопительную пенсию для некредитных финансовых организаций.

Затем следует просмотреть весь парк АС и отобрать те, которые участвуют в финансовых операциях. Список будет наверняка обширный, смотрим дальше.

 

Банки 

Для банков, в первую очередь, следует отобрать автоматизированные системы, обеспечивающие денежные переводы (согласно п. 2.5.5.1 382-П). Конечно, это основная АБС. В ней под анализ попадает и javascript код веб-интерфейсов, и код хранимых процедур на PL-SQL, и исполняемый код модулей, и bash-скрипты и др., т. к. они обеспечивают проведение платежей.

Аналогично – системы ДБО, в том числе ПО API-интерфейсов. Эти же системы ДБО, в случае работы через интернет, должны попасть под анализ согласно 683-П.

Далее под анализ попадают мобильные приложения для банковских операций, которые банки размещают в магазинах приложений Google и Apple. Их следует подвергать анализу уязвимостей согласно 683-П. В эту же группу следует включить приложения “Банк-Клиент”, передаваемые клиентам юрлицам и ИП.

 

Некредитные финансовые организации (НФО)

Давайте теперь обратимся к крупным некредитным финансовым организациям. Будем говорить о них в терминах 684-П. Так как НФО в основном не являются операторами по переводу денежных средств (на языке 382-П), то основные учётные системы анализировать на уязвимости не требуется, а вот различные системы дистанционного обслуживания (вспомним, какие мы определили для себя финансовые операции) попадут под проверку согласно 684-П. Это сервисы управления активами клиентов на сайтах НФО, личные кабинеты, системы документооборота, приёма платежей за полисы или пенсии и др.

В список ПО попадут и мобильные приложения, размещённые в магазинах Google и Apple, которые НФО используют для финансовых операций и предоставления клиентам информации о своих активах. Если у НФО есть ПО, передаваемое клиентам напрямую, то его следует включить в последнюю группу ПО, которое придётся подвергнуть анализу на уязвимости. Это, к примеру, торговые терминалы брокеров и бирж или системы управления активами в управляющих компаниях.

 

Алгоритм действий кратко:

  • Определяете финансовые операции для своей организации в терминах 683/684-П и 382-П.
  • Отбираете АС, которые обеспечивают эти финансовые операции.
  • Из них отбираете те, которые работают через интернет.
  • Добавляете мобильные приложения и ПО, которым будет пользоваться клиент самостоятельно.
  • Для банков учитываете основные АБС и ПО для переводов денежных средств.

 

Читайте полный цикл материалов

Часть 1. Как приступить к анализу программного обеспечения по ОУД4?

Часть 2. Что проверять во время анализа ПО по ОУД4?

Часть 3. Проблема комплектности ПО и возможные варианты анализа по ОУД4.

Часть 4. Анализ уязвимостей ПО на ОУД4 силами внешнего подрядчика: пошаговая реализация.

Часть 5. Самостоятельный анализ уязвимостей программного обеспечения по ОУД4.

 

***

AKTIV.CONSULTING — одно из бизнес-подразделений российской компании “Актив”, специализирующееся на услугах по консалтингу и аудиту информационной безопасности. Команда обладает экспертизой в вопросах построения систем защиты информации, проведения аудита безопасности и анализа соответствия стандартам. 

16 июня, 2020

Подписаться на новости BIS Journal / Медиа группы Авангард

Подписаться
Введите ваш E-mail

Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных

21.02.2024
«Не являлся значимым кредитором реального сектора экономики». Регулятор лишил QIWI Банк лицензии
21.02.2024
Характер занятости обсуждается при собеседовании. Как становятся дропперами
20.02.2024
Китай считает кибератаки из-за рубежа
20.02.2024
«Тинькофф» выявляет скамерский след в кредитных заявках
20.02.2024
Из банков утекает всё больше ПДн россиян
20.02.2024
В январе в открытый доступ попали 62 базы данный
20.02.2024
Национальная база генетической информации уже вот-вот…
19.02.2024
TestFlight — источник угрозы для «яблоководов»?
19.02.2024
Про мэтчинг. Но не тот, на который вы надеетесь
19.02.2024
«Яндекс» планомерно переходит в реестр ОРИ

Стать автором BIS Journal

Поля, обозначенные звездочкой, обязательные для заполнения!

Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных