Архив рубрики: Публикации

Управление инцидентами ИБ на основе SIEM-систем

По проблеме управления инцидентами пишутся целые книги. Тема эта обширная и жестко зависящая от конкретной организации (процесса). В данной статье предлагаю ограничиться вопросом автоматизации процесса управления инцидентами с помощью SIEM-систем.

Что же такое инцидент?

Процесс управления инцидентами сопряжен с некоторыми трудностями:
Четкое закрепление ролей в процессе. Если в подразделении владельца процесса роли закреплены достаточно четко, то в привлекаемых подразделениях всегда возникает вопрос: кто и как должен реагировать и какие действия совершать? Без этого оперативное реагирование на инцидент и его расследование будут затруднены.

Сбор данных из разных источников. Огромное множество средств защиты и целевых систем ведут собственные журналы в различных форматах. Возникает необходимость в просмотре всех этих источников, в проведении корреляции событий с возможностью построения вектора атаки.
Ограниченность ресурсов. Это ахиллесова пята большинства организаций. Ресурсы (кадровые и технологические) стоят денег, и если вопрос с кадровыми ресурсами можно решить автоматизацией процессов, то без необходимой инфраструктуры – никуда.
Данные препятствия значительны, но не смертельны. Любое из них может быть компенсировано различными организационными мероприятиями.

Данный термин в зависимости от методики определяется довольно широко. Поэтому остановимся на самом простом: инцидент – это любое событие, не являющееся частью нормального функционирования системы/сервиса/процесса. Как следует из определения, все, что не было заложено в логику работы информационной системы, является инцидентом. Сюда же относятся события, связанные с рисками информационной безопасности (потенциальные или свершившиеся).

Следовательно, мы должны сформировать перечень событий, являющихся инцидентами (можно воспользоваться прямым или обратным методом). Необходимо понимать, что все события, которые не войдут в перечень инцидентов, будут рассматриваться как штатные. А следовательно, данные инциденты не будут устранены и могут привести к катастрофическим последствиям.

Инцидентами информационной безопасности могут быть:

  • отказ в обслуживании сервисов, средств обработки информации, оборудования;
  • нарушение конфиденциальности и целостности ценной информации;
  • вредоносные программы и т.д.

Каждый инцидент может быть классифицирован по множеству признаков. Я использую следующие:

  • причина возникновения инцидента (достижение порогового значения, аппаратный сбой и т.п.);
  • объект воздействия инцидента (информационный актив, система или подсистема и т.п.);
  • критичность инцидента;
  • источник инцидента;
  • периодичность (уже происходил или случился впервые);
  • ущерб (денежное выражение свершения инцидента).

Процесс управления инцидентами

Так как инциденты наносят ущерб работоспособности системы (реальный или потенциальный), целесообразно организовать процесс управления ими. Он включает в себя (рис. 1):

  • определение перечня событий, являющихся инцидентами. Это логичнее всего сделать, проведя обследования существующих систем, определив их штатное состояние и риски, которые могут это состояние нарушить;
  • определение факта совершения инцидента информационной безопасности. Осуществляя мониторинг целевых систем, собирая и анализируя события, мы будем находить инциденты;
  • оповещение ответственного лица о возникновении инцидента. Здесь необходимо определить формат отчета, метод информирования, а также отразить контактную информацию лиц, которых следует оповещать об инциденте;
  • порядок устранения последствий и причин инцидента. В идеале данный процесс должен начинаться одновременно с предыдущим этапом;
  • порядок расследования инцидента. Здесь определяется причина инцидента, виновные в возникновении инцидента, порядок сбора и сохранения улик. На данном же этапе принимается решение о привлечении силовых ведомств;
  • вынесение дисциплинарных взысканий;
  • реализация необходимых корректирующих и превентивных мер.

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

  • возможность мониторинга целевых систем и средств защиты с организацией выделенного хранилища инцидентов и log-файлов;
  • расследование инцидентов;
  • возможность получения информации от подразделений (в первую очередь IТ) по произошедшим инцидентам с высокой важностью реагирования и предоставления информации;
  • полномочия по форс-мажорному исправлению последствий инцидентов с привлечением необходимых специалистов других подразделений;
  • возможность создания корректирующих мер.

Сложности реализации процесса управления инцидентами

Процесс управления инцидентами сопряжен с некоторыми трудностями:

Четкое закрепление ролей в процессе. Если в подразделении владельца процесса роли закреплены достаточно четко, то в привлекаемых подразделениях всегда возникает вопрос: кто и как должен реагировать и какие действия совершать? Без этого оперативное реагирование на инцидент и его расследование будут затруднены.

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

Ограниченность ресурсов. Это ахиллесова пята большинства организаций. Ресурсы (кадровые и технологические) стоят денег, и если вопрос с кадровыми ресурсами можно решить автоматизацией процессов, то без необходимой инфраструктуры – никуда.

Данные препятствия значительны, но не смертельны. Любое из них может быть компенсировано различными организационными мероприятиями.

Автоматизация процесса управления инцидентами

Учитывая обилие целевых систем, возможных инцидентов и рисков, мы получаем огромное множество параметров, которые необходимо отслеживать. Делать это вручную не представляется возможным. Нам нужен централизованный мониторинг, который сможет определять инциденты, складывающиеся из штатных событий. Другими словами, мы должны автоматизировать процесс управления инцидентами (рис. 2).

Система управления событиями – это глубоко интегрированная с другими процессами система. Разумеется, большинство этапов можно сделать локальными, но тогда серьезно снизится эффективность автоматизации.

Ядром автоматизации является SIEM-система. Помимо джентльменского набора функций (сбор и анализ событий; ранжирование событий и инцидентов; корреляция полученных данных на предмет определения комплексных атак, а также атак, распределенных по времени; визуализация полученных данных в реальном времени и оповещение операторов системы об инцидентах и об элементах сети, вовлеченных в атаку) SIEM-система должна дополнительно уметь:

  • Подключать любые IP-системы и устройства. Если мы не можем направить поток событий в SIEM лишь потому, что у нас самописная система, дорого и трудно разрабатываются коннекторы или необходимо обращаться в штаб-квартиру на другом конце света, то зачем нужна такая система?
  • Подключать отечественные средства защиты. Учитывая специфику отечественной информационной безопасности, необходимо понимать, что немногие организации могут обойтись только западными вендорами.
  • Работать с Service Desk. SIEM должна уметь генерировать заявки об инцидентах и отслеживать их выполнение. Во-первых, это позволяет сократить время реагирования; во-вторых, вовремя необработанный инцидент – это тоже инцидент.
  • Инициировать управляющее воздействие. Необязательная, но крайне полезная функция. Существует много ситуаций, когда решение по инциденту должно быть произведено быстро. Например, изоляция рабочей станции от локальной сети организации путем «выключения» порта на маршрутизаторе для последующего разбирательства. Данная функция требует деликатного обращения, поэтому ее использование целесообразно после прохождения этапа решения ошибок 1-го и 2-го рода.
  • Организовывать инвентаризацию существующих и поиск новых информационных активов. Не существует статичных организаций, поэтому, если мы не имеем текущей картины существующих активов, наш процесс управления событиями будет иметь белые пятна, о которых он ничего не знает. Если карта активов хранится в SIEM-системе, она должна уметь поддерживать их в актуальном состоянии.

Необходимые документы

В завершение хотелось бы коснуться темы необходимых регламентирующих документов. Разумеется, ни один процесс не будет эффективным, если он не находит поддержки у топ-менеджмента. Если у вас такая поддержка есть, то вам необходимо ввести ряд документов, начав с политики управления инцидентами. В данной политике отражаются область действия процесса, вовлеченные в него подразделения, сферы ответственности, время реагирования, формы отчетности и т.п. В регламенте процесса фиксируются процедуры по управлению инцидентами на каждом из этапов для всех вовлеченных подразделений. Далее при необходимости создаются должностные инструкции, журналы учета и т.п.

Управление инцидентами – это составная часть комплексной безопасности организации. Если вы не управляете инцидентами, то это можно сравнить с тем, как если бы вы ехали на автомобиле и не знали, когда у вас кончится бензин.

Дудко Дмитрий
Опубликовано: Журнал «Information Security/ Информационная безопасность» #3, 2014

Нужен ли вам IDM?

Системам Identity Manager (IDM) уже без малого 10 лет. За это время они прошли значительный путь в своем развитии. IDM – это системы, которые призваны автоматизировать процесс управления учетными записями. Цель, безусловно, благая – управлять однообразным и рутинным процессом по созданию, изменению и блокированию учетных записей, освободить административные ресурсы, избавиться от “мертвых душ» и т.п. Но так ли все радужно, как утверждают вендоры и интеграторы? Когда и кому выгодно внедрять IDM?

Предоставление доступа – это процесс

Казалось бы, мысль банальная. Но за этой мыслью скрывается огромный фронт работ. Во-первых, если это процесс, он должен быть описан и понятен. У процесса есть начало (вход процесса) и конец (выход процесса). Давайте изобразим для начала процесс предоставления доступа на примере одного из банков, в котором IDM так и не был внедрен. Банк крупный, более 5 тыс. человек, 7/8 из которых работают в двух основных информационных системах. Всего систем не более десятка. IT-департамент хотел бы, чтобы процесс предоставления доступа начинался из кадровой системы, далее переходил на этап согласования со всеми заинтересованными сторонами, заявке назначалась соответствующая роль и предоставлялся соответствующий доступ к целевым системам. В то же время ИБ-департамент контролирует процесс согласования и выполняет верификацию выполненных прав доступа.

На рис. 1 представлена желаемая автоматизация процесса предоставления доступа при приеме и увольнении сотрудников.

Нужен ли вам IDM? Рисунок 1

Если же у нас происходит изменение роли пользователя (рис. 2), то IDM должна получать управляющее воздействие из Service Desk после этапа согласования.

Вроде все просто, но решение о внедрении IDM Нужен ли вам IDM? Рисунок 2не принято (о чем мы подробнее поговорим ниже). В данный момент процесс работает без IDM, хоть и не без проблем. Таким образом, IDM должна легко адаптироваться в существующую схему работы.

IDM стоит дорого. Несмотря на то что IDM-решения присутствуют на рынке довольно давно, стоят они как самолет. Высокая стоимость лицензий на программное обеспечение дополняется стоимостью работ по внедрению и кастомизации. Сюда же необходимо добавить техническое сопровождение. Рынок не стоит на месте – уже сейчас есть предложения даже от отечественных вендоров. Тренд рынка IDM устремился в средний бизнес.

Во-вторых, процессы динамически развиваются. То есть IDM должна изменяться вместе с другими элементами процесса – информационными системами и организационной частью.

В-третьих, автоматизация процесса должна оптимизировать время (и расходы) обслуживания процесса.

К сожалению, у IDM по всем пунктам появляются сложности.

Организационные проблемы

Все IDM используют ролевую модель предоставления доступа. Это хорошо и правильно. Каждый сотрудник должен иметь права, соответствующие его роли и должностным обязанностям.

И здесь появляется «но». Разработка ролевой модели – чрезвычайно трудоемкий процесс, который может не закончиться никогда. Суть модели в том, что для каждой уникальной должности нужно составить свою роль, обладающую необходимым набором прав доступа к информационным системам. Причем в идеальной ситуации одинаковые должности соответствуют одной роли. На практике же сотрудники, занимающие одинаковые должности, могут иметь разные роли за счет дополнительных должностных обязанностей. Поэтому для того, чтобы определить соответствующие роли, необходимо получить соответствующую техническую информацию, «выгрузку» по правам из информационных систем, опросить администраторов информационных систем (или их отдельных модулей), администраторов информационной безопасности и владельцев ресурсов (руководителей бизнес-подразделений). А затем свести все в единую матрицу и согласовать ее со всеми участниками предыдущего процесса и с руководством заказчика.

Например, в банке трижды пробовали составить ролевую модель. И каждый раз она становилась неактуальной после ее создания. Многие компании тяжело укладываются в строго определенные рамки, и причины этого самые разные.

Если вы можете создать актуальную ролевую модель, значит вы можете описать процесс предоставления доступа. И вы переходите к выбору решения.

Проблемы внедрения

Необходимо сказать сразу, IDM-решения – не «коробочный» продукт. Из «коробки» IDM работает с узким кругом систем. Если вам необходимо управлять учетными записями в AD, почте и СУБД, вам скорее всего хватит базового функционала. Но, например, в банке необходима интеграция с 1С, не самым популярным Service Desk, и программой, которая не поддерживает даже LDAP-каталоги, не говоря уже о большем.

А ведь IDM должен быть глубоко интегрирован в информационные системы. Подключение разнообразных систем, конечно, производится с помощью коннекторов, через которые ядро IDM работает с информационными системами. Лучше, если коннектор разрабатывает сам вендор. Вы верите, что крупный западный вендор будет разрабатывать коннектор для отечественных систем? Или что стоимость такого коннектора будет разумной?

Нужен ли вам IDM? Рисунок 3

Также не стоит забывать, что информационные системы иногда обновляются. Как быстро обновится коннектор? За месяц? Квартал? Лично я знаю лишь одного вендора, который обновляет коннекторы в течение месяца, но этот вендор не производит IDM-решения. Получается, что нам уже приходится выбирать: либо автоматизация управления учетками, либо новый функционал и/или исправленные ошибки в ПО. Думаю, бизнес выберет последнее, ему работать надо.

Таким образом, IDM-решение должно быть кастомизированным, доработанным специально под заказчика. И тут в полный рост встает проблема целесообразности.

Проблема цены

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

Рынок не стоит на месте – уже сейчас есть предложения даже от отечественных вендоров. Тренд рынка IDM устремился в средний бизнес. Давайте вернемся к нашему примеру. Один из отечественных вендоров произвел оценку стоимости внедрения IDM и сделал выводы, что для компании в тысячу человек проект IDM будет стоить $200 тыс. и окупится за 2–3 года. В зависимости от курса цена этого решения 6–8 млн руб. в год. Сумма не такая уж и большая. Но в банке управление доступом занимает 6 человек full time. Как вы понимаете, для создания учетных записей не требуется высокой квалификации, а несложная арифметика подсказывает, что за те же деньги можно было бы нанять еще несколько человек. Это уже сомнительная экономия. А если учесть затраты на поддержание в актуальном состоянии ролевой модели (а учетные записи могут занимать многие и многие книги в Excel), то не проще ли оставить все на ручной обработке, написать пару скриптов, согласование доступа переложить на пользователей и т.п.? Тут требуется серьезное финансовое обоснование и учет специфики каждой отдельной компании.

После решения этих вопросов переходим к вопросам безопасности.

Необходимый функционал

IDM должен включать механизмы контроля и верификации предоставленных прав в целевых системах. Данный функционал заявлен в самой идеологии IDM, но часто либо не реализован, либо поставляется отдельно.

IDM должен избавить нас от «мертвых душ», убрать лишние права пользователей и т.п. Но все это уже при внедренной IDM. Но все угрозы безопасности существуют в уже работающих системах. Следовательно, должны быть:

  1. механизм выгрузки существующей картины;
  2. механизм наложения ее на необходимую ролевую политику;
  3. коррекция прав доступа и удаление лишних прав.

Увы, но зачастую IDM-решения могут сделать лишь один пункт из трех. Все остальное дается на откуп консультантам и интеграторам, то есть все опять же будет делать человек.

Заключение

IDM-системы необходимы. Большинство описанных проблем кроется в том, что в самом начале, при планировании инфраструктуры и создании бизнес-процессов, никто не задумывался об управлении доступом.

Если вы планируете создание новой инфраструктуры или капитальную модернизацию старой, обязательно внесите в план решение вопросов, связанных с управлением доступом, согласованием выдачи прав и созданием ролевой модели.

Дудко Дмитрий
Опубликовано: Журнал «Information Security/ Информационная безопасность» #2, 2014

Программные средства для управления ИБ и анализа рисков

В век развивающихся технологий найти самые разнообразные программные средства для управления ИБ и анализа рисков – тривиальная задача. Достаточно создать запрос в поисковике, и первой же ссылкой будет страница с необходимым ПО (платным и бесплатным). Там же мы сможем найти подробное описание данного ПО, его оценку по различным параметрам. Так что создавать очередной обзор программных средств нет смысла.

Стоит нам перенестись из теории в прикладную область, здесь мы сталкиваемся с проблемой выбора. Найти подходящие конкретной компании программные средства – вот это уже задача нетривиальная. Как же разобраться во всем многообразии предложений и не ошибиться?

Универсальный инструмент для управления рисками

Когда мы слышим про управление рисками, мы сразу представляем себе большие и не очень перечни, в которых эти самые риски перечислены. В самом простом случае мы получаем примерно то, что показано в табл. 1.

Программные средства для управления ИБ и анализа рисков. Таблица 1

К сожалению, большинство программ требуют много времени на изучение интерфейса. Нивелировать фактор его сложности могут онлайн-курс или видео по основным функциям.

Как вы заметили, использована обычная таблица. Самый распространенный табличный процессор – MS Excel. Примем его за нормированную единицу оценки, поскольку его функционала вполне хватает для определения рисков. Однако каким бы удобным инструментом ни был Excel, у него нет ряда функций. Например, вам никогда не удастся добиться многопользовательского режима работы. Или же в том случае, если количество угроз перевалит за несколько десятков, да еще и потребуется проводить анализ рисков для различных процессов/филиалов/подразделений, количество отслеживаемых зависимостей начинает усложнять работу, а полезный эффект от работы с Excel стремительно уменьшается.

Таким образом, Excel можно использовать на начальном этапе или в тестовых целях, но для работы с рисками он не подойдет.

Что же тогда выбрать?

Не будем рассматривать конкретные продукты, иначе это превратится в переписывание рекламных материалов. Обозначим ключевые требования к программным продуктам для управления рисками.

Интуитивно понятный интерфейс

Казалось бы, куда проще. Уже все заявляют о простоте работы с интерфейсом (рис. 1). Но это, пожалуй, самое главное. Если вы часто работает с Excel, то наверняка столкнулись с нетривиальным расположением привычных разделов и кнопок при выходе новых версий MS Office 2007, 2010 и 2012.

Программные средства для управления ИБ и анализа рисков. Рисунок 1

К сожалению, большинство программ требуют много времени на изучение интерфейса. Нивелировать фактор его сложности помогут онлайн-курс или видео по основным функциям.

Поддержка русского языка

Если вы начнете использовать ПО, основанное на методике иностранного стандарта (ISO 31000 и 27000, FERMA и др.), то рискуете не использовать все доступные функции.

Наличие предустановленных перечней угроз и активов

Как ни крути, а вбивая перечни угроз, можно непродуктивно потратить уйму времени или что-то забыть. Гораздо лучше работать с уже готовым перечнем, адаптируя его под собственные нужды (рис. 2).

Программные средства для управления ИБ и анализа рисков. Рисунок 2

К тому же очень удобно иметь готовые элементы для управления СУИБ, а не моделировать их самому.

Многопользовательская работа и Web-доступ

Программные средства для управления ИБ и анализа рисков. Рисунок 3

Время и технологии не стоят на месте. Сейчас уже нет возможности работать одному сотруднику с одной копией программы, в которой все хранится. С перечнями рисков должны работать многие сотрудники с разными ролями (хотя бы чтение и чтение/запись). А доступ к интерфейсу и всему функционалу должен быть как можно более простым, например через Web-консоль.

Добавление новых параметров

С одной стороны, тривиальное требование, но не везде выполнимое. Если мы используем простую формулу риска (риск = вероятность х ущерб), нам хватит и базового функционала. Но, как ни странно, не все программы позволяют добавить столько параметров, сколько необходимо (рис. 3).

К этому же требованию можно отнести импорт уже существующих перечней из других программ.

Подключение внешних источников данных

В сущности, управление информационной безопасностью можно осуществлять и с помощью офисных программ. Однако, как и каждый самостоятельный процесс, управление ИБ требует значительных трудозатрат для функционирования. Большинство этих работ приходится на рутинные операции, которые легко поддаются автоматизации.

Когда мы сформировали необходимый перечень угроз и провели оценку рисков, наша модель остается статичной. Она не изменится во времени, если вы ее сами не измените. А ведь у нас столько систем безопасности, каждая вносит свой вклад в управление рисками, понижая или повышая уровень угрозы. Таким образом, программа управления рисками должна иметь возможность изменения параметров рисков в зависимости от произошедших событий.

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

Все вышеперечисленное также относится и к системе управления ИБ, так как риск-менеджмент – это составляющая подсистема качественного средства автоматизации СУИБ.

Универсальный инструмент для управления ИБ

В сущности, управление информационной безопасностью можно осуществлять и с помощью офисных программ. Однако, как и каждый самостоятельный процесс, управление ИБ требует значительных трудозатрат для функционирования. Большинство этих работ приходится на рутинные операции, которые легко поддаются автоматизации. Рассмотрим желаемые функции.

Функционал управления СУИБ

Самый первый и важный пункт. ПО автоматизации СУИБ должно автоматизировать все или большинство функций, в эту СУИБ входящих. Например, в ISO 27001 есть 10 разделов с контролями, а в PCI DSS – 12. Берем количество функций, которые автоматизируются, и высчитываем их отношение к общему количеству. Получаем, что по ISO у нас 100%-ное выполнение, а по PCI DSS – 47%-ное.

Инвентаризация защищаемых активов

Крайне желательно, чтобы программа самостоятельно могла поддерживать в актуальном состоянии имеющиеся активы и вносить изменения. Если добавление новых активов – не критичная задача, то отслеживание уже существующих прямо влияет на актуальность и эффективность процесса управления ИБ.

Отображение процессов

Так как процесс управления ИБ неразрывно связан с бизнес-процессами, то желательно иметь наглядное представление обо всех. К процессам должны быть привязаны активы и риски.

Визуализация рисков и инцидентов, оповещение

Смотреть бесконечные колонки текста и цифр интересно, но хотелось бы иметь наглядную картину инцидентов. Лучше, если она будет привязана к плану здания (рис. 4). Вместе с возможностью инвентаризации активов подобная визуализация становится мощным инструментом мониторинга.

Программные средства для управления ИБ и анализа рисков. Рисунок 4

Также желательно иметь возможность оповещения ответственных лиц по электронной почте или SMS для оптимизации времени реагирования на инцидент.

Управляющие воздействия

Несколько лет назад это был тренд систем управления – автоматические действия на определенные события. Функция, безусловно, полезная, но требующая очень аккуратного использования.

Минимальная кастомизация

Некоторые производители избрали своей тактикой продавать «полупустой продукт». Вы покупаете оболочку, а затем интегратор за отдельные деньги «допилит» вам требуемый функционал. В бухгалтерских системах этого придерживается 1С, а в сфере безопасности – некоторые вендоры SIEM-решений.

В принципе в этом нет ничего плохого, если есть деньги и время. Но не забывайте, что в продукте, разработанном специально для вас, будут специфические именно для вашей среды особенности и дырки, которые не закрываются общими патчами. Как правило, гораздо комфортнее работать с решением, настроенным под конкретную задачу, а не специально для этого разработанным.

Программные средства для управления ИБ и анализа рисков. Таблица 2

Для того чтобы окончательно разобраться с продуктами и выбрать конкретное ПО для управления ИБ и рисками, вы можете воспользоваться табл. 2 (выберите подходящий вариант для каждого параметра и сложите оценки).

Дудко Дмитрий
Опубликовано: Журнал «Information Security/ Информационная безопасность» #1, 2014

Эффективны ли программы слежения за сотрудниками?

Проблема необходимости контроля над действиями сотрудников, вероятно, появилась одновременно с возникновением наемного труда. Кому и зачем это необходимо? Для начала разберемся с первым вопросом. Слежка за сотрудниками необходима всем компаниям, и более того, почти во всех она используется в том или ином виде. Особенно остро вопрос контроля встает в компаниях со стремительно растущей численностью сотрудников, а также с усложняющимися производственными операциями. Далее постараемся ответить на второй вопрос: зачем нам необходимо следить за своими сотрудниками?

Мотивация для установления контроля

Контроль всегда должен преследовать определенную цель. Чаще всего основной мотивацией для установления контроля над действиями сотрудников является предотвращение финансовых потерь. Работодатель всегда хочет иметь уверенность в том, что он не платит сотрудникам сверх меры, не несет дополнительных накладных расходов (например, из-за воровства или простоя ресурсов) и прямых убытков.

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

Итак, мы определили основную цель контроля: предотвращение финансовых потерь. Далее нам необходимо проанализировать работу компании и определить «дыры», то есть слабые места, где при допущении сотрудником ошибки или в результате его злонамеренных действий теоретически можно понести несравнимо большие убытки.

Перечень таких слабых мест может быть следующим:

  • воровство материальных и интеллектуальных ценностей;
  • нецелесообразное использование ресурсов (например, рабочего времени);
  • вандализм в отношении производственных процессов;
  • непреднамеренные ошибки (в том числе утечки данных, компрометация защищаемой информации и т.п.).

Итак, мы разобрались с мотивацией и основной направленностью слежки. А теперь задумаемся, как же отнесутся сотрудники компании к тому, что их действия контролируют?

Взгляд с обратной стороны

Информировать сотрудников о контроле не так сложно – необходимо внести упоминание об этом в трудовой договор или приложение к нему. Вам помогут:

  • Ст. 21 ТК РФ, которая обязывает сотрудника качественно выполнять работу: «Работник обязан: добросовестно исполнять свои трудовые обязанности, возложенные на него трудовым договором; соблюдать правила внутреннего трудового распорядка…»
  • Ст. 22 ТК РФ дает вам (работодателю) право контролировать работу.
  • Ст. 189 ТК РФ определяет правила внутреннего трудового распорядка.

Очевидно, что самой распространенной реакцией на контроль будет резкое непринятие, негатив (не всегда, о чем мы поговорим ниже), ведь мы не любим, когда нам очерчивают рамки и следят за каждым шагом. Поэтому после установления контроля, как правило, встречаем противодействие, и включаемся в «гонку вооружений» с собственными сотрудниками.

Поэтому одним из ключевых моментов при организации контроля, позволяющим избежать негативной реакции на слежку, является донесение мысли о необходимости этого контроля до самих сотрудников. Возникает вопрос: как это сделать? Вариантов множество. Например, можно объяснить сотрудникам, что контроль над выносом материальных ценностей поможет выполнить производственный план, а следовательно, получить премиальные.

Чуть сложнее донести мысль о необходимости слежки до сотрудников, работающих в информационной сфере. Информацию необязательно выносить в кармане через проходную, а ущерб от некоторых утечек может перекрыть на годы вперед таковой от воровства материальных ресурсов. Для человека, как правило, недосягаема мысль о неправильности поступка при краже или утере информации, поскольку информация нематериальна. А раз нематериальна – значит ничего не украл и не потерял.

Где же найти решение проблемы?

Для каждой компании оно свое. Но, как правило, сотрудники положительно или по крайней мере равнодушно реагируют на контроль в тех компаниях, в которых их устраивают график работы, уровень заработной платы, способ поощрений и т.д. Итак, можно сделать следующий вывод: довольный сотрудник согласен с установлением контроля над его действиями. Однако работодателю необходимо четко соблюдать границы дозволенного контроля, уважать своих подчиненных, иначе даже довольный работой сотрудник может стать нарушителем.

Сообщать о слежке или нет?

Итак, контроль над действиями сотрудников установлен. Возникает вопрос: сообщать ли сотрудникам о слежке или нет?

Ответ один: сообщать. При выборе второго варианта мы рискуем узнать подробности ст. 137 Уголовного кодекса РФ «Нарушение неприкосновенности частной жизни» и 138 УК РФ «Нарушение тайны переписки, телефонных переговоров, почтовых, телеграфных или иных сообщений». Данные статьи – это дамоклов меч любого безопасника, практика их применения большая, и всегда не в пользу работодателя.

Какой бы ни была цель контроля, стоимость его организации не должна превышать совокупной суммы ущерба. Для всестороннего расчета суммы ущерба необходимо использовать специальные методы, описание которых займет не одну статью. Эмпирически можно вывести правило, что чем ближе контролируемая цель к производственному процессу, тем эффективней должен быть контроль над действиями пользователей.

Таким образом, нам так или иначе приходится информировать сотрудников о контроле. Это не так сложно – внесите упоминание об этом в трудовой договор или приложение к нему. Вам помогут:

  • Ст. 21 Трудового кодекса, которая обязывает сотрудника качественно выполнять работу: «Работник обязан: добросовестно исполнять свои трудовые обязанности, возложенные на него трудовым договором; соблюдать правила внутреннего трудового распорядка…»
  • Ст. 22 ТК РФ дает (работодателю) право контролировать работу.
  • Ст. 189 ТК РФ определяет правила внутреннего трудового распорядка.

Закон не разделяет отношения работник-работодатель на отношения с использованием компьютерной техники либо без нее. Правоотношения, их субъекты, суть и результат не меняются с модификацией орудий производства. Какие бы программы ни использовались, мы имеем дело все с теми же трудовыми отношениями, в которых сотрудник обязан выполнить работу в рабочее время, а работодатель – ее оплатить.

Существует внутренний трудовой распорядок, сотрудник с ним ознакомлен. А значит, не нарушаются конституционные права работника (ст. 23, 24 Конституции РФ). Отсутствие умысла работодателя выбивает почву из-под ног и у сторонников привлечения шефа к ответственности по ст. 137 и 138 УК РФ.

Но вернемся к самой слежке за действиями сотрудников в среде, наиболее нас интересующей, – информационной.

Что использовать?

Решая вопрос о достижении наших целей (контроль утечек и укрепление дисциплины), нам не обойтись без технических средств. Разумеется, прежде чем выбирать меры слежения, нам необходимо составить модель нарушителя и определить каналы утечки информации (в случае с укреплением дисциплины – способы реализации). Меры могут быть организационные (например, отключить доступ к Интернету) и программно-аппаратные.

Эффективны ли программы слежения за сотрудниками? - статья Дудко Дмитрия

Кратко рассмотрим основные программно-аппаратные меры, которые помогут, в порядке необходимости:

  • подсистема идентификации и аутентификации пользователей. Это основа основ. Если мы не можем однозначно идентифицировать пользователя, то мы не сможем его контролировать. И разумеется, никаких локальных администраторов на рабочих машинах;
  • подсистема доступа в Интернет (proxy). Proxy выступает первым эшелоном контроля, ограничивая каналы утечки через Интернет;
  • подсистема контроля приложений (программной среды). Мы контролируем установку приложений на рабочих компьютерах, а следовательно, уменьшаем возможность принести «сюрприз из дома»;
  • подсистема контроля подключаемых устройств. Логическое продолжение предыдущего пункта: если мы не можем подключить флешку, то сюрпризов у нас будет гораздо меньше. Также мы ограничим утечки класса «поработаю дома»;
  • подсистема контроля утечек конфиденциальной информации (DLP-системы). Если мы все же разрешаем использовать Интернет и подключать флешки, нам необходимо знать, что именно передается;
  • подсистема IRM (Information Rights Management). Это уже глобальный уровень отслеживания перемещения документов и действий сотрудников с ними в рамках всей организации и за ее пределами.

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

Измеряем эффективность

Как работодателю оценить, эффективен ли его контроль над действиями сотрудников? Измерение эффективности слежения прямо связано с поставленными целями. Если наша цель в уменьшении непродуктивно используемого времени, проведенного в Интернете, то мерой эффективности слежения будет уменьшение случаев непродуктивного использования (с учетом вышеназванных ограничений). Чем меньше инцидентов, тем лучше.

Какой бы ни была цель контроля, стоимость его организации не должна превышать совокупной суммы ущерба. Для всестороннего расчета суммы ущерба необходимо использовать специальные методы, описание которых займет не одну статью. Эмпирически можно вывести правило, что чем ближе контролируемая цель к производственному процессу, тем эффективней должен быть контроль над действиями пользователей.

Следить за действиями сотрудников необходимо. Главное – соблюсти баланс интересов бизнеса и сотрудников.

Дудко Дмитрий
Опубликовано: Журнал «Information Security/ Информационная безопасность» #6, 2013