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

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

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

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

Обнаружение и анализ инцидентов информационной безопасности

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

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

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

Признаки инцидента информационной безопасности

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

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

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

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

Примерами событий, которые могут послужить источниками информационной безопасности могут служить:

• журнальные файлы сервера фиксируют сканирование портов
• объявление в СМИ о появлении нового вида эксплойта
• открытое заявление компьютерных преступников об объявлении войны вашей организации и.т.д.

Анализ инцидентов информационной безопасности

Инцидент не является очевидным свершившимся фактом, напротив, злоумышленники стараются сделать всё чтобы не оставить в системе следов своей деятельности. Признаки инцидента содержит незначительное изменение в файле конфигурации сервера или, на первый взгляд, стандартная жалоба пользователя электронной почты. Принятие решения о наступлении события инцидента во многом зависит от компетентности экспертов команды реагирования. Необходимо отличать случайную ошибку оператора от злонамеренного целенаправленного воздействия на информационную систему. Факт отработки “в холостую” инцидента информационной безопасности также является инцидентом информационной безопасности, поскольку отвлекает экспертов команды реагирования от насущных проблем. Руководство организации должно обратить внимание на данное обстоятельство и предоставить экспертам команды реагирования известную свободу действий.

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

Документирование инцидента информационной безопасности

Документирование событий инцидента информационной безопасности необходимо для сбора и последующей консолидации свидетельств расследования. Документированию подлежат все факты и доказательства злонамеренного воздействия. Различают технологические свидетельства и операционные свидетельства воздействия. К технологическим свидетельствам относят информацию, полученную от технических средств сбора и анализа данных (сниферы, IDS), к операционным – данные или улики, собранные в процессе опроса персонала, свидетельства обращений на service desk, звонки в call center.

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

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

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

Язык инцидентов и проблем

ITIL Service Support — признанная в мире модель. Она основана на передовом опыте и используется как руководство ИТ-организациями при разработке подходов к управлению обслуживанием. Эта модель перспективна. Также она определяет дополнительные элементы, необходимые для успешного функционирования ИТ-организации как сервисного бизнеса. Она предоставляет технический словарь для обсуждения службы поддержки, определяет понятия и раскрывает отличия между различными видами деятельности. Например, деятельность, необходимая для реагирования на прерывания сервиса, его восстановления, отлична от деятельности по поиску и устранению причин, из-за которых прерывается обслуживание.

Инциденты

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

Примерами инцидентов являются:

1. Пользователь не может получить e-mail
2. Средство мониторинга сети указывает, что канал связи вскоре переполнится
3. Пользователь ощущает замедление работы приложения

Проблемы

Проблема — есть неизвестная причина одного или более инцидентов.Одна проблема может породить несколько инцидентов.

Ошибки

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

Примеры ошибок включают:

1. Неправильная сетевая конфигурация компьютера
2. Средство мониторинга неверно определяет статус канала в момент занятости маршрутизатора

Соотношение понятий управления инцидентами и проблемами показано на рисунке 1. Инциденты, проблемы и известные ошибки связаны в своего рода жизненный цикл: инциденты часто являются индикаторами проблем ⇒ выявление причины проблемы определяет ошибку ⇒ ошибки затем систематически исправляются.

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

Она включает в себя:

1. Выявление и регистрация инцидентов
2. Классификация и начальная поддержка
3. Исследование и диагностика
4. Решение и восстановление
5. Закрытие
6. Владение, мониторинг, отслеживание и связь

Управление проблемами

Управление проблемами — есть деятельность по минимизации воздействия на бизнес проблем, которые вызываются ошибками в ИТ-инфраструктуре, по предотвращению повторения инцидентов, связанных с такими ошибками. Управление проблемами выявляет причины проблем, идентифицирует решения по их обходу или устранению.

Управление проблемами включает:

1. Контроль проблем
2. Контроль ошибок
3. Предотвращение проблем
4. Анализ основных проблем

Контроль проблем

Цель контроля проблем — найти причину проблемы, выполнив следующие шаги:

1. Идентификация и регистрация проблем
2. Классификация проблем и определение приоритетов их решений
3. Исследование и диагностика причин

Контроль ошибок

Контроль ошибок обеспечивает исправление проблем за счет следующих действий:

1. Идентификация и регистрация известных ошибок
2. Оценка способов устранения и расстановка приоритетов
3. Регистрация по временному обходу ошибки в средствах службы поддержки
4. Закрытие известных ошибок путем осуществления исправлений
5. Мониторинг известных ошибок для определения необходимости в изменении приоритетов

Анализ проблем

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

Организационные роли и распределение ответственности

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

Первый уровень поддержки

Организация (подразделение), представляющая первый уровень поддержки обычно относится к оперативным службам. Как правило, она называется диспетчерской службой, Call Center, Service Desk.

Роли. Владелец процесса

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

Первая линия поддержки

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

Обязанности

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

• Гарантировано, что карточка инцидента содержит точное и достаточно детальное описание проблемы
• Гарантирован правильный выбор важности/приоритета инцидента
• Определена природа проблемы, контакты пользователя, влияние на бизнес и ожидаемое время решения

• Владение каждым инцидентом. Как адвокат конечного пользователя первый уровень поддержки обеспечивает успешное разрешение каждого инцидента. При этом гарантируется своевременное решение вопросов за счет:

  • Разработки и управления планом действий по решению вопроса
  • Инициации конкретных назначений заданий для персонала и бизнес-партнеров
  • Эскалации инцидента, если требуется, когда цель не достигается во время
  • Обеспечения внутреннего взаимодействия в соответствии с целями обслуживания
  • Защиты интересов вовлеченных бизнес-партнеров

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

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

  • Оценки эффективности данного процесса и таких механизмов поддержки, как отчеты, виды связи и форматы сообщений, процедуры эскалации
  • Разработки специфических для подразделений отчетов и процедур
  • Поддержки и совершенствования взаимодействия и списков эскалации
  • Участие в процессе анализа проблем

Способности и навыки

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

Второй уровень поддержки

Этот уровень также обычно относится к оперативным службам.

Роли

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

Обязанности

• Решение инцидентов, переданных с первого уровня. Если для первого уровня поддержки ожидается, что он решает 80% инцидентов, то от второго уровня поддержки ожидается, что он решает 75% инцидентов, переданных ему первым уровнем, то есть 15% от числа зарегистрированных инцидентов. Остальные инциденты передаются на третий уровень.
• Определение причин проблем. Второй уровень поддержки определяет причины проблем и предлагает меры по их обходу или устранению. Они привлекают и управляют другими ресурсами по мере необходимости для определения причин. Решение проблем передается на третий уровень, когда причина заключается в архитектурном или техническом вопросе, который превышает их уровень квалификации.
• Обеспечение реализации исправлений и устранений проблем. Второй уровень поддержки обеспечивает инициирование проектов в организациях разработчиках для реализации планов устранения известных ошибок. Они обеспечивают документирование найденных решений, сообщают о них персоналу первого уровня и реализуют их в инструментах.
• Постоянный мониторинг инфраструктуры. Второй уровень поддержки пытается идентифицировать проблемы до возникновения инцидентов посредством наблюдения за компонентами инфраструктуры и принятия корректирующих действий при обнаружении дефектов или ошибочных тенденций.
• Заблаговременный анализ тенденций инцидентов. Уже случившиеся инциденты исследуются для того, чтобы определить не свидетельствуют ли они о наличии проблем, которые следует исправить, чтобы они не вызвали новые инциденты. Исследуются те инциденты, которые закрыты и не сопоставлены известным проблемам, на предмет наличия потенциальных проблем.
• Постоянное совершенствование процесса управления проблемами. Как владелец процесса управления проблемами второй уровень поддержки гарантирует, что процесс и имеющиеся возможности адекватны и улучшает их при необходимости. Они проводят сессии анализа проблем, чтобы выявить полученные уроки и гарантировать, что средства контроля над процессом, такие как совещания и отчеты, адекватны.

Способности и навыки

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

Третий уровень поддержки

Этот уровень поддержки обычно относится к группе разработки приложений и сетевой инфраструктуры.

Роли

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

Обязанности

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

Способности и навыки

• Эксперты в соответствующих областях. Команды третьего уровня должны быть экспертами, которые планируют и проектируют ИТ-инфраструктуру.

Процессы

Можно выделить три основных процесса, связанных с управлением инцидентами и управлением проблемами:

• процесс управления инцидентами
• процесс контроля проблем
• процесс контроля ошибок

Эти основные процессы присутствуют практически во всех передовых организациях, хотя могут иметь и другие названия.

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

Данный процесс сфокусирован на скорейшем восстановлении прерванного сервиса. В таблице 1 приведены основные параметры этого процесса, а на рисунке 1 показана диаграмма его работы.

Рисунок 1. Модель процесса

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

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

Рисунок 2. Модель процесса контроля проблем

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

1. Если у вас достаточное количество проблем, то назначьте постоянную команду. Иначе создавайте команду при появлении проблемы, во многом также как формируется команда под какой-либо проект;
2. Команда почти всегда должна быть с междисциплинарным опытом и знаниями. И это конечно зависит от природы возникшей проблемы;
3. Следует давать оценку времени на определение причины (разрабатывать план проекта) в момент появления проблемы. В соответствии с этой оценкой следует измерять прогресс в деятельности команды.

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

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

Рисунок 3. Модель процесса контроля ошибок

Взаимодействия

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

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

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

Эскалация

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

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

Функциональная эскалация

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

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

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

Иерархическая эскалация

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

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

Отчеты и совершенствование процессов

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

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

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

Такие отчеты позволяют руководителям принимать решения о распределении ресурсов, направлении усилий персонала. Регулярное использование параметров типа:

1. Среднее время обработки карточек на каждом из уровней
2. Количество карточек, переданных и решенных на каждый из уровней, могут помочь выявить слабости ИТ-инфраструктуры

Наконец жизненно необходимый набор отчетов, типа:

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

Заключение

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

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

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

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

Управление инцидентами

Основная цель процесса управления инцидентами (incident management) - восстановление нормальной работоспособности системы в максимально короткие сроки и минимизация отрицательного влияния на бизнес, пользующийся службами, работоспособность которых оказалась нарушенной . Под «нормальным функционированием служб» понимается функционирование, соответствующее зафиксированному в соглашении об уровне обслуживания (service level agreement,SLA ).

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

Всякому процессу управления инцидентами можно дать формальное краткое описание путем перечисления набора характеристик.

Входными данными для описания инцидентов служат:

• детальное описание инцидента, полученное от Service Desk, служб обеспечения оперативного функционирования сетей или серверов и т.д.;
• описание конфигураций и элементов, возможно связанных с инцидентом. Описания берутся из CMDB, базы данных единиц конфигурации, к которым относятся все элементы ИТ-инфраструктуры (оборудование, программное обеспечение, документация, предоставляемые службы и т.д.);
• информация (при ее наличии) из базы проблем и базы известных ошибок;
• описание способа разрешения.

Результат процесса управления инцидентами может быть следующим:

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

Возможные мероприятия по управлению инцидентами:

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

Роли и функции управления инцидентами:

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

Возможные метрики:

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

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

Передача инцидента от Service Desk на вторую линию поддержки (функциональная эскалация) требуется при невозможности устранить инцидент на первой линии. Автоматизированная функциональная эскалация возможна, но должна быть тщательно спланирована в соответствии с SLA.

Иерархическая эскалация оказывается необходимой при невозможности устранения инцидента либо за выделенное время, либо с необходимым качеством. Как правило, она осуществляется персоналом службы Service Desk в соответствии с их опытом и вручную. Автоматизированная иерархическая эскалация тоже используется и может строиться на основе учета временных интервалов. Целесообразно чтобы она осуществлялась до времени, установленного в SLA; при этом соответствующий руководитель получит возможность предпринять дополнительные действия.

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

Перечислим наиболее важные полезные качества, которые приобретаются в результате внедрения процесса управления инцидентами. Для бизнеса в целом это:

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

Ряд полезных качеств приобретает и работа ИТ-подразделения:

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

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

Управление проблемами

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

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

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

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

Входными данными для описания служат:

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

Возможные мероприятия:

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

Результаты могут быть следующими:

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

Роли и функции: сотрудники, ответственные за обработку проблем (роли); менеджер управления проблемами (роль).

Возможные метрики:

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

Эффект от внедрения процесса управления проблемами

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

• Качество служб. Управление проблемами помогает поддерживать непрерывный цикл постоянного повышения качества ИТ-служб.
• Сокращение числа инцидентов. Процесс управления проблемами является инструментом для сокращения числа возникающих инцидентов, отрицательно влияющих на бизнес организации.
• Непрерывное решение. В результате работы процесса сокращается число и влияние на бизнес уже решенных проблем и известных ошибок.
• Усовершенствованное обучение. Процесс основывается на концепции использования накопленных знаний из прошлого и предоставляет возможности для анализа трендов и предотвращения сбоев, либо снижения их значимости и влияния на основной бизнес.
• Увеличение числа инцидентов, разрешаемых при первом обращении. Это достигается путем предоставления в распоряжение Service Desk рекомендаций по путям предотвращения и обхода возникающих инцидентов.

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

Реализация и внедрение

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

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

Допустимо (и рекомендуется) совмещение функций Service Desk и функций управления инцидентами. Однако важно помнить, что это разные процессы: первичное общение с пользователями не входит в функции процесса управления инцидентами. К тому же, пользователь может обратиться в службу поддержки не только в связи с возникшим инцидентом, но и по иной причине (потребность в информации, необходимость пополнения расходуемых материалов и т.д.). С другой стороны, при некоторых способах реализации (например, в случае построения службы поддержки на основе Web-технологий, когда пользователь самостоятельно вносит все необходимые данные в формы) необходимость выделенной службы Service Desk оказывается под вопросом. В то же время ни в коем случае нельзя отказываться от управления инцидентами - откуда бы ни поступило сообщение об их возникновении, кто-то обязательно должен отвечать за их устранение.

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

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

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

Производители инструментария стараются учитывать упомянутые рекомендации. Например, HP OpenView Service Desk 3.0 имеет модульную структуру. В виде отдельного модуля реализованы возможности регистрации и управления обращений пользователей, инцидентов и проблем, что вполне соответствует упомянутым рекомендациям: интеграция в данном случая является максимально полной. Пользователи системы, построенной на основе этого продукта, имеют возможность строить связи между регистрационными записями всех перечисленных типов, осуществлять поиск по контексту и с учетом этих связей, определять известные способы решения проявляющихся неисправностей. Разделение этих функций может снизить эффективность работы инструментального средства, а как следствие - и качество реализации процессов. В то же время, в основе всякого решения по управлению ИТ-инфраструктурой лежит учет имеющегося оборудования, приложений, документации и т.д. - всего того, что и составляет эту инфраструктуру. Такие возможности также доступны в рамках HP Service Desk 3.0. Кроме того, в виде отдельных модулей реализованы возможности, предназначенные для автоматизации управления изменениями и управления соглашениями SLA. Интеграция всех перечисленных модулей реализуется в максимально полном объеме, предоставляя возможность использовать рассматриваемый продукт в качестве основы для построения комплексной системы управления ИТ.

Продукт компании Remedy строится несколько сложнее, основой его является Remedy Action Request System, устанавливаемая на сервере. К системе в качестве прикладной части могут дополнительно приобретаться функциональные модули: Help Desk, Asset Management, Change Management и Service Level Agreement. Каждый из модулей может использоваться как самостоятельно (без других прикладных модулей), так и в составе комплексного решения. Вопросы автоматизации процессов управления проблемами и инцидентами, как и в случае решения от HP, реализуются в модуле Remedy Help Desk. При этом имеются некоторые отличия и реализуются отдельные собственные подходы к пониманию данных процессов, но основные пожелания и требования ITIL полностью учтены.

Для успешного внедрения процессов управления инцидентами и проблемами

необходимо выполнение, как минимум, следующих условий.

• Наличие актуальной и своевременно обновляемой базы CMDB. Если эта база недоступна, информация об имеющих отношение к инциденту единицах конфигурации будет добываться вручную, что существенно увеличит время обработки инцидента и повысит ее сложность.
• Доступность обновляемой базы знаний по ошибкам/проблемам и способам их разрешения, а также обхода. Наличие такой базы позволяет быстро разрешать многие проблемы. Желательно иметь возможность подключения к ней аналогичных баз, разработанных другими организациями и компаниями. Возникающие при этом вопросы совместимости могут привести к большим сложностям, поэтому рекомендуется использовать решения с открытой архитектурой, содержащие средства для импорта и экспорта данных. В последнее время все чаще в качестве стандартного способа доступа к информации используется Web-интерфейс, являющийся удобным и понятным, а также широко распространенным.
• С точки зрения потенциально конфликтной ситуации между управлением проблемами и управлением инцидентами (из-за их разных целей), необходимо организовать совместную работу и сотрудничество исполнителей обоих процессов. При этом нельзя забывать о том, что из тех же соображений один и тот же человек не может исполнять и те и другие обязанности одновременно: ему будет очень трудно найти баланс интересов.
• Организация эффективной автоматизированной системы регистрации инцидентов с возможностями детальной и качественной классификации, являющейся чрезвычайно важным элементом для организации функционирования как службы Service Desk, так и рассматриваемых процессов в чистом виде. Использование для этих целей бумажных технологий не рекомендуется.

Весьма удобно, если инструментальные средства, используемые для реализации рассматриваемых процессов, обладают следующими дополнительными возможностями:

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

Проиллюстрируем перечисленные возможности на примере уже упоминавшегося Service Desk 3.0. Будучи представителем семейства продуктов HP OpenView, Service Desk содержит возможности получения сообщений от других продуктов данного семейства, в том числе от Network Node Manager, средства мониторинга и управления сетевыми устройствами, и VantagePoint Operations, средства мониторинга и управления серверами и приложениями. Данные продукты могут в автоматическом режиме, на основании собираемой информации о контролируемых объектах, генерировать запросы для Service Desk, которые автоматически передаются и анализируются операторами службы поддержки или обрабатываются в автоматическом режиме. При соответствующей настройке источниками аналогичных сообщений могут стать и иные диагностические средства. Продукт предусматривает возможности автоматического информирования путем отправки сообщений руководителей соответствующих уровней при нарушении сроков устранения инцидента. В нем реализованы расширенные возможности по поиску необходимой информации среди уже учтенных проблем, инцидентов и иных данных. В продукте представлены возможности интеграции с почтовыми, телефонными и пейджинговыми системами.

В виду актуальности и полезности перечисленных дополнительных возможностей, производители программных решений стараются включать их в свои продукты. Многое из сказанного о HP Service Desk относится и к продуктам других производителей, в том числе, Remedy, Tivoli, CA, Peregrin, FrontRange.

Тем, кто берется за работу по внедрению рассматриваемых процессов, надо быть готовым к разнообразным трудностям. Среди них:

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

***

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

Литература

1. З. Алехин. ITIL - основа концепции управления ИТ-службами. «Открытые системы». 2001, № 3
2. З. Алехин. Service Desk - цели, возможности, реализации. «Открытые системы». 2001, № 5-6
3. CCTA. Best Practice for Service Support. London: The Stationery Office, 2000

Заурбек Алехин ([email protected]) - руководитель проекта компании i-Teco (Москва).

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

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

Приложения:

• служба недоступна;
• ошибка в приложении, не дающая клиенту нормально работать;
• исчерпано дисковое пространство.

Оборудование:

• сбой системы;
• внутренний сигнал тревоги;
• отказ принтера.

Заявки на обслуживание:

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

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

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

Обеспечение информационной безопасности бизнеса Андрианов В. В.

4.1.4. Примеры инцидентов

4.1.4. Примеры инцидентов

Общие сведения

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

Утечка служебной информации;

Кража клиентов и бизнеса организации;

Саботаж инфраструктуры;

Внутреннее мошенничество;

Фальсификация отчетности;

Торговля на рынках на основе инсайдерской, служебной информации;

Злоупотребление полномочиями.

Аннотация

В отместку за слишком маленькую премию 63-летний Рожер Дуронио (бывший системный администратор компании UBS Paine Webber) установил на серверах компании «логическую бомбу», которая уничтожила все данные и парализовала работу компании на продолжительное время.

Описание инцидента

Дуронио был недоволен своей зарплатой, составляющей 125 000 долларов в год, возможно, это и послужило причиной внедрения «логической бомбы». Однако последней каплей для системного администратора стала полученная им премия в размере 32 000 долларов вместо ожидаемых 50 000 долларов . Когда он обнаружил, что его премия гораздо меньше, чем он ожидал, Дуронио потребовал от начальства перезаключить трудовой договор на сумму 175 000 долларов в год, или же он покинет компанию. В повышении зарплаты ему было отказано, кроме того, его попросили покинуть здание банка. В отместку за такое обращение Дуронио решил воспользоваться своим «изобретением», внедренным заранее, предвидя такой поворот событий.

Внедрение «логической бомбы» Дуронио осуществил с домашнего компьютера за несколько месяцев до того, как получил слишком маленькую, на его взгляд, премию. «Логическая бомба» была установлена примерно на 1500 компьютеров в сети филиалов по всей стране и настроена на определенное время - 9.30, как раз на начало банковского дня .

Уволился Дуронио из UBS Paine Webber 22 февраля 2002 г., а четвертого марта 2002 г. «логическая бомба» последовательно удалила все файлы на главном сервере центральной базы данных и 2000 серверов в 400 филиалах банка, при этом отключив систему резервного копирования.

Адвокат Дуронио в течение судебного процесса указывал на то, что виновником происшедшего мог быть не один только обвиняемый: учитывая незащищенность ИТ-систем UBS Paine Webber, под логином Дуронио туда мог попасть и любой другой сотрудник. О проблемах с ИТ-безопасностью в банке стало известно еще в январе 2002 г.: при проверке установили, что 40 человек из ИТ-службы могли войти в систему и получить права администратора по одному и тому же паролю, и понять, кто именно совершил то или иное действие, не представлялось возможным. Адвокат также выдвигал обвинения в адрес UBS Paine Webber и компании @Stake, нанятой банком для расследования случившегося, в уничтожении доказательств атаки. Однако неоспоримым доказательством вины Дуронио были найденные на его домашних компьютерах отрывки вредоносного кода, а в его шкафу - распечатанная копия кода.

Возможности инсайдера

Как на одного из системных администраторов компании на Дуронио была возложена ответственность за всю компьютерную сеть UBS PaineWebber, и, соответственно, он имел к ней доступ. У него также был доступ к сети со своего домашнего компьютера посредством безопасного интернет-соединения.

Причины

Как уже указывалось ранее, его мотивами были деньги и месть. Дуронио получил годовую зарплату 125 000 долларов и премию 32 000 долларов, в то время как ожидал 50 000 долларов, и таким образом отомстил за свое разочарование.

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

Последствия

Заложенная Дуронио «логическая бомба» остановила работу 2000 серверов в 400 офисах компании. По словам ИТ-менеджера UBS Paine Webber Эльвиры Марии Родригес (Elvira Maria Rodriguez), это была катастрофа «на 10 с плюсом по 10-балльной шкале». В компании воцарился хаос, который почти сутки устраняли 200 инженеров из IBM. Всего над исправлением ситуации работало около 400 специалистов, включая ИТ-службу самого банка. Ущерб от случившегося оценивают в 3,1 млн долларов. Восемь тысяч брокеров по всей стране вынуждены были прекратить работу. Некоторым из них удалось вернуться к нормальной деятельности через несколько дней, некоторым - через несколько недель, в зависимости от того, насколько сильно пострадали их базы данных и осуществлялось ли в филиале банка резервное копирование. В целом же банковские операции были возобновлены в течение нескольких дней, однако работа некоторых серверов так и не была восстановлена в полном объеме, в большей степени из-за того, что на 20 % серверов не было средств резервного копирования. Только через год весь серверный парк банка снова был полностью восстановлен.

При рассмотрении дела Дуронио в суде его обвиняли по следующим статьям:

Мошенничество с ценными бумагами - обвинение по данной статье влечет за собой максимальное наказание в виде лишения свободы на 10 лет в федеральной тюрьме и штрафа в размере 1 млн долларов;

Мошенничество в деятельности связанной с компьютерами - обвинение по данной статье влечет за собой максимальное наказание в виде лишения свободы на 10 лет и штрафа в размере 250 000 долларов .

В итоге судебного процесса в конце декабря 2006 г. Дуронио был осужден на 97 месяцев без права досрочного освобождения.

«Вымпелком» и «Шерлок»

Аннотация

С целью наживы бывшие сотрудники компании «Вымпелком» (торговая марка «Билайн») через веб-сайт предлагали детализацию телефонных переговоров сотовых операторов.

Описание инцидента

Сотрудники компании «Вымпелком» (бывшие и действующие) организовали в Интернете сайт www.sherlok.ru, о котором в компании «Вымпелком» узнали в июне 2004 г. . Организаторами данного сайта предлагалась услуга - поиск людей по фамилии, телефону и другим данным. В июле организаторы сайта предложили новую услугу - детализацию телефонных переговоров сотовых операторов. Детализация разговоров - это распечатка номеров всех входящих и исходящих звонков с указанием длительности разговоров и их стоимости, используемая операторами, например для выставления счетов абонентов. По этим данным можно сделать вывод о текущей деятельности абонента, его сфере интересов и круге знакомств. В пресс-релизе Управления «К» министерства внутренних дел (далее - МВД) уточняется, что такая информация стоила заказчику 500 долларов.

Сотрудники компании «Вымпелком», обнаружив данный сайт, самостоятельно собрали доказательства преступной деятельности сайта и передали дело в МВД. Сотрудники МВД возбудили уголовное дело и совместно с компанией «Вымпелком» установили личности организаторов данного преступного бизнеса. А 18 октября 2004 г. был задержан с поличным главный подозреваемый 1 .

Кроме того, 26 ноября 2004 г. были задержаны остальные шестеро подозреваемых, в числе которых были трое сотрудников абонентской службы самой компании «Вымпелком». В ходе следствия выяснилось, что сайт был создан бывшим студентом Московского государственного университета, не работавшим в данной компании.

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

Возможности инсайдера

Двое из числа выявленных среди участников инцидента сотрудников компании «Вымпелком» работали операционистами в компании, а третий являлся бывшим сотрудником и на момент преступления работал на Митинском рынке.

Работа в самой компании операционистами свидетельствует о том, что данные сотрудники имели непосредственной доступ к информации, предлагаемой к продаже на сайте www.sherlok.ru. Кроме того, так как бывший сотрудник компании уже работал на Митинском рынке, то можно предположить, что со временем одним из каналов сбыта данной информации или какой-либо еще информации из баз данных компании «Вымпелком» мог стать и данный рынок.

Последствия

Основными последствиями для компании «Вымпелком» от данного инцидента могли быть удар по репутации самой компании и потеря клиентов. Однако данный инцидент был предан огласке непосредственно благодаря активным действиям самой компании.

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

В марте 2005 г. Останкинский районный суд города Москва приговорил подозреваемых, в числе которых трое сотрудников компании «Вымпелком», к различным штрафам . Так, организатор группы оштрафован на 93 000 рублей. Однако работа сайта www.sherlok.ru была прекращена на неопределенный срок только с 1 января 2008 г.

Крупнейшая утечка персональных данных за всю историю Японии

Аннотация

Летом 2006 г. произошла самая крупная утечка персональных данных за всю историю Японии: сотрудник полиграфического и электронного гиганта Dai Nippon Printing украл диск с приватными сведениями почти девяти миллионов граждан.

Описание инцидента

Японская фирма Dai Nippon Printing, специализирующаяся на выпуске полиграфической продукции, допустила крупнейшую утечку в истории своей страны. Хирофуми Йокояма, бывший сотрудник одного из подрядчиков компании, скопировал на мобильный винчестер и украл персональные данные клиентов фирмы. В общей сложности под угрозу попали 8,64 млн человек, так как похищенная информация содержала имена, адреса, телефоны и номера кредитных карт. В похищенной информации содержались сведения о клиентах 43 различных компаний, например о 1 504 857 клиентах компании American Home Assurance, 581 293 клиентах компании Aeon Co и 439 222 клиентах NTT Finance .

После похищения данной информации Хирофуми открыл торговлю приватными сведениями порциями от 100 000 записей. Благодаря стабильному доходу инсайдер даже покинул постоянное место работы. К моменту задержания Хирофуми успел продать данные 150 000 клиентов крупнейших кредитных фирм группе мошенников, специализирующихся на онлайн-покупках. Кроме того, часть данных уже была использована для мошенничества с кредитными картами.

Более половины организаций, данные клиентов которых были похищены, даже не были предупреждены об утечке информации.

Последствия

В результате данного инцидента убытки граждан, которые пострадали из-за мошенничества с кредитными картами, ставшего возможным только вследствие этой утечки, составили несколько миллионов долларов. Всего пострадали клиенты 43 различных компаний, в том числе Toyota Motor Corp., American Home Assurance, Aeon Co и NTT Finance. Однако более половины организаций даже не были предупреждены об утечке.

В 2003 г. в Японии был принят закон Personal Information Protection Act 2003 (PIPA), но прокуратура не смогла его применить в реальном судебном разбирательстве по данному делу в начале 2007 г. Обвинение не смогло инкриминировать инсайдеру нарушение закона PIPA. Его обвиняют лишь в краже винчестера стоимостью 200 долларов.

Не оценили. Запорожский хакер против украинского банка

Аннотация

Бывший системный администратор одного из крупных банков Украины перевел через банк, в котором раньше работал, со счета региональной таможни на счет несуществующей днепропетровской фирмы-банкрота около 5 млн гривен.

Описание инцидента

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

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

Уволившись, бывший системный администратор решил вернуть у бывшего руководства интерес к своей персоне посредством использования несовершенства применяемой практически во всех банках Украины системы «Банк-Клиент» 2 . План системного администратора состоял в том, что он решил разработать свою программу защиты и предложить ее банку, вернувшись на свое прежнее место работы. Реализация плана заключалась в проникновении в систему «Банк-Клиент» и внесении в нее минимальных изменений. Весь расчет был сделан на то, что в банке должны были обнаружить взлом системы.

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

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

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

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

В действительности системный администратор рассчитывал на то, что денежные средства не будут переведены, что факт взлома будет обнаружен до перевода средств, но на практике все оказалось по-другому и он стал преступником и его липовый перевод перерос в кражу.

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

Последствия

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

В 2004 г. указом президента Украины была усилена уголовная ответственность за компьютерные преступления: штрафы от 600 до 1000 не облагаемых налогом минимумов, лишение свободы - от 3 до 6 лет. Однако бывший системный администратор совершил преступление до вступления в силу указа президента.

В начале 2005 г. состоялся суд над системным администратором. Его обвинили в совершении преступления по части 2 статьи 361 Уголовного кодекса Украины - незаконное вмешательство в работу компьютерных систем с нанесением вреда и по части 5 статьи 185 - кража, совершенная в особо крупных размерах. Но так как руководство банка отказалось от каких-либо претензий в его адрес, то статью за кражу с него сняли, а часть 2 статьи 361 поменяли на часть 1 - незаконное вмешательство в работу компьютерных систем.

Бесконтрольный трейдинг в банке Societe Generale

Аннотация

24 января 2008 г. Societe Generale объявил о потере 4,9 млрд евро из-за махинаций своего трейдера Жерома Кервьеля . Как показало внутреннее расследование, в течение нескольких лет трейдер открывал сверхлимитные позиции на фьючерсы на европейские фондовые индексы. Общая сумма открытых позиций составила 50 млрд евро.

Описание инцидента

С июля 2006 по сентябрь 2007 г. компьютерная система внутреннего контроля 75 раз (именно столько раз Жером Кервьель осуществлял несанкционированные операции либо его позиции превышали допустимый лимит) выдавала предупреждение о возможных нарушениях. Сотрудники отдела мониторинга рисков банка не осуществляли детальных проверок по этим предупреждениям .

Впервые экспериментировать с неавторизованным трейдингом Кервьель начал уже в 2005 г. Тогда он занял короткую позицию на акции Allianz, ожидая падения рынка. Вскоре рынок действительно упал (после террористических акций в Лондоне), так были заработаны первые 500 000 евро. О своих чувствах, которые он испытал от своего первого успеха, Кервьель впоследствии рассказал следствию: «Я уже знал, как закрыть мою позицию, и был горд за полученный результат, но вместе с тем и удивлен. Успех заставил меня продолжать, это было как снежный ком… В июле 2007 г. я предложил занять короткую позицию в расчете на падение рынка, но не встретил поддержки со стороны своего руководителя. Мой прогноз оправдался, и мы получили прибыль, на этот раз она была вполне легальной. Впоследствии я продолжал проводить такого рода операции на рынке либо с согласия начальства, либо при отсутствии его явного возражения… К 31 декабря 2007 г. моя прибыль достигла 1,4 млрд евро. В тот момент я не знал, как объявить об этом моему банку, так как это была очень большая, нигде не задекларированная сумма. Я был счастлив и горд, но не знал, как объяснить своему руководству поступление этих денег и не навлечь на себя подозрение в проведении несанкционированных сделок. Поэтому решил скрыть мою прибыль и провести противоположную фиктивную операцию…» .

В действительности в начале января того же года Жером Кервьель вновь вступил в игру с фьючерсными контрактами на три индекса Euro Stoxx 50, DAX и FTSE, помогавшими ему обыгрывать рынок в конце 2007 г. (правда, тогда он предпочитал занимать короткую позицию). По подсчетам, в его портфеле накануне 11 января было 707, 9 тыс. фьючерсов (каждый стоимостью по 42,4 тыс. евро) на Euro Stoxx 50, 93,3 тыс. фьючерсов (192,8 тыс. евро за 1 штуку) на DAX и 24,2 тыс. фьючерсов (82,7 тыс. евро за 1 контракт) на индекс FTSE. В целом спекулятивная позиция Кервьеля равнялась 50 млрд евро, т. е. была больше стоимости банка, в котором он работал .

Зная время проверок, он в нужный момент открывал фиктивную хеджирующую позицию, которую позже закрывал. В результате проверяющие никогда не видели ни одной позиции, которую можно было назвать рискованной. Их не могли насторожить и крупные суммы сделок, которые вполне обычны для рынка фьючерсных контрактов по индексам. Подвели его фиктивные сделки, проводимые со счетов клиентов банка. Использование счетов различных клиентов банка не приводило к видимым для контролеров проблемам. Однако по истечении определенного времени Кервьель начал использовать счета одних и тех же клиентов, что привело к «ненормальной» активности, наблюдаемой за данными счетами, и, в свою очередь, привлекло внимание контролеров . Это стало концом аферы. Выяснилось, что партнером Кервьеля по мультимиллиардной сделке был крупный немецкий банк, якобы подтвердивший астрономическую транзакцию по электронной почте. Однако электронное подтверждение вызвало у проверяющих подозрения, для проверки которых в Societe Generale была создана комиссия. 19 января в ответ на запрос немецкий банк не признал эту транзакцию, после чего трейдер согласился дать признательные показания .

Когда удалось выяснить астрономические размеры спекулятивной позиции, генеральный директор и председатель совета директоров Societe Generale Даниэль Бутон заявил о своем намерении закрыть открытую Кервьелем рискованную позицию . На это ушло два дня и привело к убыткам в 4,9 млрд евро.

Возможности инсайдера

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

В 2005 г. Кервьеля повысили. Он стал настоящим трейдером. В непосредственные обязанности молодого человека входили элементарные операции по минимизации рисков. Работая на рынке фьючерсных контрактов на европейские биржевые индексы, Жером Кервьель должен был следить за тем, как меняется инвестиционный портфель банка. А его основной задачей, как объяснил один из представителей Societe Generale, было сокращать риски, играя в противоположном направлении: «Грубо говоря, видя, что банк ставит на красное, он должен был ставить на черное». Как у всех младших трейдеров, у Кервьеля был лимит, превышать который он не мог, за этим следили его бывшие коллеги по бэк-офису. В Societe Generale существовало несколько уровней защиты, например трейдеры могли открывать позиции только со своего рабочего компьютера. Все данные об открытии позиций автоматически в реальном времени передавались в бэк-офис. Но, как говорится, лучший браконьер - бывший лесничий. И банк совершил непростительную ошибку, поставив бывшего лесничего в положение охотника. Жерому Кервьелю, имевшему за плечами почти пятилетнюю практику контроля за трейдерами, не составило большого труда обойти эту систему. Он знал чужие пароли, знал, когда в банке проходят проверки, хорошо разбирался в информационных технологиях .

Причины

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

Последствия

Его деятельность по итогам 2007 г. принесла банку около 2 млрд евро прибыли. Во всяком случае так говорит сам Кервьель, утверждая, что руководство банка наверняка знало, чем он занимается, но предпочитало закрывать глаза до тех пор, пока он был в прибыли .

Закрытие открытой Кервьелем рискованной позиции привело к убыткам в 4,9 млрд евро.

В мае 2008 г. Даниэль Бутон покинул пост генерального директора Societe Generale, на этой должности его сменил Фредерик Удеа . Год спустя он был вынужден уйти и с поста председателя совета директоров банка. Причиной ухода стала острая критика со стороны прессы: Бутона обвиняли в том, что подконтрольные ему топ-менеджеры банка поощряли рискованные финансовые операции, осуществляемые сотрудниками банка.

Несмотря на поддержку совета директоров, давление на господина Бутона усиливалось. Его отставки требовали акционеры банка и многие французские политики. Президент Франции Никола Саркози также призвал Даниэля Бутона уйти с поста, после того как стало известно, что в течение полутора лет до скандала компьютерная система внутреннего контроля Societe Generale 75 раз, т. е. всякий раз как Жером Кервьель осуществлял несанкционированные операции, выдавала предупреждение о возможных нарушениях .

Сразу после обнаружения потерь Societe Generale создал специальную комиссию по расследованию действий трейдера, в которую вошли независимые члены совета директоров банка и аудиторы PricewaterhouseCoopers. Комиссия пришла к выводу, что система внутреннего контроля в банке была недостаточно эффективной. Это привело к тому, что банк не смог предотвратить столь крупное мошенничество. В отчете говорится, что «сотрудники банка не проводили систематических проверок» деятельности трейдера, а сам банк не располагает «системой контроля, которая могла бы предотвратить мошенничество» .

В отчете о результатах проверки трейдера говорится, что по итогам расследования принято решение «существенно укрепить процедуру внутреннего надзора за деятельностью сотрудников Societe Generale». Это будет сделано при помощи более строгой организации работы различных подразделений банка и координации их взаимодействия. Также будут приняты меры, позволяющие отслеживать и персонифицировать трейдерские операции сотрудников банка посредством «укрепления системы ИТ-безопасности и разработки высокотехнологичных решений по персональной идентификации (биометрии)».

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