BIS Journal №3(38)/2020

13 августа, 2020

И заведите клона…

Использовать защищаемые данные для целей тестирования – нельзя, или когда-то всё-таки можно?

 

Что требует регулятор:

Центральный Банк в своём ГОСТ Р 57580.1-2017 «Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый набор организационных и технических мер», действующем с 1 января 2018 года, выдвигает следующие базовые требования:

В вычислительной сети финансовой организации должен быть выделен отдельный сегмент или группа сегментов, предназначенных для размещения информационной инфраструктуры, используемой только на этапе создания и(или) модернизации автоматизированной системы (далее – АС), в т.ч. тестирования программного обеспечения и средств вычислительной техники. Сетевое взаимодействие с иными сегментами по инициативе сегмента разработки и тестирования должно быть исключено (раздел 7.3.1.2, пункты СМЭ.6, СМЭ.7).

При этом использование защищаемой информации в сегментах разработки и тестирования запрещается, за исключением случаев, когда речь идёт о конфигурационной информации, определяющей параметры работы АС (раздел 9.5, пункт ЖЦ.7).

Данные требования актуальны в том числе для контуров безопасности в области действия Положения Банка России от 17 апреля 2019 года № 683-П «Об установлении обязательных для кредитных организаций требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента» (Положение № 683-П), поскольку оно ссылается на ГОСТ Р 57580.1-2017. С 2023 года, видимо, будут актуальны и для Положения Банка России от 9 июня 2012 года № 382-П «О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств» (Положение №382-П), если проект очередной его редакции, также содержащий отсылку к ГОСТ Р 57580.1-2017, не претерпит каких-то кардинальных изменений.

 

Что можно не делать?

Популярная, но некорректная постановка вопроса. Правильнее говорить о том, когда и что именно делать нужно, потому как не каждое «попробовать» – это тестирование, к которому предъявляются приведённые выше требования. Решающую роль при этом играет статус системы, в которой необходимо определить возможность использования защищаемых данных и решить проблему размещения в том или ином сегменте сети организации.

 

Когда речь идёт действительно о тестировании?

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

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

 

Когда речь идёт о диагностике, и требования регулятора неприменимы?

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

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

Смотрите также

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

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

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

28.03.2024
Аитов: Ограничения Samsung Pay на использование карт «Мир» можно обойти
28.03.2024
Киберпреступления — 35% всех преступлений в России
28.03.2024
Почему путешествовать «налегке» не всегда хорошо
28.03.2024
«Тинькофф»: Несколько платёжных систем лучше, чем одна
28.03.2024
В РФ готовят базу для «усиленной блокировки» незаконного контента
28.03.2024
Термин «риск ИБ» некорректен по своей сути
27.03.2024
Samsung Pay перестанет дружить с «мировыми» картами
27.03.2024
Канадский университет восстанавливает работу после ИБ-инцидента
27.03.2024
Crypto Summit 2024. Трейдинг, майнинг и перспективы развития рынка ЦФА
27.03.2024
РКН начал работу по контролю за «симками» иностранцев

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

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

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