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

Это мероприятие проводят сегодня Мария Воронова директор по консалтингу компании InfoWatch, консультант в ИБ-области Максим Анюков, компания InfoWatch и консультант в области юридических вопросов Сергей Хайрук, компания InfoWatch. Они сегодня расскажут, что нужно делать, если сотрудники информационной безопасности или DLP-система обнаружили нарушение. Как зафиксировать инцидент, как оценить его критичность для компании, что надо сделать для его разбора, как его классифицировать, как оформить инцидент, как подготовить документацию для судебного разбирательства.

Темы, которые сегодня будут рассмотрены на мероприятии, изображены на следующем слайде.

Перед ИБ-подразделением стоит задача построить процедуру реагирования на инциденты и как DLP-система применима к различным системам мониторинга событий. Важно предварительно проработать и понять, что является инцидентом, а что им не является. Что является нарушением, какие данные критичны для конкретной организации.

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

 

Допустим DLP-система выдает какое-либо событие, таких событий может быть множество.

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

 

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

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

 

Событие не подтверждается

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

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

 

Оценка критичного инцидента

Теперь перейдем к оценке критичности инцидента. Слово берет Максим Анюков, консультант в ИБ-области, компания InfoWatch.

DLP-система во множестве организаций выдает огромное количество срабатываний и событий, разной степени критичности, это в определенной степени зависит от ее настроек.

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

 

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

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

Здесь ключевую роль играет взаимодействие начинающих сотрудников, находящихся на первой линии SOС (Центр управления инцидентами информационной безопасности – Security Operation Center), с опытными сотрудниками, работающими на второй линии, либо руководством, которые должны предоставить первым максимально подробные и понятные регламенты работы и до них доводить все новые изменения в регламентах, чтобы они при виде события сами могли принять определенное решение, а не просто скидывать на следующие линии прошедшие через них инциденты. Чем подробнее будут разработаны критерии отнесения события к инциденту или не инциденту, чем подробнее будут составлены критерии отнесения события к критичному инциденту, который требует очень внимательно разбора, тем лучше будет для этой организации, поскольку очень серьезных инцидентов бывает очень немного. Каждому инциденту на практике не получится уделять много внимания. Кроме того, первая линия SOС обязательно должна получать обратную связь по поводу тех инцидентов, которые они передавали дальше, без этого они не смогут повышать свою квалификацию.

 

Разбор некритичного инцидента

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

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

 

Разбор критичного инцидента

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

Сначала оформляется инцидент, потом он подтверждается регламентом, согласованием всеми заинтересованными подразделениями.

 

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

Прежде всего используется срез по видам нарушений и определяется ответственное за разбор подразделение. Возможна квалификация по категориям данных, от этого будет зависеть принцип разбора инцидента, по каким статьям нарушителю будут предъявлены претензии, связанные с нарушением. Срез по уровню нарушений определяет от какого уровня сотрудников происходил инцидент (топ-менеджер, ИБ- или ИТ-персонал и т.д.). Срез по степени воздействия: возможный ущерб для организации.

 

Классификация инцидентов

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

Как правило, к конфиденциальной категории Critical относится все что связано с коммерческой тайной, с данными по VIP-сотрудникам и VIP-клиентам. Вторая конфиденциальная категория – High, имеет следующее описание: нарушение данных из этой категории приводит к наложению штрафов от регуляторов. Здесь напрашивается 152-й ФЗ, законы о банковской тайне и другие законы, касающиеся деятельности конкретно вашей организации. Прежде всего это персональные данные, они должны контролироваться и выявляться DLP-системой в рамках работы служб информбезопасности. 

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

В первых двух категориях сотрудники привлекаются строго по законодательству. Пятая категория – Public здесь содержатся абсолютно открытые данные. 

 

Далее следует классификация для маршрутизации по ответственным подразделениям. Какое подразделение за какой тип инцидентов отвечает.

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

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

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

 

Оформление инцидента

На следующем слайде даны 9 шагов оформления инцидента.

Что надо делать? В обязательном порядке при выявлении нарушения составляется служебная записка с описанием инцидента, чисто формально: что произошло, такой-то инцидент, руководством, кому эта записка направляется (это либо руководитель организации, либо руководитель ИБ-департамента), должна быть наложена некая резолюция. Начинается внутренне расследование, собирается комиссию, которая затребует объяснение у сотрудника, совершившего инцидент. А на это дается всего месяц, по трудовому кодексу какое-либо дисциплинарное взыскание может быть применено не позднее чем через месяц после обнаружения проступка, т.е. обнаружения в DLP-системе. На срок предоставления объяснений у сотрудника есть три рабочих дня. В этот срок он должен написать объяснительную записку либо отказаться от объяснений, тогда комиссия составляет акт об отказе в даче каких-либо объяснений.

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

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

Если все правильно оформлено, то такие сотрудники проигрывают суд.

 

Несколько слов про акт проведения служебного расследования. Слово взял консультант в области юридических вопросов Сергей Хайрук, компания InfoWatch. 

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

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

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

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

Если допустим сотрудник выгрузил на съемный носитель коммерческую тайну и кому-то передал флешку, здесь нужно фиксировать первое единократное нарушение внутреннего регламента, это основание для получения выговора сотрудником, если это многократное нарушение, то это повод для увольнения. Если разглашение доказано, то это однозначно увольнение. Необходимо доказать стандартный состав (в организации учрежден режим коммерческой тайны), доказать, что коммерческая тайна была правомерно предоставлена работнику на законных основаниях, это либо согласие работника, либо прописанное в трудовом договоре и должностной инструкции необходимость допуска работника к коммерческой тайне, и факт выгрузки на внешний носитель. Этого достаточно. Факт разглашения устанавливать не требуется.

 

Официальное оформление доказательств для суда

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

Чтобы избежать претензий на предмет того, что часть доказательств слеплено («это вообще не мое, меня здесь не было» и т.д.). Здесь рекомендуется снимать доказательства для суда в присутствии нотариуса для нотариального заверения с объяснениями: какие действия производятся, все это следует зафиксировать. Это делается быстро, стоит не дорого, но сильно помогает доказательства воспринимать как максимально легитимные. И на их основе можно много легче приниматься судебные решения.

 

Ключевые выводы

Важно четко прописать области ответственности, кто что делает и в какие моменты времени. Нужно четко прописывать процедуры. 

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

 

Сейчас на главной