В очередной раз об инцидентах и сервисных запросах.

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

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

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