Звучит красиво, но на самом деле такая система неработоспособна. В достаточно крупном офисе по почте летают сотни вложений в день. Если хотя бы половину этих вложений должен будет проверять администратор системы — он сопьется через месяц от такой работенки. :)
На самом деле, это сильно зависит от того, насколько адекватны политики безопасности и насколько тщательно классифицированы защищаемые документы. У нас есть достаточно много заказчиков, у которых DLP стоит «в разрыв». Но Вы правы в том, что большинство все-таки предпочитает режим мониторинга — и ровно по тем причинам, которые Вы описали.
При этом и мониторинг работает на безопасность, хотя и не так прямо, как блокировка, например:
Есть функция уведомления пользователей о нарушении политики безопасности. Система сообщает человеку, что некое его действие выглядит как нарушение, и просит подтвердить, что оно легитимно и должно быть продолжено. Это снижает число случайных утечек (например, человек поставил в копию письма лишнего адресата).
Есть функция, позволяющая модифицировать письмо, исключая из него лишних получателей или даже изменяя вложение (пример использования мы описали вот тут)
Если DLP не просто внедрена «для галочки», а реально используется безопасником, который оперативно просматривает алерты, то даже уведомление о том, что сотрудник только что скопировал коммерческую тайну на флешку, позволяет предотвратить утечку.
Собственно, большинство технологий, которыми дополнялись DLP в последние годы, направлены на то, чтобы сделать мониторинг более полезным для человека, работающего с системой. Очевидно, можно ранжировать инциденты по критичности (так-то и посещение развлекательных ресурсов можно завести как инцидент, но понятно, что пересылка комтайны за периметр гораздо важнее).
Критичность может зависеть от типа информации, которая находится под угрозой, (и здесь все относительно просто), а может — от конкретного человека и его действий. Например, сравните: один сотрудник копирует часть клиентской базы, а другой, уже написавший заявление на увольнение, — всю.
В попытке научить систему понимать, что второй инцидент важнее, большинство вендоров пришло к тому, что у нас называется «группы особого контроля», у конкурентов, если не ошибаюсь, «группы под подозрением». Это группы людей, которых система в результате их действий автоматически считает более вероятными нарушителями (о наших алгоритамх мы писали вот здесь).
Сейчас вендоры ищут разные подходы, которые позволят системе с адекватной степенью достоверности определять высококритичный инцидент, чтобы безопасник мог моментально принять меры.
И еще, конечно, человеческая психология такова, что часто уже само знание о том, что в компании установлена DLP, удерживает людей от некоторых поступков.
Насчет запароленных — это вы пошутили, наверное. Если пароль не присутствует в тексте письма, то на подбор пароля никаких серверных мощностей не хватит.
Тогда, конечно, напишем. О некоторых мы уже рассказывали, кстати.
Почему мы рассказываем и о таких историях, как в этой статье: дело в том, что сейчас функционал DLP позволяет выявить не только утечки, но и различного рода мошенничества/откаты у заказчиков. Конкретно здесь собраны забавные кейсы, где компании очень уж сильно не страдают, но вообще прямое воровство денег на откатах часто наносит компании ущерб не меньший, чем воровство информации.
Сейчас как раз DLP-решения выходят на новый и довольно любопытный виток развития — появляются технологии User Behavior Analytics, идут исследования в области применения нейросети в DLP и много чего еще. Хотя при этом до сих пор идет борьба с ложными срабатываниями (мы тоже писали о том, как мы с этим работаем — 1,2).
Мотивом для внедрения DLP служит все-таки не желание «прижать» сотрудников и почитать их переписку, а стремление обезопасить данные, которыми компания оперирует.
Например, большинство банков внедряет DLP, потому они хранят и обрабатывают огромные объемы персональных данных клиентов. Утечка, о которой стало известно, — это и репутационные риски, и уход разгневанных клиентов к конкурентам, и проверки Роскомнадзора.
А так DLP — система не дешевая и во внедрении не самая простая. Едва ли кто-то станет так заморачиваться только чтобы читать, о чем сотрудники с женами разговаривают.
Собственно, в начале статьи и была оговорка о том, что это редкие и необычные кейсы, на которые система не заточена. Это не обучающий материал, а скорее развлекательный (ну, должен был быть развлекательным, но, признаем это, вышел скорее холиварным).
Можем в следующий раз рассказать о более классических инцидентах, с которыми наши инженеры внедрения сталкивались на проектах.
Да, письмо блокируется до проверки администратором системы. DLP проверяет и вложения, в том числе архивы, в том числе запароленные. О том, как это устроено технически, мы как раз планируем написать статью.
Да, реакция читателей, безусловно, понятна. Есть такая шутка в среде безопасников, что ДЛП расшифровывается «Для Любителей Подглядывать».
Но, во-первых, сотрудник должен быть информирован под роспись об использовании такого ПО в организации. Речь никогда не идет о тайной «прослушке».
Во-вторых, представление о безопаснике как о человеке, который весь свой рабочий день тратит на чтение чужой переписки, — это миф. Организации менее 300 сотрудников вообще редко внедряют DLP, а представьте, сколько трафика они ежедневно генерируют.
Офицер безопасности реагирует исключительно на алерты, которые присылает ему система (и то не на все, потому что, как и другие системы защиты, DLP часто фолсят). Собственно, с реакции на уведомление от DLP начинается каждый из приведенных кейсов. Алерты же генерируются в результате нарушений политик безопасности.
Наконец, DLP защищает от внутренних нарушителей не только компании, но и их клиентов, доверяющих этим компаниям персональные данные. Этим клиентом может оказаться любой из нас. Да, как и многие вещи в мире, DLP может быть использована не по назначению, но не стоит лишь на этом основании демонизировать ее как класс.
Цели разделить людей на «плохих» и «хороших» не стоит, человек может скомпрометировать конфиденциальные данные и по ошибке. Задача DLP – защитить информацию либо помочь в проведении расследования.
Перед внедрением почти любого средства защиты по предотвращению утечки информации, происходит оценка стоимости цифровых активов и прогнозируется потенциальный ущерб в случае их компрометации. Эта информация, в сравнении со стоимостью внедрения и эксплуатации средства защиты ( в нашем случае DLP) и ложится в основу экономической оценки или эффективности проекта (ТЭО/ФЭО). Данную процедуру проводит большинство наших заказчиков самостоятельно, либо нанимают соответствующие организации.
Перед внедрением DLP-подобных систем с сотрудником заключает дополнительное соглашение к трудовому договору, в котором указывают перечень целей, в рамках которых сотрудник может использовать корпоративное оборудование. Так, дается определение термину «коммуникации» и описывается право компании на контроль некоторых «коммуникаций» в определенных ситуациях. Более подробно о правилах внедрения DLP мы рассказывали вот в этой статье.
Интересно было бы еще увидеть ваши рассуждения касательно обоснования целесообразности защит, поскольку, как я уже сказал выше, часто разговоры о безопасности разбиваются о «Да кому мы вообще нужны, чтобы нас ломать»
Наши диалоги с заказчиками и соответствующие обоснования сильно разнятся в зависимости от конкретного предприятия. Например, в некоторых случаях потенциальные последствия успешной атаки на АСУ ТП настолько ужасны, что рассуждать в классической парадигме в принципе неправильно.
А есть, конечно, менее критичные объекты, и в этом случае мы апеллируем и к реальным инцидентам на аналогичных предприятиях, и, если есть возможность, к инцидентам в периметре данной компании, и к требованиям регуляторов, наконец.
«Да зачем оно надо, если злоумышленникам проще и эффективнее внедрить/подкупить своего человека на месте».
А человек на месте — это история чуть другой безопасности, и как раз она, по нашему опыту, на критичных объектах на должном уровне.
Давайте будем оптимистами. Тем более, мы с вами видим рост спроса на квалифицированные кадры в области обеспечения ИБ в АСУ ТП. Среди задач, которые ставятся перед этими людьми, помимо соответствия требованиям, мы видим задачи обеспечения реальной безопасности, снижения рисков ИБ за счет применения организационных и технических мер.
Так что скорее все же движемся в светлое будущее)
Ситуации бывают разные, и, как показывает практика, кому-то будет мало и двух «Петь» подряд. Но сейчас мы видим значительно меньше подобных кейсов. Это следствие не только «Пети» и активных действий государства и регуляторов, а скорее даже совокупного движения компаний в сторону повышения уровня зрелости в вопросах обеспечения ИБ.
К счастью или к сожалению, но это не всегда возможно. И даже из таких самых сложных ситуаций есть выход. Но в целом в последнее время ситуация с безопасностью АСУ ТП улучшается. Мы все чаще видим, что в ТЗ на создаваемые и модернизируемые системы закладываются требования по обеспечению ИБ.
И такое устойчивое мнение – одна из причин появления нашей статьи. Забегая немного вперед, скажу, что мы считаем, что «слона надо есть по частям», понемногу приучая производство к безопасности.
При этом и мониторинг работает на безопасность, хотя и не так прямо, как блокировка, например:
Собственно, большинство технологий, которыми дополнялись DLP в последние годы, направлены на то, чтобы сделать мониторинг более полезным для человека, работающего с системой. Очевидно, можно ранжировать инциденты по критичности (так-то и посещение развлекательных ресурсов можно завести как инцидент, но понятно, что пересылка комтайны за периметр гораздо важнее).
Критичность может зависеть от типа информации, которая находится под угрозой, (и здесь все относительно просто), а может — от конкретного человека и его действий. Например, сравните: один сотрудник копирует часть клиентской базы, а другой, уже написавший заявление на увольнение, — всю.
В попытке научить систему понимать, что второй инцидент важнее, большинство вендоров пришло к тому, что у нас называется «группы особого контроля», у конкурентов, если не ошибаюсь, «группы под подозрением». Это группы людей, которых система в результате их действий автоматически считает более вероятными нарушителями (о наших алгоритамх мы писали вот здесь).
Сейчас вендоры ищут разные подходы, которые позволят системе с адекватной степенью достоверности определять высококритичный инцидент, чтобы безопасник мог моментально принять меры.
Напишем об этом.
Почему мы рассказываем и о таких историях, как в этой статье: дело в том, что сейчас функционал DLP позволяет выявить не только утечки, но и различного рода мошенничества/откаты у заказчиков. Конкретно здесь собраны забавные кейсы, где компании очень уж сильно не страдают, но вообще прямое воровство денег на откатах часто наносит компании ущерб не меньший, чем воровство информации.
Сейчас как раз DLP-решения выходят на новый и довольно любопытный виток развития — появляются технологии User Behavior Analytics, идут исследования в области применения нейросети в DLP и много чего еще. Хотя при этом до сих пор идет борьба с ложными срабатываниями (мы тоже писали о том, как мы с этим работаем — 1,2).
Например, большинство банков внедряет DLP, потому они хранят и обрабатывают огромные объемы персональных данных клиентов. Утечка, о которой стало известно, — это и репутационные риски, и уход разгневанных клиентов к конкурентам, и проверки Роскомнадзора.
А так DLP — система не дешевая и во внедрении не самая простая. Едва ли кто-то станет так заморачиваться только чтобы читать, о чем сотрудники с женами разговаривают.
Можем в следующий раз рассказать о более классических инцидентах, с которыми наши инженеры внедрения сталкивались на проектах.
Но, во-первых, сотрудник должен быть информирован под роспись об использовании такого ПО в организации. Речь никогда не идет о тайной «прослушке».
Во-вторых, представление о безопаснике как о человеке, который весь свой рабочий день тратит на чтение чужой переписки, — это миф. Организации менее 300 сотрудников вообще редко внедряют DLP, а представьте, сколько трафика они ежедневно генерируют.
Офицер безопасности реагирует исключительно на алерты, которые присылает ему система (и то не на все, потому что, как и другие системы защиты, DLP часто фолсят). Собственно, с реакции на уведомление от DLP начинается каждый из приведенных кейсов. Алерты же генерируются в результате нарушений политик безопасности.
Наконец, DLP защищает от внутренних нарушителей не только компании, но и их клиентов, доверяющих этим компаниям персональные данные. Этим клиентом может оказаться любой из нас. Да, как и многие вещи в мире, DLP может быть использована не по назначению, но не стоит лишь на этом основании демонизировать ее как класс.
Перед внедрением почти любого средства защиты по предотвращению утечки информации, происходит оценка стоимости цифровых активов и прогнозируется потенциальный ущерб в случае их компрометации. Эта информация, в сравнении со стоимостью внедрения и эксплуатации средства защиты ( в нашем случае DLP) и ложится в основу экономической оценки или эффективности проекта (ТЭО/ФЭО). Данную процедуру проводит большинство наших заказчиков самостоятельно, либо нанимают соответствующие организации.
А о чем еще Вам было бы интересно почитать?
А есть, конечно, менее критичные объекты, и в этом случае мы апеллируем и к реальным инцидентам на аналогичных предприятиях, и, если есть возможность, к инцидентам в периметре данной компании, и к требованиям регуляторов, наконец.
А человек на месте — это история чуть другой безопасности, и как раз она, по нашему опыту, на критичных объектах на должном уровне.
Так что скорее все же движемся в светлое будущее)