в продолжение — это не считая того, что даже при ручной настройке доступов ситуация остается управляемой:
— для новых сотрудников заявку выдают заранее (до их выхода на работу)
— для дорогих (в прямом смысле) сотрудников — vip'ов — требования к срокам и приоритет заявок на доступ отличается от рядовых сотрудников => потери, если и будут, то для наименее оплачиваемых сотрудников.
Действительно, такая практика встречается, но далеко не везде.
— вы уверены, что эффективность сотрудника без нового доступа 50%? Вот так работал-работал он на 100%, тут ему расширили круг обязанностей, а доступ не дали и — хоп! — еще вчера 100% эффективность стала вдруг 50%-ной.
В статье речь о новых сотрудниках, которые ждут предоставления доступа. Разумеется, если это не новый сотрудник, разницу в его эффективности до и после предоставления нового доступа оценить сложно.
— оценка времени на предоставление доступа, как 25% — это тоже «с потолка» (о чем вы честно и пишите, но вы же это совсем-совсем «с потолка» используете для ФЭО). Доступ к типовым системам предоставляется в течении минут — от 15 мин — чудо — до 1ч.
25% взяли из обоснования одного из промышленных предприятий.
25% взяли из обоснования одного из промышленных предприятий.
— нет оценки стоимости простоя системы (а он будет — у вас же SLA не 100%.
Да, но и не все потери оценили :)
То есть, моя мысль такая: сокращение затрат/увеличение выручки за счет сокращения времени на предоставление доступа сотрудникам есть, оценить его достаточно сложно; при этом финансовая оценка экономии вряд ли будет корректной и сомнительно (для меня), что она убедит стейкхолдеров.
Для «средней» компании соглашусь, оно так и есть. Когда в компании есть заметные всем понятные проблемы, например, тот самый доступ первоначальный неделю-две предоставляют, то оценка будет выглядеть адекватно.
Цифры достаточно условные, они даны просто для наглядности расчета, но каждый коэффициент взят с какого-либо реального проекта. Если кредитный эксперт или сотрудник службы поддержки реально неделю-две ждёт предоставления доступа, то потери существенны, и за это время такие сотрудники могли бы действительно что-то нагенерить.
Насильно привести человека к счастью, как известно, невозможно. Мы это хорошо понимаем, и все «тимбилдинговые» активности (вроде «Что? Где Когда?») являются добровольными, ведь организуются они ради людей.
К командировкам и графику у каждого своего отношение. У вас свое мнение, и мы его уважаем. Однако, как нам кажется, об эффективности и «правильности» того или иного процесса лучше всего говорит результат. В нашем случае это самая крепкая, дружная команда на рынке. За все время существования Solar JSOC к конкурентам ушли единицы, и это при том, что наши ребята регулярно получают предложения о вдвое большей зарплате.
Суть же статьи не столько в этих деталях — сколько раз нужно провести личные встречи, сколько раз обучения — сколько в том, что команда остается командой только тогда, когда руководители находятся в контакте с каждым сотрудником и рассматривают его не как винтик в большой машине, а как человека, чьему потенциалу надо помочь раскрыться, чьи ожидания надо постараться оправдать. И вот тогда сплоченности команды не помешает ни расстояние, ни что-то другое.
Это каждый трактует по-своему, но мы для себе решили, что граница проходит там, где требуется вмешательство человека, будь то инженер первой линии мониторинга, аналитик или заказчик (в зависимости от кейса).
Если бот постучался на ssh/22, это классифицируется как событие информационной безопасности, а не кибератака. Шум интернета действительно велик, и он вносит свой вклад в цифру 28 млрд событий ИБ, ежесуточно обрабатываемых SIEM-системой.
Да, тут не совсем корректная формулировка в тексте (в аудио вроде все так). Задача была не просто сравнить а еще и «склеить» воедино. Поэтому банальные способы типа total commander и notepad++ не работали.
Это очень хороший совет, но, к сожалению, не для этого инцидента. Тут нюанс истории был ровно в том, что созданный fake агент антивируса действительно периодически стучался в центр управления и демонстрировал собственную «живость». Наверняка его можно было бы «обмануть», послав какую-то нестандартную команду из центра управления, и он бы отреагировал неадекватно, но до этого дело при расследовании не дошло :)
Отчего же, очень верим. По нашему опыту, многие атаки происходят потому, что кому-то в компании «на минутку» открыли доступ в интернет в обход прокси, а потом забыли закрыть, пользователь обладал правами администратора на машине, но не знал азов ИБ и т.д.
Безопасность часто конфликтует с удобством пользователей, и здесь очень помогают две вещи: внутренние обучения пользователей и умение обосновать руководству необходимость в ИБ с точки зрения выгоды для бизнеса.
Звучит красиво, но на самом деле такая система неработоспособна. В достаточно крупном офисе по почте летают сотни вложений в день. Если хотя бы половину этих вложений должен будет проверять администратор системы — он сопьется через месяц от такой работенки. :)
На самом деле, это сильно зависит от того, насколько адекватны политики безопасности и насколько тщательно классифицированы защищаемые документы. У нас есть достаточно много заказчиков, у которых DLP стоит «в разрыв». Но Вы правы в том, что большинство все-таки предпочитает режим мониторинга — и ровно по тем причинам, которые Вы описали.
При этом и мониторинг работает на безопасность, хотя и не так прямо, как блокировка, например:
Есть функция уведомления пользователей о нарушении политики безопасности. Система сообщает человеку, что некое его действие выглядит как нарушение, и просит подтвердить, что оно легитимно и должно быть продолжено. Это снижает число случайных утечек (например, человек поставил в копию письма лишнего адресата).
Есть функция, позволяющая модифицировать письмо, исключая из него лишних получателей или даже изменяя вложение (пример использования мы описали вот тут)
Если DLP не просто внедрена «для галочки», а реально используется безопасником, который оперативно просматривает алерты, то даже уведомление о том, что сотрудник только что скопировал коммерческую тайну на флешку, позволяет предотвратить утечку.
Собственно, большинство технологий, которыми дополнялись DLP в последние годы, направлены на то, чтобы сделать мониторинг более полезным для человека, работающего с системой. Очевидно, можно ранжировать инциденты по критичности (так-то и посещение развлекательных ресурсов можно завести как инцидент, но понятно, что пересылка комтайны за периметр гораздо важнее).
Критичность может зависеть от типа информации, которая находится под угрозой, (и здесь все относительно просто), а может — от конкретного человека и его действий. Например, сравните: один сотрудник копирует часть клиентской базы, а другой, уже написавший заявление на увольнение, — всю.
В попытке научить систему понимать, что второй инцидент важнее, большинство вендоров пришло к тому, что у нас называется «группы особого контроля», у конкурентов, если не ошибаюсь, «группы под подозрением». Это группы людей, которых система в результате их действий автоматически считает более вероятными нарушителями (о наших алгоритамх мы писали вот здесь).
Сейчас вендоры ищут разные подходы, которые позволят системе с адекватной степенью достоверности определять высококритичный инцидент, чтобы безопасник мог моментально принять меры.
И еще, конечно, человеческая психология такова, что часто уже само знание о том, что в компании установлена DLP, удерживает людей от некоторых поступков.
Насчет запароленных — это вы пошутили, наверное. Если пароль не присутствует в тексте письма, то на подбор пароля никаких серверных мощностей не хватит.
Тогда, конечно, напишем. О некоторых мы уже рассказывали, кстати.
Почему мы рассказываем и о таких историях, как в этой статье: дело в том, что сейчас функционал DLP позволяет выявить не только утечки, но и различного рода мошенничества/откаты у заказчиков. Конкретно здесь собраны забавные кейсы, где компании очень уж сильно не страдают, но вообще прямое воровство денег на откатах часто наносит компании ущерб не меньший, чем воровство информации.
Сейчас как раз DLP-решения выходят на новый и довольно любопытный виток развития — появляются технологии User Behavior Analytics, идут исследования в области применения нейросети в DLP и много чего еще. Хотя при этом до сих пор идет борьба с ложными срабатываниями (мы тоже писали о том, как мы с этим работаем — 1,2).
Мотивом для внедрения DLP служит все-таки не желание «прижать» сотрудников и почитать их переписку, а стремление обезопасить данные, которыми компания оперирует.
Например, большинство банков внедряет DLP, потому они хранят и обрабатывают огромные объемы персональных данных клиентов. Утечка, о которой стало известно, — это и репутационные риски, и уход разгневанных клиентов к конкурентам, и проверки Роскомнадзора.
А так DLP — система не дешевая и во внедрении не самая простая. Едва ли кто-то станет так заморачиваться только чтобы читать, о чем сотрудники с женами разговаривают.
Собственно, в начале статьи и была оговорка о том, что это редкие и необычные кейсы, на которые система не заточена. Это не обучающий материал, а скорее развлекательный (ну, должен был быть развлекательным, но, признаем это, вышел скорее холиварным).
Можем в следующий раз рассказать о более классических инцидентах, с которыми наши инженеры внедрения сталкивались на проектах.
Да, письмо блокируется до проверки администратором системы. DLP проверяет и вложения, в том числе архивы, в том числе запароленные. О том, как это устроено технически, мы как раз планируем написать статью.
В статье речь о новых сотрудниках, которые ждут предоставления доступа. Разумеется, если это не новый сотрудник, разницу в его эффективности до и после предоставления нового доступа оценить сложно.
25% взяли из обоснования одного из промышленных предприятий.
Да, но и не все потери оценили :)
Для «средней» компании соглашусь, оно так и есть. Когда в компании есть заметные всем понятные проблемы, например, тот самый доступ первоначальный неделю-две предоставляют, то оценка будет выглядеть адекватно.
К командировкам и графику у каждого своего отношение. У вас свое мнение, и мы его уважаем. Однако, как нам кажется, об эффективности и «правильности» того или иного процесса лучше всего говорит результат. В нашем случае это самая крепкая, дружная команда на рынке. За все время существования Solar JSOC к конкурентам ушли единицы, и это при том, что наши ребята регулярно получают предложения о вдвое большей зарплате.
Суть же статьи не столько в этих деталях — сколько раз нужно провести личные встречи, сколько раз обучения — сколько в том, что команда остается командой только тогда, когда руководители находятся в контакте с каждым сотрудником и рассматривают его не как винтик в большой машине, а как человека, чьему потенциалу надо помочь раскрыться, чьи ожидания надо постараться оправдать. И вот тогда сплоченности команды не помешает ни расстояние, ни что-то другое.
Безопасность часто конфликтует с удобством пользователей, и здесь очень помогают две вещи: внутренние обучения пользователей и умение обосновать руководству необходимость в ИБ с точки зрения выгоды для бизнеса.
Эта функциональность будет уже осенью.
При этом и мониторинг работает на безопасность, хотя и не так прямо, как блокировка, например:
Собственно, большинство технологий, которыми дополнялись DLP в последние годы, направлены на то, чтобы сделать мониторинг более полезным для человека, работающего с системой. Очевидно, можно ранжировать инциденты по критичности (так-то и посещение развлекательных ресурсов можно завести как инцидент, но понятно, что пересылка комтайны за периметр гораздо важнее).
Критичность может зависеть от типа информации, которая находится под угрозой, (и здесь все относительно просто), а может — от конкретного человека и его действий. Например, сравните: один сотрудник копирует часть клиентской базы, а другой, уже написавший заявление на увольнение, — всю.
В попытке научить систему понимать, что второй инцидент важнее, большинство вендоров пришло к тому, что у нас называется «группы особого контроля», у конкурентов, если не ошибаюсь, «группы под подозрением». Это группы людей, которых система в результате их действий автоматически считает более вероятными нарушителями (о наших алгоритамх мы писали вот здесь).
Сейчас вендоры ищут разные подходы, которые позволят системе с адекватной степенью достоверности определять высококритичный инцидент, чтобы безопасник мог моментально принять меры.
Напишем об этом.
Почему мы рассказываем и о таких историях, как в этой статье: дело в том, что сейчас функционал DLP позволяет выявить не только утечки, но и различного рода мошенничества/откаты у заказчиков. Конкретно здесь собраны забавные кейсы, где компании очень уж сильно не страдают, но вообще прямое воровство денег на откатах часто наносит компании ущерб не меньший, чем воровство информации.
Сейчас как раз DLP-решения выходят на новый и довольно любопытный виток развития — появляются технологии User Behavior Analytics, идут исследования в области применения нейросети в DLP и много чего еще. Хотя при этом до сих пор идет борьба с ложными срабатываниями (мы тоже писали о том, как мы с этим работаем — 1,2).
Например, большинство банков внедряет DLP, потому они хранят и обрабатывают огромные объемы персональных данных клиентов. Утечка, о которой стало известно, — это и репутационные риски, и уход разгневанных клиентов к конкурентам, и проверки Роскомнадзора.
А так DLP — система не дешевая и во внедрении не самая простая. Едва ли кто-то станет так заморачиваться только чтобы читать, о чем сотрудники с женами разговаривают.
Можем в следующий раз рассказать о более классических инцидентах, с которыми наши инженеры внедрения сталкивались на проектах.