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

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

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

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

Центральный Банк в своём ГОСТ Р 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, не претерпит каких-то кардинальных изменений.

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

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

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

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

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

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

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