Банки и некредитные финансовые организации все чаще задаются вопросом, как провести анализ программного обеспечения в соответствии с требованиями ОУД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

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

18.03.2024
Сколько денег тратят на маркетинг лидеры российского рынка инфобеза
18.03.2024
Microsoft закроет доступ к облачным сервисам для российских компаний
18.03.2024
От операторов связи потребовали ограничить продажу «симок»
18.03.2024
Жертва социнженеров пыталась поджечь отделение «Сбера»
18.03.2024
Системы МВФ были взломаны впервые за 13 лет
15.03.2024
ИИ поможет бизнесу выявлять брак и маркировать продукцию
15.03.2024
Минцифры поручено и дальше цифровизировать всё вокруг
15.03.2024
Стоит с настороженностью относиться к сообщениям о перевыпуске SIM-карты
15.03.2024
IDC: Больше всех на «облака» в этом году потратит Польша
14.03.2024
Вендоры хотят ограничить госкомпании в закупках зарубежного харда

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

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

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