`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Алексей Дрозд

DLP-системы в финансовом секторе

+44
голоса

Финансовые организации предъявляют к DLP-системам особые, достаточно высокие, требования, и поэтому далеко не каждая система защиты от утечек данных, подходящая, скажем, производственной компании, подойдет финансовой. На какие особенности DLP-системы стоит обратить внимание перед решением о её приобретении? Их список достаточно велик:

  1. Отсутствие угрозы для непрерывности бизнес-процессов организации;
  2. Поддержка максимально большого числа каналов передачи данных, по которым может произойти утечка (электронная почта, ICQ, Skype, внешние носители информации, отправляемые на печать документы и т.д.);
  3. Возможность внедрить систему без необходимости обеспечения доступа сторонних специалистов к защищаемой конфиденциальной информации и без остановки деятельности организации во время внедрения системы;
  4. Развитые возможности по анализу перехваченных DLP-системой данных и широкие возможности поиска конфиденциальной информации в них;
  5. Возможность выявления не только точных копий конфиденциальных документов, но и их изменённых вариантов;
  6. Масштабируемость системы (т.е. возможность легко подключить к корпоративной системе защиты конфиденциальной информации новые компьютеры).

Можно сказать, что все качественные DLP-системы сегодня удовлетворяют указанным требованиям, в большей или меньшей степени. Но нужно помнить, что при выборе DLP-системы ИБ-отдел финансовой компании ориентируется на многие другие показатели, которые могут уже достаточно сильно отличаться (например, у большинства зарубежных DLP  есть вопросы с поддержкой русского языка).

DLP-системы в финансовом секторе

+44
голоса

Напечатать Отправить другу

Читайте также

Алексей, а почему Вы акцентируете внимание только на требованиях финансового сектора?
По моему скромному мнению, большинство заказчиков ищут систему так или иначе подходящую под эти требования.
Я позволю себе коротко прокомментировать каждое из них:

1. Непрерывность бизнеса.
Это правильно, К этому нужно стремиться.
Но также очень важно понимать, что как только мы переходим от простого мониторинга и перехвата теневых копий к блокированию утечек (или того, что система распознала как утечку) мы получаем паузу бизнес-процесса. Это неизбежно для решений, которые предлагают основные игроки на рынке DLP систем.
Для оптимизации и устранения простоев интегратор совместно с ИТ-специалистами заказчика обязан предпринять ряд мер:
- DLP система должна предусматривать функционал обхода/отмены блокировки таким образом, чтобы пользователь мог уведомить ИБ о ложном срабатывании;
- сотрудники компании, в которой внедряется DLP должны быть официально уведомлены об изменении бизнес-процессов, они должны четко знать что делать если их письмо не уходит, а документ не распечатывается;
- HelpDesk или ИБ департамент должны своевременно реагировать на запросы пользователей и устранять ложные срабатывания путем тонкой подстройки политик;
- из предыдущего условия формируется требование к компетенции интегратора и специалистов заказчика (кто будет сопровождать DLP)

2. Озвученные требования, как правило решаются за счет агентного ПО, которое развертывается на сервер/рабочую станцию.
В ряде случаев, для большей эффективности внедрения DLP я советую заказчику провести инвентаризацию используемого ПО и аудит прав учетных записей пользователей перед внедрением DLP.
Так проще писать политики.

3. Неоднозначное требование.
С одной стороны, это можно реализовать, при условии, что собственные специалисты компании получат компетенцию по внедряемому решению. Но с другой стороны, если я не ошибаюсь, согласно ISO 127001/002 аудит СМИБ включая DLP должен проводиться внешней организацией. Получается, для оценки эффективности внедренного решения нужно привлекать "чужих" специалистов. Вообще это извечная дилемма. Тут уже либо 90% доверия к интегратору + NDA, либо компетенция своих специалистов.
Следует помнить, если руководство не покажет всю конфиденциальную информацию (включая самую ценную), политики, созданные на этапе внедрения DLP системы могут не остановить утечку самого ценного.

4. Data-Mining. Здравое требование. Главное чтобы интегратор/специалисты ИБ умели пользоваться инструментарием DLP системы.

5. Если мы копнем чуть глубже в сторону технических дебрей, то выясниться, что выполнение этого требования достигается за счет комбинирования тегирования (tagging), снятия цифровых отпечатков и контекстного анализа текстовой составляющей.
Практически все крупные игроки DLP рынка это в той или иной степени умеют, но как показывает моя скромная практика PoC и внедрений - мало кто из заказчиков использует эти технологии по-максимуму. Вообще, все что касается классификации информации, по простому "отделение мух от котлет" - это очень острая проблема. Интеграторы как правило стараются не заморачиваться с этим, а заказчики очень тяжело формируют критерии отличия коммерческой тайны от остального пласта информации.

6. Здравое требование корпоративного сегмента.
Если мы говорим о тех, модулях DLP, которые функционируют на сетевом уровне, тут проблем с масштабируемостью не возникает (пока не упремся в пропускную способность железок или виртуалок). Кластеризация спасает.
А если говорить про клиентские модули, то процесс масштабирования очень облегчает deployment и управление из единой консоли.

В завершении своего комментария, я хотел бы обратить внимание читателей на то, что не озвученные автором требования присущи не только финансовому сектору.
По мере роста спроса на DLP системы учреждения из разных сфер украинского бизнеса, включая ГОС органы приходят в необходимости внедрения DLP.
Для кого-то это осознанный шаг, для кого-то попытка ликвидировать последствия, для иных - способ поставить галочку "впроваджено".
В любом случае, эти требования выдвигают не только представители финансового сектора.

p.s.
Алексей, меня насторожила фраза

"у большинства зарубежных DLP есть вопросы с поддержкой русского языка"

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

Я понимаю, что SearchInform гордиться своим поисковым движком, но не стоит забывать, что DLP это лишь инструмент.
На какой язык его настроишь - тот и будет мониторить.
Ничто не мешает заказчику написать свои словари и шаблоны на русском/украинском языке. И уж точно ничто не мешает системе "парсить" кириллический текст.

Тут мы опять возвращаемся к вопросу классификации информации...

Читателей с праздником и хороших выходных.

Ух. Ваш ответ получился даже больше, чем сам пост. Внесу к вашим комментариям немного своих мыслей.

1. Из нашей практики могу сказать, что клиенты предпочитают вообще обходиться без блокировки. Как Вы правильно написали, для оптимизации простоев придётся совершить много лишних телодвижений и, как следствие, дополнительно потратиться. Учитывая стоимость самой DLP + стоимость услуг интегратора, раскошеливаться ещё на что-то бизнес будет скрипя зубами. В то же время польза от блокировки в глазах бизнеса выглядит сомнительной (особенно после того, как пару раз обожгутся).

2. Да, только через агентов. Здесь есть важный нюанс: если в системе предусмотрена возможность создать уникальные настройки по перехвату для каждой станции, нужно отображать всё это так, чтобы пользователь (безопасник) не запутался.

3. Эта опция «не для всех». С внедрением, как правило, сложнее (если полностью самостоятельно). А вот с использованием с недавних пор проще, так как мы открыли учебный центр, в котором учим, как разбить любую сложную задачу на ряд подзадач и «перевести» их на язык DLP-системы.

4. Здесь снова отсылка к учебному центру.

5. С вопросом «так а что защищать?» приходят очень многие. Серьёзно. Не ожидал, что их настолько много. Мы иногда начинаем работу даже с анализа инсайд-листа. Казалось бы, что там вода водой, но в итоге получается, что даже оттуда можно накопать с десяток задач. Затем уже смотрим их актуальность для компании, потому что иногда что-то контролировать может и хотелось бы, но затраченные усилия и время больше, чем предотвращённый ущерб.

6. А тут и добавить, собственно, нечего :)

Поэтому поясню что имелось ввиду под "проблемами с русским языком".

Навскидку могу назвать парочку.

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

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

Эта проблема тоже легко решается - нужно написать эти выражения. Но написаны ли они?

Во-вторых, в "западных" системах могут отсутствовать списки стоп-слов для "местных" языков. Тем самым, индексироваться будет всё, а это и избыточный объём индекса, и снижение скорости отработки поисковых запросов. Рискну предположить, что и на качестве поисковой выдачи это может сказаться.

Алексей, спасибо за дополнительные мысли.

1. Возможно, с точки зрения "бизнесов" так легче, но Вы ведь понимаете, что мониторинг и профилактические беседы не слишком помогут при реальной утечке. И будет уже не важно случайно или умышленно "слили" информацию;

5. По поводу открытых источников согласен.
На эту тему на майском phd был хороший доклад Влада Стырана по OSINT;

- - -
По поводу "кирилизации"

- локализация интерфейса (возможно) критична для менеджмента или тех персон, которые будут работать только с отчетами;
По моему скромному мнению, ИТ специалист, особенно если он работает в сфере ИБ, обязан знать английский на должном уровне (все равно больший процент cli/gui написан на языке Шекспира)

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

- по поводу "чемодана" предустановленных политик:
Так или иначе, для более гранулированного срабатывания политики DLP системы должны перебираться или переписываться под конкретного заказчика.
Настройки by default возможно и сгенерируют видимость деятельности, но уж точно не помогут разобраться где серьезная утечка, а где пустой треп.

* То есть мы все равно приходим к тому, что рано или поздно политики нужно переписывать/писать под клиента, иначе по-молчанию будет либо много ложных срабатываний, либо не увидим желаемого

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

В любом случае, спасибо за дискуссию.
Мне понятна Ваша позиция.
И не смотря на разногласия по некоторым пунктам, с отдельными тезисами я согласен.

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT