Да, реакция читателей, безусловно, понятна. Есть такая шутка в среде безопасников, что ДЛП расшифровывается «Для Любителей Подглядывать».
Но, во-первых, сотрудник должен быть информирован под роспись об использовании такого ПО в организации. Речь никогда не идет о тайной «прослушке».
Во-вторых, представление о безопаснике как о человеке, который весь свой рабочий день тратит на чтение чужой переписки, — это миф. Организации менее 300 сотрудников вообще редко внедряют DLP, а представьте, сколько трафика они ежедневно генерируют.
Офицер безопасности реагирует исключительно на алерты, которые присылает ему система (и то не на все, потому что, как и другие системы защиты, DLP часто фолсят). Собственно, с реакции на уведомление от DLP начинается каждый из приведенных кейсов. Алерты же генерируются в результате нарушений политик безопасности.
Наконец, DLP защищает от внутренних нарушителей не только компании, но и их клиентов, доверяющих этим компаниям персональные данные. Этим клиентом может оказаться любой из нас. Да, как и многие вещи в мире, DLP может быть использована не по назначению, но не стоит лишь на этом основании демонизировать ее как класс.
Цели разделить людей на «плохих» и «хороших» не стоит, человек может скомпрометировать конфиденциальные данные и по ошибке. Задача DLP – защитить информацию либо помочь в проведении расследования.
Перед внедрением почти любого средства защиты по предотвращению утечки информации, происходит оценка стоимости цифровых активов и прогнозируется потенциальный ущерб в случае их компрометации. Эта информация, в сравнении со стоимостью внедрения и эксплуатации средства защиты ( в нашем случае DLP) и ложится в основу экономической оценки или эффективности проекта (ТЭО/ФЭО). Данную процедуру проводит большинство наших заказчиков самостоятельно, либо нанимают соответствующие организации.
Перед внедрением DLP-подобных систем с сотрудником заключает дополнительное соглашение к трудовому договору, в котором указывают перечень целей, в рамках которых сотрудник может использовать корпоративное оборудование. Так, дается определение термину «коммуникации» и описывается право компании на контроль некоторых «коммуникаций» в определенных ситуациях. Более подробно о правилах внедрения DLP мы рассказывали вот в этой статье.
Интересно было бы еще увидеть ваши рассуждения касательно обоснования целесообразности защит, поскольку, как я уже сказал выше, часто разговоры о безопасности разбиваются о «Да кому мы вообще нужны, чтобы нас ломать»
Наши диалоги с заказчиками и соответствующие обоснования сильно разнятся в зависимости от конкретного предприятия. Например, в некоторых случаях потенциальные последствия успешной атаки на АСУ ТП настолько ужасны, что рассуждать в классической парадигме в принципе неправильно.
А есть, конечно, менее критичные объекты, и в этом случае мы апеллируем и к реальным инцидентам на аналогичных предприятиях, и, если есть возможность, к инцидентам в периметре данной компании, и к требованиям регуляторов, наконец.
«Да зачем оно надо, если злоумышленникам проще и эффективнее внедрить/подкупить своего человека на месте».
А человек на месте — это история чуть другой безопасности, и как раз она, по нашему опыту, на критичных объектах на должном уровне.
Давайте будем оптимистами. Тем более, мы с вами видим рост спроса на квалифицированные кадры в области обеспечения ИБ в АСУ ТП. Среди задач, которые ставятся перед этими людьми, помимо соответствия требованиям, мы видим задачи обеспечения реальной безопасности, снижения рисков ИБ за счет применения организационных и технических мер.
Так что скорее все же движемся в светлое будущее)
Ситуации бывают разные, и, как показывает практика, кому-то будет мало и двух «Петь» подряд. Но сейчас мы видим значительно меньше подобных кейсов. Это следствие не только «Пети» и активных действий государства и регуляторов, а скорее даже совокупного движения компаний в сторону повышения уровня зрелости в вопросах обеспечения ИБ.
К счастью или к сожалению, но это не всегда возможно. И даже из таких самых сложных ситуаций есть выход. Но в целом в последнее время ситуация с безопасностью АСУ ТП улучшается. Мы все чаще видим, что в ТЗ на создаваемые и модернизируемые системы закладываются требования по обеспечению ИБ.
И такое устойчивое мнение – одна из причин появления нашей статьи. Забегая немного вперед, скажу, что мы считаем, что «слона надо есть по частям», понемногу приучая производство к безопасности.
Возможно, в одной из следующих статей по теме. В этом цикле мы планируем рассказать о задачах практической безопасности, не концентрируясь на вопросах регулирования.
Дошедшие до первой линии подозрения на инцидент мы называем кейсами. Где то 85% на этом этапе фильтруется, а инцидентами оказываются около 3-4%.
Такая цифра вызвана тем, что часть показателей (критичность инцидента, хоста и УЗ), влияющих на итоговую критичность, проставляется совместно с клиентами.
Также, как правило, скоуп подключенных источников ограничивается системами с довольно высокой критичностью.
Этой задачей в данный момент как раз занимается команда развития :)
Сейчас часть вопросов автоматизировано в SIEM посредством трендов по ключевым индикаторам компрометации – попробуем описать механизм в отдельной статье.
Но у нас есть несколько идей, которые мы прорабатываем, возможно, поделимся ими чуть позже.
Спасибо, что читаете нас.
Интересен ваш опыт по Incident Response с точки зрения людей.
Насколько я помню по прошлым публикациям у вас есть 2 линии обработки инцидентов. Первая линия «массовка» обрабатывает «типовые» сценарии. Вторая «тру-антихакеров» подключается в сложных случаях. Как обучаете 1-ю линию? Проводите ли «Курс молодого бойца» по разбору инцидентов? Есть ли инструкции на каждый типовой инцидент (при бруте делай то, смотри туда)?
Про это мы чуть позже напишем отдельный материал, но общая механика такая:
Да, первую линию обучаем — и основам информационной безопасности, и опыту работы с логами, и тому как устроены Kill Chain, и какой импакто может лежать за каждым инцидентом.
Инструкции по типовым инцидентам есть, но они не пошаговые — cлишком много сценариев и вариантов. Это скорее описание того, что нужно найти по итогам инцидента, основных мест, где можно анализировать информацию, и того, что обязательно надо проверить (критерии false-positive, обязательная к предоставлению информация по инциденту и т.д.)
Дальше много нюансов, но это уже в отдельной статье :)
А 2 линия «тру-антихакеры» у вас свободные художники которые разбирают APT стоящие вне типовых задач? Какие критерии подключения к делу (порог критичности инцидента) этих более опытных товарищей?
За 2-й линией стоит еще и 3-я, и 4-я, и отдельная команда форенсики, но да, идея примерно такая. У инженеров 2-й линии больше опыта и есть некоторая специализация по задачам. К анализу инцидента они подключаются в нескольких случаях:
когда инцидент априори сложный или еще не обкатан массово по 1-й линии;
когда с заказчиком согласована углубленная аналитика по инциденту;
когда конкретный инженер 1-й линии или не может справиться с задачей, или увидел «странное»;
ну, и наконец, когда очень высока нагрузка и нужно просто помочь 1-й линии. SOC — это командная работа :)
Но, во-первых, сотрудник должен быть информирован под роспись об использовании такого ПО в организации. Речь никогда не идет о тайной «прослушке».
Во-вторых, представление о безопаснике как о человеке, который весь свой рабочий день тратит на чтение чужой переписки, — это миф. Организации менее 300 сотрудников вообще редко внедряют DLP, а представьте, сколько трафика они ежедневно генерируют.
Офицер безопасности реагирует исключительно на алерты, которые присылает ему система (и то не на все, потому что, как и другие системы защиты, DLP часто фолсят). Собственно, с реакции на уведомление от DLP начинается каждый из приведенных кейсов. Алерты же генерируются в результате нарушений политик безопасности.
Наконец, DLP защищает от внутренних нарушителей не только компании, но и их клиентов, доверяющих этим компаниям персональные данные. Этим клиентом может оказаться любой из нас. Да, как и многие вещи в мире, DLP может быть использована не по назначению, но не стоит лишь на этом основании демонизировать ее как класс.
Перед внедрением почти любого средства защиты по предотвращению утечки информации, происходит оценка стоимости цифровых активов и прогнозируется потенциальный ущерб в случае их компрометации. Эта информация, в сравнении со стоимостью внедрения и эксплуатации средства защиты ( в нашем случае DLP) и ложится в основу экономической оценки или эффективности проекта (ТЭО/ФЭО). Данную процедуру проводит большинство наших заказчиков самостоятельно, либо нанимают соответствующие организации.
А о чем еще Вам было бы интересно почитать?
А есть, конечно, менее критичные объекты, и в этом случае мы апеллируем и к реальным инцидентам на аналогичных предприятиях, и, если есть возможность, к инцидентам в периметре данной компании, и к требованиям регуляторов, наконец.
А человек на месте — это история чуть другой безопасности, и как раз она, по нашему опыту, на критичных объектах на должном уровне.
Так что скорее все же движемся в светлое будущее)
Такая цифра вызвана тем, что часть показателей (критичность инцидента, хоста и УЗ), влияющих на итоговую критичность, проставляется совместно с клиентами.
Также, как правило, скоуп подключенных источников ограничивается системами с довольно высокой критичностью.
Сейчас часть вопросов автоматизировано в SIEM посредством трендов по ключевым индикаторам компрометации – попробуем описать механизм в отдельной статье.
Но у нас есть несколько идей, которые мы прорабатываем, возможно, поделимся ими чуть позже.
Спасибо, что читаете нас.
Про это мы чуть позже напишем отдельный материал, но общая механика такая:
Дальше много нюансов, но это уже в отдельной статье :)
За 2-й линией стоит еще и 3-я, и 4-я, и отдельная команда форенсики, но да, идея примерно такая. У инженеров 2-й линии больше опыта и есть некоторая специализация по задачам. К анализу инцидента они подключаются в нескольких случаях: