Недавно коллеги из АРБ организовали и провели при поддержке уважаемой компании «Диалог-Наука» вебинар по ознакомлению с очередными требованиями Банка России по обеспечению информационной безопасности. Получилось хорошее мероприятие, но не буду его пересказывать, а поделюсь своими мыслями, которые зароились после его завершения.
Друзья мои, мы живем в интересное время. Не многим повезло так, как нам с вами. Мы не изучаем информационную безопасность, а создаем ее, сами пишем эту увлекательную историю.
На наших глазах и нашими с вами руками создавались фундаментальные для финансовой отрасли основы защиты информации в форме сначала стандартов Банка России, а затем несколькими итерациями Положений БР мы перешли к российским стандартам — ГОСТам. Только перечисление СТОБРов, ГОСТов, МРок, Указаний и Положений заняло бы целую страницу. Не одно поколение авторов прошло эту школу писательства нормативки. Вдогонку многое прилетает к нам от наших партнеров из-за рубежа — еще одна гора стандартов карточных платежных систем со всего света, включая наши собственные, да еще всякие SWIFTы и пр., а ведь мы не только реализуем эти требования, но еще и сами принимаем активное участие в их разработке на основе нашего собственного опыта.
Но все-таки основная проблема — в реализации требований, а гора их растет.
За что это нам? Неужели нельзя было сделать что-то «одно на всех» и соответствовать «ему», а все остальные пусть доверяют! Давайте посмотрим картинку (рис.1).
Рисунок 1. Области требований к защите информации
В банке, как правило, обрабатываются различные виды информации, к которым предъявляются различные требования по защите этих видов информации. Их пересечения очень условно можно поделить как на рис. 1.
Очевидно, что невозможно совсем разделить все эти виды информации на изолированные контуры. И невозможно строить несколько систем защиты информации. Естественно, что идеологически самый простой способ — объявить всю информации равнозащищенной, строить безопасность по самому высокому уровню защиты, какой найдется в организации, и тогда вся информация будет защищена. Технически это очень дорогостоящая утопия, потому что надо будет научиться делить все системы по уровню защиты, научиться гарантированно разделять те сегменты сети, где обрабатываются данные одного уровня, и в каждом сегменте строить свою защиту. Но тогда, возможно, окажется, что принципы построения защиты в каждом сегменте могут значительно отличаться.
Проблема эта не новая, и ее решение на каждом этапе развития ИБ было свое. Например, в начале 2010-х годов остро встал вопрос соответствия требованиям по защите персональных данных. Благодаря усилиям Банка России родилось знаменитое письмо четырех, в результате банки, имеющие определенную оценку соответствия требованиям ЦБ, автоматически считались соответствующими требованиям по защите ПДн. Как это решилось? Были обозначены «кирпичи» из фундамента безопасности, которые надо было взять и вложить в свой «фундамент» (рис.1).
Сейчас, когда требований стало больше и они стали разнообразней, появилось новое видение, как строить безопасность: нам предложили набор «кирпичей» для строительства системы обеспечения ИБ – наборы организационных и технических мер в форме стандарта ГОСТ-Р57580.1-2017 и правил оценки правильности «сбора этих кирпичей» ГОСТ-Р57580.2-2018. Очень кратко это выглядит так: группы процессов объединены направлениями, внутри каждого из которых сгруппированы наборы организационных и технических мер:
Внутри каждого буллита есть свои 2-10-20-30-40 «подбуллитов», которые, собственно, и создают ту самую основу – «кирпичи» и правила обращения с ними, благодаря чему мы можем строить любую систему защиты информации. Всего набирается около 340 мер, каждая из которых может иметь организационную или техническую составляющую, либо не иметь ее вовсе, в зависимости от целевого уровня защиты. Для того, чтобы разобраться с обилием кирпичей, предлагается использовать процессный подход для управления «стройкой» и последующей «эксплуатацией».
Более того, если взять обобщенные требования МПС [1], то даже для их реализации всегда можно набрать кирпичей из стандарта.
Если рассмотреть требования к типовым информационным системам банка – АБС, СДБО, CRM, процессинговые системы, системы отчетности, технологические системы и т.д., – то в общем случае требования начинают носить все более унифицированный характер.
Иначе говоря, система защиты информации банка, правильно собранная из этих кирпичей на основе процессного похода, будет соответствовать требованиям практически любого нормативного документа БР или МПС.
Все Положения БР теперь не формулируют непосредственно требования, а ссылаются на ГОСТ – возьми такой-то набор кирпичей и будет тебе хорошо. Т.е. в общем случае применение кирпичей необходимо как для платежных, неплатежных и просто технологических систем. Такой подход позволит унифицировать применяемые средства защиты для разных элементов банковской КИС и тем самых хоть немного облегчить участь ибэшников.
Совершенно очевиден следующий шаг –гармонизация этой «фабрики кирпичей» с техническими требованиями других стандартов. При таком подходе появление нового документа не будет вызывать очередной шок — не надо начинать все сначала, а нужно просто проверить все ли кирпичи на месте, уложены ли правильно, либо где-то каких-то кирпичей не хватает и их надо будет «просто» добавить.
Отдельно нужно было бы взглянуть на управление жизненным циклом автоматизированных банковских систем, на ряд требований к выделению технологических участков и обеспечения их безопасности, на требование сертификации ФСТЭК отдельных видов ППО, на профиль защиты ППО.
Но это уже другой разговор.
Построение и обслуживание защищенной сети и систем
1. Установить и обеспечить функционирование межсетевых экранов для защиты данных держателей карт
2. Не использовать пароли и другие системные параметры, заданные производителем по умолчанию
Защита данных держателей карт
3. Обеспечить безопасное хранение данных держателей карт
4. Обеспечить шифрование данных держателей карт при их передаче через сети общего пользования
Программа управления уязвимостями
5. Защищать все системы от вредоносного ПО и регулярно обновлять антивирусное ПО
6. Разрабатывать и поддерживать безопасные системы и приложения
Внедрение строгих мер контроля доступа
7. Ограничить доступ к данным держателей карт в соответствии со служебной необходимостью
8. Определять и подтверждать доступ к системным компонентам
9. Ограничить физический доступ к данным держателей карт
Регулярный мониторинг и тестирование сети
10. Контролировать и отслеживать любой доступ к сетевым ресурсам и данным держателей карт
11. Регулярно выполнять тестирование систем и процессов обеспечения безопасности.
Поддержание политики информационной безопасности
12. Разработать и поддерживать политику информационной безопасности для всего персонала организации
- Стоимость медиауслуг (открыть PDF) -
Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных
Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных
.png)