Меня всегда умиляет эта фраза «регулятор рекомендует». Первое, у нас столько регуляторов, и под всех надо подстраиваться. И второе, если это рекомендации, то почему при проверках они становятся обязательными?
«Рекомендует» — всего лишь повод для торга. Да, при аттестации в соответствии с требованиями будут смотреть на сертификаты, и каким образом осуществляется защита предназначенным для этого ПО. DLP сертифицирован только на НДВ и по сути не относится к СЗИ. То есть функционал DLP остается в стороне при аттестации (исключая специализированные требования) — лишь бы не понижал общий уровень. Поэтому здесь слово «рекомендация» вполне уместно.
Во вступлении, кстати, есть пояснение – «При этом регулятор напрямую не указывает на необходимость применения систем защиты конфиденциальных данных от утечек (DLP). Однако эти системы позволяют выполнить такие требования, как обеспечение конфиденциальности, целостности информации, передаваемой из информационной системы, регистрация событий безопасности и др.»
Но ведь говоря о криптографии, мы должны иметь ввиду российскую криптографию.
Да, но перечисленные в статье средства защиты идут в качестве модулей самой ОС, распространяющейся в РФ официально. Смотрим Положение о лицензировании деятельности по распространению шифровальных (криптографических) средств (утв. постановлением Правительства РФ от 29 декабря 2007 г. N 957)
Настоящее Положение не распространяется на деятельность по распространению:
а) шифровальных (криптографических) средств, предназначенных для защиты информации, содержащей сведения, составляющие государственную тайну;
б) шифровальных (криптографических) средств, являющихся компонентами доступных для продажи без ограничений посредством розничной торговли, либо сделок по почтовым запросам, либо электронных сделок, либо сделок по телефонным заказам программных операционных систем, криптографические возможности которых не могут быть изменены пользователями, которые разработаны для установки пользователем самостоятельно без дальнейшей существенной поддержки поставщиком и техническая документация (описание алгоритмов криптографических преобразований, протоколы взаимодействия, описание интерфейсов и т.д.) на которые является доступной, в том числе для проверки;
в) персональных кредитных карточек со встроенной микроЭВМ, криптографические возможности которых не могут быть изменены пользователями; и т.д.
Коллеги, мы с vilgeforce договорились о взаимно удобном канале связи, подлинную его сюда: подобную информацию можно высылать на soc@rt.ru и cert@rt.ru.
vilgeforce, раздача внутренних почтовых адресов коллег противоречит нашим политикам информационной безопасности. Если Вам действительно есть чем поделиться, напишите, пожалуйста, личное сообщение, и оно не останется без внимания.
Если это будет полезно, конечно, давайте сделаем англоязычную версию. discovan, давайте мы организуем перевод, а Вы верифицируете его корректность. Заодно посмотрим на дивный новый мир — англоязычный Хабр. MunGell, спасибо за идею.
в продолжение — это не считая того, что даже при ручной настройке доступов ситуация остается управляемой:
— для новых сотрудников заявку выдают заранее (до их выхода на работу)
— для дорогих (в прямом смысле) сотрудников — 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). Однако эти системы позволяют выполнить такие требования, как обеспечение конфиденциальности, целостности информации, передаваемой из информационной системы, регистрация событий безопасности и др.»
Да, но перечисленные в статье средства защиты идут в качестве модулей самой ОС, распространяющейся в РФ официально. Смотрим Положение о лицензировании деятельности по распространению шифровальных (криптографических) средств (утв. постановлением Правительства РФ от 29 декабря 2007 г. N 957)
Настоящее Положение не распространяется на деятельность по распространению:
а) шифровальных (криптографических) средств, предназначенных для защиты информации, содержащей сведения, составляющие государственную тайну;
б) шифровальных (криптографических) средств, являющихся компонентами доступных для продажи без ограничений посредством розничной торговли, либо сделок по почтовым запросам, либо электронных сделок, либо сделок по телефонным заказам программных операционных систем, криптографические возможности которых не могут быть изменены пользователями, которые разработаны для установки пользователем самостоятельно без дальнейшей существенной поддержки поставщиком и техническая документация (описание алгоритмов криптографических преобразований, протоколы взаимодействия, описание интерфейсов и т.д.) на которые является доступной, в том числе для проверки;
в) персональных кредитных карточек со встроенной микроЭВМ, криптографические возможности которых не могут быть изменены пользователями; и т.д.
MunGell, спасибо за идею.
В статье речь о новых сотрудниках, которые ждут предоставления доступа. Разумеется, если это не новый сотрудник, разницу в его эффективности до и после предоставления нового доступа оценить сложно.
25% взяли из обоснования одного из промышленных предприятий.
Да, но и не все потери оценили :)
Для «средней» компании соглашусь, оно так и есть. Когда в компании есть заметные всем понятные проблемы, например, тот самый доступ первоначальный неделю-две предоставляют, то оценка будет выглядеть адекватно.
К командировкам и графику у каждого своего отношение. У вас свое мнение, и мы его уважаем. Однако, как нам кажется, об эффективности и «правильности» того или иного процесса лучше всего говорит результат. В нашем случае это самая крепкая, дружная команда на рынке. За все время существования Solar JSOC к конкурентам ушли единицы, и это при том, что наши ребята регулярно получают предложения о вдвое большей зарплате.
Суть же статьи не столько в этих деталях — сколько раз нужно провести личные встречи, сколько раз обучения — сколько в том, что команда остается командой только тогда, когда руководители находятся в контакте с каждым сотрудником и рассматривают его не как винтик в большой машине, а как человека, чьему потенциалу надо помочь раскрыться, чьи ожидания надо постараться оправдать. И вот тогда сплоченности команды не помешает ни расстояние, ни что-то другое.
Безопасность часто конфликтует с удобством пользователей, и здесь очень помогают две вещи: внутренние обучения пользователей и умение обосновать руководству необходимость в ИБ с точки зрения выгоды для бизнеса.
Эта функциональность будет уже осенью.
При этом и мониторинг работает на безопасность, хотя и не так прямо, как блокировка, например:
Собственно, большинство технологий, которыми дополнялись DLP в последние годы, направлены на то, чтобы сделать мониторинг более полезным для человека, работающего с системой. Очевидно, можно ранжировать инциденты по критичности (так-то и посещение развлекательных ресурсов можно завести как инцидент, но понятно, что пересылка комтайны за периметр гораздо важнее).
Критичность может зависеть от типа информации, которая находится под угрозой, (и здесь все относительно просто), а может — от конкретного человека и его действий. Например, сравните: один сотрудник копирует часть клиентской базы, а другой, уже написавший заявление на увольнение, — всю.
В попытке научить систему понимать, что второй инцидент важнее, большинство вендоров пришло к тому, что у нас называется «группы особого контроля», у конкурентов, если не ошибаюсь, «группы под подозрением». Это группы людей, которых система в результате их действий автоматически считает более вероятными нарушителями (о наших алгоритамх мы писали вот здесь).
Сейчас вендоры ищут разные подходы, которые позволят системе с адекватной степенью достоверности определять высококритичный инцидент, чтобы безопасник мог моментально принять меры.
Напишем об этом.