Блок про выбор системы, вендора, интегратора

•  Не определить цели зачем нужна ИБ система, а сразу начать выбор.

Это «база». Выбор ПО без понимания цели для этого ПО обычно приводит к таким результатам:

— Быстрый пилот и очень долгое согласование закупки. Потому что ЛПР или его руководство не понимает выгоды от внедрения и какие «боли» будут «закрыты», и соответственно, не хочет платить денег, а сейл видит, что пилот прошёл быстро и гладко и не понимает почему нет оплаты.

— Бесконечный пилот. Потому что требования к системе меняются и появляются в процессе пилотирования; возникают новые вопросы на основании прошлых ответов; пляшут туда-сюда запросы в КП.

— 100500 вопросов и запросов после покупки. С просьбами о доработках и донастройках.

— У заказчика в эксплуатацию попадёт система требования к которой будут не из задач бизнеса, а натянутые на возможности системы.

— Недовольству руководства, т.к. деньги потратили, а результат может быть «не в фокусе».

Опять же, не забудем другую базу: «Без внятного ТЗ — результат ХЗ». Так что, если не понимать «какую боль» лечим — мы останемся болеть, но, возможно, уже без денег.

•  Не определить «папа» и «мама» для ИБ системы.

«Папа» — это бизнес заказчик; тот, кто говорит какие цели нужно достигнуть; тот, кто будет спрашивать метрики.

«Мама» — это подразделение которое будет ответственное, что система «доступна, целостна, конфиденциальна»; тот, кто запросит сколько ресурсов нужно для системы; тот кто будет обслуживать систему; с кого будут спрашивать, если сервис будет недоступен.

В итоге, скорее всего, систему будут стараться не брать на баланс и обслуживание, видя в ней только трату времени. Возможны неожиданные тормоза и зависания системы из-за несогласованности или неверных ресурсов. Очень возможно, не будет целей и метрик для системы.

•  Уже только лишь каждый об этом говорил, но всё равно тоже скажу. Можно столкнуться с ситуацией, когда вендор ушёл с рынка по геополитическим причинам.

И потом сидеть без обновлений, в том числе критических; без тех.поддержки. Да и вообще немного нервничать, что в системе есть time-bomb.

•  Фейл, который может сидеть в голове: считать, что если уже какое-то решение используется, то его нельзя заменить.

Заменить, в общем-то, можно любую систему. Но всегда критичны вопросы:

— Актуальные решаемые задачи и нагрузка;
— Стоимость владения старым и новым решением;
— Наличие специалистов по новой системе, и время переобучения со старого на новое;
— Привычка руководства к отчётам из старой системы;
— Взаимоотношения с вендором/интегратором старой и новой систем;
— Какие-то джокеры или блокеры от регуляторов;
— Заинтересованность «Папы» системы в смене инструмента (или не смене);
— «Нытьё мамы», что придётся работать;
— Ваша личная заинтересованность что-то делать.

В общем, факторов не мало, работа не простая, НО, взвесив все параметры можно пронять решение.

•  Не смоделировать как новая система «вольется» в инфраструктуру.

Определить, что где будет расположено, как будет внедряться; как повлияет на инфраструктуру; как будет работать с тем что уже есть — нужно до момента приобретения и до начала пилота. Иначе можно получить остановку какого-нибудь бизнес-процесса или просто лучи ненависти от ИТ-коллег.

•  Постесняться задать конкретные вопросы вендору/интегратору и домыслить ответы.

Например, диалог, который, скорее всего приведёт к испорченным отношениям, или вообще оставит кого-нибудь без премии:

Заказчик: Ваша DLP Телеграмм же контролирует?
Вендор: Да.

…происходит покупка…

Заказчик: Почему-то ни одно сообщение не перехвачено!
Вендор: Так вы нам показываете web-версию телеграмм!
Заказчик: И что?!? Перехвата Телеграмм нет!!
Вендор: А у нас только перехват в приложении, в web-версии будет только через год!!
Заказчик: так у нас приложением и не пользуются!!! Мы зачем вас купили?!!!
Вендор: ПО работает согласно документации!!!

Пример правильного диалога:

Заказчик: Ваша DLP Телеграмм же контролирует?
Вендор: Да.
Заказчик: можно конкретнее, web-версию и приложение?
Вендор: только приложение.
Заказчик: контроль текста, вложенных файлов, голосовых сообщений и звонков?
Вендор: ещё есть нюансы про входящие и исходящие сообщения, вот держите таблицу 2 на 4 на 2 где галочками отмечен каждый вариант.
Заказчик: отлично, как раз сверю всё с нашими целями для DLP и моделью угроз.

А ещё не забуду след от моей руки на моём лице, во время диалога на созвоне уже после покупки ПО.

Заказчик: как настроить «возможность» чтоб «вот такая информация» «вот это показала»

Я: система так не умеет, тут не вопрос настройки отчёта.

Заказчик: жаль, я думал, что умеет и уже Генеральному сказал, что к следующей встрече принесу такой отчёт. Сделайте что-нибудь чтоб на следующей неделе у меня была такая информация.

Блок про тестирование и внедрение

• Установленная система заблокировала бизнес-процессы.

Например, популярный фейл при внедрении DLP — сразу врубить правила карантина почты. … а затем выслушивать от директора по продажам и финансового о том, что в  подразделениях остановилась почта и не выполняются задачи и KPI.

Ещё из весёлого — бездумное использование «белых списков» блокировок. [«Белый список» — это когда разрешено только то, что в списке]. Если сделать «белый список» USB устройств только из разрешённых флэшек … верно! Внезапно отвалятся принтеры, мышки, клавиатуры. Один раз видел как на ноутбуке экран отключился.

• Не подготовили документы легитимизации.

Ну это «база». Документы в компании ИБ внедряет не только по требованию законодательства, но и чтобы самим «не надуло». И очень важно понимать что и зачем ты делаешь с ИБ инструментами. Об этом можно отдельный большой пост написать, тут приведу пример как может быть если ничего не делать и действовать бездумно; все совпадения случайны.

В организации используют DLP, но совсем не внедряют документы. Обнаруживают что сотрудник мало того, что раздолбай, так ещё и регулярно выгружает отчёты из CRM себе на флэшку и уносит домой. Сотрудника призывают в кабинет СБ, показывают фактуру и предлагают выйти из кабинета на улицу подписав заявление «по собственному». Красиво звучит? Вроде как нашил злодея и «выкинули на мороз». Что же будет дальше?

А дальше этот сотрудник очень медленно идёт в трудовую. Когда приходит – пишет заявление в трудовой что на прошлой работе на него оказывали давление используя средства сбора информации на обработку которыми он не давал согласие. Трудовая радостно идёт за «своей палкой», проводит проверку в организации и постановляет:

— Гражданина на работе восстановить

— Время с момента увольнения до дня восстановления оплатить в моменте

— Должностных лиц оштрафовать

— Организацию оштрафовать

И потом этого сотрудника будет сложно уволить повторно, а видеть его «в коридорах» придётся.

В общем, если кратко, документы должны внятно описать что можно делать, а что нельзя; кто за что отвечает; что рабочее — это рабочее, а личное — это личное, и они не пересекаются; что ведётся автоматизированная обработка информации для целей бизнеса.

• Установленная система замедлила работу АРМ сотрудников и вызвала волну недовольства.

Нужно понимать, что ИБ для бизнеса, а не бизнес — полигон для экспериментов ИБ. Поэтому важно внедрять инструменты ИБ обдумано и только после пилотирования на разных группах сотрудников и на разных ПК с разными рабочими сценариями. Любой дополнительный инструмент на АРМ или сети — «не бесплатен». На АРМ его работа будет потреблять процессор, оперативную память и скорость диска; а в сети — снижать скорость.

Например, видел, как в организации где у сотрудников были HDD диски на терабайт почти полностью занятые excel файлами и pdf документами включение сканирования DCAP в рабочий день парализовало работу организации.

Но нужно знать и обратную «сторону медали». После того, как сотрудники узнают, что в организации внедрили DLP — один из самых популярных тикетов в свою поддержку «У меня теперь всё тормозит». Естественно мы с клиентами проводили эксперимент: сообщали сотрудникам о внедрении системы, но агентов устанавливали не везде. А затем с интересом наблюдали за эмоциональными рассказами как всё резко изменилось в день новости и теперь работать стало невозможно и именно поэтому сотрудник не выполняет свои задачи от тех сотрудников, у которых нет агента.

• Купили и никому не сказали и пользуются только одни.

Это не совсем фейл, это больше отсутствие бережливого производства. Доступом к SIEM можно делиться с ИТ, а данными из DLP — с HR. Купив систему один раз и раздав нужные доступы другим подразделениям мы переиспользуем инструменты для дополнительной выгоды.

Например, логично настроить доступы к DLP так, чтобы:

— HR видели несколько важных им отчётов по УРВ, поиску работы, «температре», по всем сотрудникам.

— Руководители подразделений имели доступ ко всем данным, но только по своим сотрудникам.

— ТОП-ы — изучали дашборды верхнего уровня с метриками здоровья и рисков.

• Не читали документацию.

Да, её пишут. Некоторые вендоры пишут как «разработчик для разработчика» и простому человеку её читать непонятно и неудобно; но видел написанное как хорошую понятную книгу. А некоторые современные движки делают навигацию и поиск очень полезными.

Заглянуть в документацию нужно как минимум по двух поводам:

—️ Документацию для клиента пишут точно не лучше, чем внутреннюю. Вот и задумайтесь как у вендора внутри всё организовано.

— Чтоб не попасть в ситуацию с фейлом про домыслы.

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

Примеров не будет, просто помните, «помогают раздеться до секса, а после секса вряд ли вам помогут одеться». Обязательно во время пилота пообщайтесь с тех. поддержкой и узнавайте больше про работу отделок у вендора / интегратора который будет работать с вами после покупки.