Стандарт СТО БР ИББС – принимать или не принимать?

Своим мнением о том, каким путём идти банкам при решении задач обеспечения информационной безопасности, в том числе – защиты персональных данных, о некоторых широко распространенных мифах, ошибках и заблуждениях, сопровождающих основные стандарты обеспечения информационной безопасности, а также о том, какие сложности и проблемы ожидают "внедренца" на самом деле, делится эксперт ФБК Михаил Винников, заместитель руководителя направления "Аудит информационных систем" по методологической работе:

С подходами ФСТЭК не всё так просто, как кажется на первый взгляд.

После выпуска Банком России стандарта информационной безопасности СТО БР ИББС (далее – Стандарт) перед банками встал вопрос – принимать или не принимать данный стандарт в качестве основы своей деятельности при обеспечении информационной безопасности. Стандарт носил рекомендательный характер и не воспринимался как серьезный документ.

Выход Федерального закона "О персональных данных" №152-ФЗ, в котором достаточно конкретно обозначено требование к обеспечению защиты прав субъектов персональных данных, в том числе, посредством обеспечения информационной безопасности информационных систем обработки персональных данных, более рельефно обозначил требования к информационной безопасности, пусть и "в отдельно взятой области". Но и этот факт опять же не оказал стимулирующего воздействия на финансовые организации для начала работы по обеспечению безопасности информационных ресурсов, то ли из-за сильной размытости и неконкретности в формулировках требований, то ли в силу неразберихи в определениях понятий, таких как "[не]автоматизированная обработка" и т.п.

Формирование Банком России во взаимодействии с другими регуляторами по защите персональных данных законодательной и методологической среды для приведения информационных систем персональных данных банков к требованиям Федерального закона "О персональных данных" №152-ФЗ на основе последней версии Стандарта (июнь 2010 года) опять же не внесла особой уверенности в действия банков – они по-прежнему, похоже, не понимают, каким путем им выгоднее идти, в частности, в вопросах защиты персональных данных (ПДн).

Для банков существует как минимум два пути обеспечения соответствия ИСПДн требованиям 152-ФЗ. Мы об этом уже писали в одной из статей.

Внедрение стандарта является непростой задачей, т.к. подразумевает не разовую компанию по написанию политик безопасности и инструкций пользователя, а непрерывную работу в замкнутом цикле управления "планирование – реализация – оценка результатов – выработка управленческих решений".

Создается впечатление, что идя по пути ФСТЭК этого делать не надо, т.к. об этом не написано в явном виде. В действительности это представление поверхностно и, по существу, ошибочно.

В документах ФСТЭК есть требования как по проведению мероприятий, непосредственно связанных с ИСПДн (классификация ПДн и ИСПДн, учет носителей ПДн, учет лиц, имеющих доступ к ИСПДн и т.п.), так и по обеспечению безопасности информации в ИСПДн разного класса, зафиксированных в частности в Приказе ФСТЭК №58 от 5 февраля 2010 года (требования которого, кстати, во многом перешли в РС БР ИББС-2.3-2010 "Требования по обеспечению ИБ ПДн"). Многие считают, что данный приказ относится только к системам, классифицированным как типовые (т.е. такие, где надо обеспечить только конфиденциальность данных) и не относится к специальным (т.е. таким, где надо дополнительно обеспечить доступность и/или целостность), т.е. к тому классу, к которому, скорее всего, будут отнесены подавляющее число ИСПДн, эксплуатируемых в банках. Но истинность данного мнения определяется тем, как относиться к положениям данного приказа.

Можно рассматривать их как буквальные требования только к данному классу систем, а можно как минимальные к системам, имеющим, по сути, более широкие требования к обеспечению безопасности. Т.е., например, для многоролевой многопользовательской системы управления кадровой информацией банка, отнесенной по классификации ФСТЭК к специализированным системам класса К3, необходимо кроме требований, описанных в п.2.3 Приложения к Положению о методах и способах защиты информации в информационных системах персональных данных Приказа №58, добавить защиту от скачков и пропадания напряжения в сетей питания сервера посредством UPS (блок бесперебойного электропитания) с сетевым фильтром и RAID (система защиты на основе избыточных дисков) дисковой системы на сервере (для обеспечения доступности и целостности данных), т.е. требования выше, а не ниже, чем по Приказу.

Таким образом, при выборе "пути по ФСТЭК" никто не отменяет требование по реализации общей защиты информации в ИСПДн.

Далее по цепочке рассуждений – если Вы организуете систему информационной безопасности ИСПДн, т.е. создаете, по меньшей мере, функциональные роли офицера безопасности, ставите антивирусные системы, организуете ролевой доступ к информационным системам, критичным к требованиям ИБ, по крайней мере, не более чем в основных информационных бизнес-системах банка, к которым, правда, пока (вопрос: как долго?), не выдвигаются столь строгие требования по ИБ. Да и работоспособность системы защиты информации перед регулятором можно подтвердить только на основе тех же многоуровневых программных, нормативных и отчетных документов, прописанных, например, в стандарте СТО БР ИББС. Так почему не защищать данные в ИСПДн в рамках общей системы информационной безопасности банка, обеспечивающей, в том числе, защиту бизнес-информации, которую все чаще предлагают считать т.н. информационным активом банка, наряду с реальными материальными активами?

Существенным недостатком "пути ФСТЭК" является то, что под определение ИСПДн попадают ВСЕ технологические процессы и информационные системы банка, в которых в том или ином виде присутствуют персональные данные. "Путь СТО БР ИББС" выводит из класса ИСПДн автоматизированные системы, информационная безопасность которых обеспечена положениями "банковской тайны", а именно, например, расчетные системы, к которым, в соответствии с положениями СТО БР ИББС, относятся все системы банка, формирующие финансовые транзакции. Естественно, система кадрового учета, используемая в банке, в любом случае является ИСПДн, как бы она ни реализовывалась и какими бы архитектурными особенностями ни обладала. Некоторые сложности в классификации "ИСПДн/Не ИСПДн" вызывают информационные системы разного типа, реализованные на едином ядре-надстройке над СУБД промышленного типа. Например, на российском рынке есть АБС, в которых реализованы как системы проведения клиентских расчетов и учета банковских операций, так и система кадрового учета. Как классифицировать данную систему? Есть две крайности – первая: объявить данную АБС ИСПДн и "получить проблему по полному профилю" при классификации, обеспечении защиты по требованиям документов ЦБ и ФСТЭК и т.п.; вторая: объявить, что кадровая система и, в частности, рабочие места и технологические процессы, встроенные архитектурно в АБС, НЕ является ИСПДн и, в свою очередь, "поиметь" реальные проблемы с регулятором, который априори знает, что любой, даже неавтоматизированный, кадровый учет ведется при помощи ИСПДн. Истина, как всегда, где-то посередине. Например, к рабочим местам и ролям доступа кадрового офицера необходимо предъявлять требования как к ИСПДн, но считать и реализовывать защиту информации в АБС так, что в остальном система закрыта требованиями банковской тайны.

Еще одним, скажем, непростым местом в подходе к защите ИСПДн по ФСТЭК является оценка уровня соответствия требованиям.

С одной стороны, т.к. отсутствуют четкие указания по правилам формирования оценки, можно предположить, что "хозяин-барин" и банк сам волен определять нормы, правила и подходы к защите информации в ИСПДн на основе "принятой в банке модели угроз ИСПДн". Т.е., "захочу и напишу, что персональным данным в моих информационных системах ничего не угрожает, поэтому все имеющиеся у меня в настоящий момент средства защиты информации (в том числе и их полное отсутствие) данной модели угроз соответствуют и все у нас в порядке". Только как такой подход будет отстаиваться перед регулятором при проведении проверки или, не дай бог, расследовании инцидента? Поэтому, видимо, стоит предположить, что защита данных все-таки должна быть и не абы какая, а работающая, хотя бы в пределах здравого смысла: если есть требование закона об ограничении доступа к персональным данным кругом лиц, которым эти данные необходимы по работе, значит, система управления доступа в ИСПДн должна быть и должна быть настроена соответствующим образом и т.д.

С другой стороны, предположим, элементы обеспечения системы информационной безопасности имеются, но достаточны ли они для минимального удовлетворения регулятора? (Понятно, что совершенство не достижимо и всегда есть куда расти в пределах ресурсов и бюджета). С точки зрения документов ФСТЭК это не очень очевидно, а, значит, присутствует субъективный фактор оценки, который очень трудно бывает предугадать.

Подход Банка России, отраженный в СТО БР ИББС-1.2 "Методика оценки соответствия..." содержит выверенный, а главное – согласованный с регуляторами подход к оценке, контрольные позиции, весовые коэффициенты, пороги оценок, дающие возможность количественно оценить текущее состояние информационной безопасности, в т.ч. отдельных ее элементов, и определить направления развития и управляющие воздействия для формирования комплексной системы информационной безопасности банка.

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

Таким образом, "легкость" одного пути ("пути ФСТЭК") по сравнению со "сложностью" другого ("пути СТО БР ИББС") явно сомнительна.

"Путь ФСТЭК", вроде бы, касается узкой области ИСПДн, но, в конце концов, приводит к необходимости принятия более "широких" решений и действий по системе информационной безопасности в целом, но зачастую "расширять" строение на "узком" фундаменте сложнее (и дороже), чем изначально строить его на основе, учитывающей все аспекты информационной безопасности.

"Путь Стандарта" более всеохватен и, скорее всего, потребует на начальной фазе больше ресурсов, но допускает по многим направлением постепенное и целенаправленное движение с возможностью проведения [само]оценки текущего состояния и обеспечивает защиту информационных ресурсов банка в целом.

И поэтому, по нашему мнению, регулирование в специализированной отраслевой области надо доверять специализированным организациям и их рекомендациям.

Но, в конце концов, выбор остается за банками...

Tweet