Примеры авиационных происшествий и инцидентов. Описание ключевых процессов управления ит-услугами. Управление Уровнем Услуг

Действует Редакция от 27.12.2007

Наименование документ	"НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ. ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ. МЕНЕДЖМЕНТ ИНЦИДЕНТОВ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ. ГОСТ Р ИСО/МЭК ТО 18044-2007" (утв. Приказом Ростехрегулирования от 27.12.2007 N 513-ст)
Вид документа	приказ, стандарт, гост
Принявший орган	ростехрегулирование
Номер документа	18044-2007
Дата принятия	01.01.1970
Дата редакции	27.12.2007
Дата регистрации в Минюсте	01.01.1970
Статус	действует
Публикация	На момент включения в базу документ опубликован не был
Навигатор	Примечания

"НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ. ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ. МЕНЕДЖМЕНТ ИНЦИДЕНТОВ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ. ГОСТ Р ИСО/МЭК ТО 18044-2007" (утв. Приказом Ростехрегулирования от 27.12.2007 N 513-ст)

6 Примеры инцидентов информационной безопасности и их причин

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

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

6.1 Отказ в обслуживании

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

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

Существует два основных типа инцидентов ИБ, связанных с отказом в обслуживании, создаваемых техническими средствами: уничтожение ресурсов и истощение ресурсов.

Некоторыми типичными примерами таких преднамеренных технических инцидентов ИБ "отказ в обслуживании" являются:

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

Передача данных в непредусмотренном формате в систему, сервис или сеть в попытке разрушить или нарушить их нормальную работу;

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

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

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

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

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

Случайным нанесением ущерба аппаратуре и (или) ее местоположению от огня или воды/наводнения;

Экстремальными условиями окружающей среды, например высокой температурой (вследствие выхода из строя системы кондиционирования воздуха);

Неправильным функционированием или перегрузкой системы;

Неконтролируемыми изменениями в системе;

Неправильным функционированием программного или аппаратного обеспечения.

6.2 Сбор информации

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

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

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

Типичными примерами атак, направленных на сбор информации техническими средствами, являются:

Сбрасывание записей DNS (системы доменных имен) для целевого домена Интернета (передача зоны DNS);

Отправка тестовых запросов по случайным сетевым адресам с целью найти работающие системы;

Зондирование системы с целью идентификации (например, по контрольной сумме файлов) операционной системы хоста;

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

Сканирование одного или нескольких сервисов с известными уязвимостями по диапазону сетевых адресов (горизонтальное сканирование).

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

Инциденты, направленные на сбор информации, создаваемые нетехническими средствами, приводят к:

Прямому или косвенному раскрытию или модификации информации;

Хищению интеллектуальной собственности, хранимой в электронной форме;

Нарушению учетности, например, при регистрации учетных записей;

Неправильному использованию информационных систем (например, с нарушением закона или политики организации).

Инциденты могут вызываться, например, следующими факторами:

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

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

6.3 Несанкционированный доступ

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

Попытки извлечь файлы с паролями;

Атаки переполнения буфера с целью получения привилегированного (например, на уровне системного администратора) доступа к сети;

Использование уязвимостей протокола для перехвата соединения или ложного направления легитимных сетевых соединений;

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

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

Разрушением устройств физической защиты с последующим несанкционированным доступом к информации;

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

Инцидент (incident или INC ) – любое событие (сбои, запросы на консультации и т.п,), не являющееся частью нормальной работы услуги, ведущее/способное привести к остановке услуги или снижению уровня её качества.

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

Для успешного управления инцидентами необходимо создание диспетчерской службы (Service desk ), которая должна являться единой точкой контакта с пользователями и координирует устранение инцидентов. Service Desk - подразделение (в терминологии ITIL «функция»), обеспечивающее единую и единственную точку входа для всех запросов конечных пользователей и унифицированную процедуру обработки запросов.

Эскалация – механизм, служащий своевременному разрешению INC с помощью привлечения дополнительных знаний (функциональная эскалация) или полномочий (иерархическая эскалация). Цель - решить INC в срок указанный в SLA .

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

Различают функциональную и иерархическую эскалацию:

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

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

Маршрутизация инцидента, или функциональная эскалация определяется требуемым уровнем знаний, полномочий и срочностью. Первой линией поддержки (называемой также поддержкой 1-го уровня) обычно является Служба Service Desk , второй линией – подразделений, осуществляющие Управление ИТ-инфраструктурой, третья – отделы разработки и архитектуры программного обеспечения, и четвертая – поставщики. Чем меньше организация, тем меньше в ней уровней эскалации . В больших организациях Руководитель Процесса Управления Инцидентами может назначить Координаторов инцидентов в соответствующих подразделениях для поддержки своей деятельности. Например, координаторы могут играть роль интерфейса между процессной деятельностью и линейными организационными подразделениями. Каждый из них координирует деятельность собственных групп поддержки.

Разграничение между инцидентами и проблемами вероятно является одним из самых известных, но не самых популярных вкладов библиотеки ITIL в развитие ИТ Сервис-менеджмента. Хотя это раз­граничение иногда может запутывать, но его главное достоинство заключается в установлении разли­чия между быстрым восстановлением услуги и установлением причины инцидента и ее устранением.

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

Hank Marquis предлагает 6 основных аспектов процесса управления инцидентами :

1. Создание базы данных записей обо всех инцидентах . Необходимо фиксировать все возникающие инциденты, независимо от способа их поступления (электронная почта, телефонный звонок, факс и т.д.). Вся информация о ходе решения инцидента так же должна фиксироваться в базе данных.
2. Создание базы знаний , где будет содержаться дополнительная информация для разрешения инцидента. Чем больше информации, тем лучше. В ITIL это базы данных управления конфигурацией (CMDB) и/или системы управления конфигурацией (CMS).
3. Разработайте и утвердите четкие инструкции и правила обработки инцидентов (регистрация, классификация, определение приоритета, анализа и т.д.).
4. Определите, в привязке к SLA, процедуры , которые позволят вам управлять воздействием (impact) инцидента на бизнес.
5. Создайте модель «основного инцидента» – набор правил четко описывающих очень серьёзный инцидент. Под основным инцидентом понимается такой, который затрагивает критичный бизнес-сервис и/или большое количество заказчиков и пользователей. В любом случае, основной инцидент требует немедленной эскалации, уведомления заказчиков и другой специальной обработки. Вся суть заключается в том, что такой инцидент требует максимальной реакции со стороны ИТ-организации.
6. Информируйте тех, кто сообщил вам об инциденте, о статусе работ . Вам необходимо представлять, кому и как часто необходимо направлять информацию. Например, Вы можете уведомить об инциденте заказчиков и пользователей. Вы должны также проинформировать их о невозможности вернуть уровень предоставляемого сервиса к согласованным параметрам в согласованное время.

Если у вас не реализован хотя бы один из этих 6 пунктов, то, в соответствии со стандартом ISO/IEC 20000-1 (Service Management), сфокусировавшись на нем, вы сможете улучшить качество сервиса. Если же все пункты у вас реализованы, то, скорее всего, вам уже не нужно тратить много времени на внедрение процесса управления инцидентами – сосредоточьтесь на других областях ITIL, таких как Управление проблемами (Problem Management ) или Управление изменениями (Change Management ).

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

Запрос на обслуживание – это Запрос от Пользователя на поддержку, предоставление информации, консультации или документации, не являющийся сбоем ИТ-инфраструктуры.

Примеры Запросов на Обслуживание:

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

Для того чтобы можно было отличить “настоящие инциденты ” от “инцидентов-Запросов на Обслу­живание “, рекомендуется присваивать Запросам на Обслуживание специальную категорию.

При одновременной обработке нескольких инцидентов необходимо расставлять приоритеты . Обос­нованием для назначения приоритета служит уровень важности ошибки для бизнеса и для пользо­вателя. На основе диалога с пользователем и в соответствии с положениями Соглашений об Уров­нях Услуг (Service Level Agreements – SLAs ) Служба Service Desk назначает приоритеты, определя­ющие порядок обработки инцидентов. При эскалации инцидентов на вторую, третью или более ли­нии поддержки, тот же приоритет должен быть соблюден, но иногда он может быть скорректирован по согласованию со Службой Service Desk.

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

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

5.3.1 Обработка Инцидента.

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

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

На Рисунке 5.2 показаны процессы, происходящие в течение жизненного цикла Инцидента. В Приложении 5Д эти процессы представлены с другой точки зрения.

Рисунок 5.2 - Жизненный цикл Инцидента.

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

■ новый;.

■ принят;.

■ определены сроки;.

■ назначен/передан специалисту;.

■ в работе (Work In Progress, WIP);.

■ ожидание;.

■ разрешен;.

■ закрыт.

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

■ обновить исторические сведения;.

■ изменить статус (например, со статуса «новый» на статус «в работе» или «ожидание»);.

■ изменить влияние на бизнес и приоритет;.

■ ввести потраченное время и затраты;.

■ отследить статус эскалации.

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

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

■ имя человека, сделавшего изменение в записи;.

■ дата и время изменения;.

■ что именно этот человек изменил (например, приоритет, статус, историю);.

■ почему было внесено изменение;.

■ потраченное время.

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

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

5.3.2 Первая, вторая и третья линии поддержки.

Часто подразделения и (специализированные) группы поддержки, не входящие в состав Службы Service Desk, называются группами поддержки второй или третьей линии. Они обладают более специализированными навыками, дополнительным временем или другими ресурсами для разрешения Инцидентов. Исходя из этого, Служба Service Desk называется первой линией поддержки. На Рисунке 5.3 показано, как эта терминология связана с действиями в процессе Управления инцидентами, о которых говорилось в предыдущих параграфах.

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

Рисунок 5.3 ~ Первая, вторая и третья линии поддержки.

5.3.3 Сравнение функциональной и иерархической эскалации.

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

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

«Иерархическая эскалация» может произойти в любой момент процесса разрешения, если существует вероятность того, что разрешение Инцидента не удастся завершить вовремя или оно окажется неудовлетворительным. В случае, если не хватает знаний или квалификации, иерархическая эскалация обычно производится вручную (Службой Service Desk или другим персоналом поддержки). Возможность проведения автоматической иерархической эскалации может рассматриваться после некоторого критичного периода времени, когда становится очевидным, что своевременно разрешить Инцидент не удастся. Предпочтительно, чтобы эскалация происходила задолго до истечения времени, отведенного (в SLA) на разрешение. Это позволит линейному руководству, имеющему соответствующие полномочия, принять меры по исправлению ситуации, например нанять специалистов внешнего поставщика.

5.3.4 Приоритет.

Приоритет Инцидента первоначально определяется его влиянием на бизнес и срочностью, с которой необходимо обеспечить разрешение или Обходное решение. Целевые показатели для разрешения Инцидентов или обработки запросов обычно включаются в SLA. На практике целевые показатели разрешения Инцидентов часто связаны с категориями. Примеры категорий и приоритетов, а также систем их кодирования, можно найти в Приложениях 5А и 5Б соответственно.

Службе Service Desk отводится важная роль в процессе Управления инцидентами:.

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

■ основная масса Инцидентов (возможно, до 85% при высоком уровне навыков персонала) будет разрешена Службой Service Desk;.

■ Служба Service Desk - «независимое» подразделение, которое наблюдает за ходом разрешения всех зарегистрированных Инцидентов.

Ниже приведен перечень основных действий, которые выполняются Службой Service Desk после получения уведомления об Инциденте:.

■ запись основных сведений - включая время и полученные подробности о симптомах;.

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

■ для дополнения записи об Инциденте на основе CMDB происходит выбор Учетных элементов (УЭ), являющихся, по сообщению, причиной Инцидента;.

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

■ оценка Инцидента и, по возможности, предоставление рекомендаций по его разрешению: часто это возможно для стандартных Инцидентов или, когда его причиной является известная Проблема/ошибка;.

■ закрытие записи об Инциденте после его успешного разрешения: добавление сведений о действиях, связанных с разрешением, и установка соответствующего кода категории;.

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

5.3.5 Связи между Инцидентами, Проблемами, Известными ошибками и Запросами на Изменение (RFC).

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

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

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

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

Успешная обработка записи о Проблеме приведет к идентификации корневой ошибки; эта запись может стать записью Известной ошибки после того, как разработано Обходное решение и/или RFC. Эта логическая цепочка, от первоначального уведомления до разрешения исходной проблемы, показана на Рисунке 5.4.

Рисунок 5.4 - Связи между Инцидентами, Проблемами, Известными ошибками и Запросами на Изменение (RFC).

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

■ Проблема: неизвестная исходная причина одного и более Инцидентов.

■ Известная ошибка: Проблема, которая успешно диагностирована и для которой известно Обходное решение.

■ RFC: Запрос на Изменение любого компонента ИТ-инфраструктуры или любого аспекта ИТ-услуг.

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

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

Когда процесс Управления инцидентами находит Обходное решение, оно будет проанализировано командой Управления проблемами, которая потом обновит соответствующую запись о Проблеме (см. Рисунок 5.5). Необходимо отметить, что соответствующая запись о Проблеме может в этот момент еще не существовать например, Обходное решение может состоять в том, чтобы отослать отчет по факсу из-за сбоя в канале связи, но записи о Проблеме по поводу этого сбоя в канале связи может еще не быть; в этом случае команда Управления проблемами должна ее создать. Итак, в процесс входят действия, когда Служба Service Desk связывает Инциденты, которые являются результатом зарегистрированной Проблемы.

Рисунок 5.5 - Обработка Обходных решений и разрешений инцидента.

Также возможно, что группа Управления проблемами во время расследования Проблемы, связанной с Инцидентом, найдет Обходное решение или разрешение самой Проблемы и/или некоторых связанных с ней Инцидентов. В этом случае группа Управления проблемами должна сообщить об этом процессу Управления инцидентами для того, чтобы изменить статус открытых Инцидентов на «Известная ошибка» или «Закрыт».

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

11 октября 2012 в 10:58

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

• Информационная безопасность

Доброго дня, уважаемый хабрахабр!

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

Информирование об инцидентах

Перво наперво необходимо получить информацию об инциденте. Этот момент необходимо продумать ещё на этапе формирования политики безопасности и создания презентаций по ликбезу в ИБ для сотрудников.
Основные источники информации:

1. Helpdesk.
Как правило (и это хорошая традиция) о любых неполадках, неисправностях или сбоях в работе оборудования звонят или пишут в хелпдеск вашей IT-службы. Поэтому необходимо заранее «встроиться» в бизнес-процесс хелпдеска и указать те виды инцидентов, с которыми заявку будут переводить в отдел информационной безопасности.

2. Сообщения непосредственно от пользователей.
Организуйте единую точку контакта, о чём сообщите в тренинге по ИБ для сотрудников. На данный момент отделы ИБ в организациях, как правило, не очень большие, зачастую из 1-2 человек. Поэтому будет несложно назначить ответственного за приём инцидентов, можно даже не заморачиваться с выделением адреса электропочты под нужды IS Helpdesk.

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

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

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

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

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

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

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

5. Компрометация учетных записей.
Этот пункт перекликается с 3 . Фактически инцидент переходит из 3 в 5 категорию, если в ходе расследования инцидента выясняется, что пользователь в этот момент физически и фактически не мог использовать свои учётные данные.

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

С этим пунктом в работе с инцидентами можно поступить 2-мя путями: простым и сложным.
Простой путь: взять соглашение об уровне сервиса вашей IT-службы и подогнать под свои нужды.
Сложный путь: на основе анализа рисков выделить группы инцидентов и/или активов, в отношении которых решение или устранение причин инцидента должны быть незамедлительными.
Простой путь неплохо работает в небольших организациях, где не так уж и много закрытой информации и нет огромного количества сотрудников. Но стоит понимать, что IT-служба исходит в SLA из своих собственных рисков и статистики инцидентов. Вполне возможно, что зажевавший бумагу принтер на столе генерального директора будет иметь очень высокий приоритет, в том случае, как для вас важнее будет компрометация пароля администратора корпоративной БД.

Сбор свидетельств инцидента

Есть особенная прикладная наука - форензика, которая занимается вопросам криминалистики в области компьютерных преступлений. И есть замечательная книга Федотова Н.Н. «Форензика - компьютерная криминалистика». Я не буду сейчас расписывать детально аспекты форензики, просто выделю 2 основных момента в сохранении и предоставлении свидетельств, которых необходимо придерживаться.

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

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

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

Переоценка рисков, повлекших возникновение инцидента
подготовка перечня защитных мер для минимизации выявленных рисков, в случае повторения инцидента
актуализация необходимых политик, регламентов, правил ИБ
провести обучение персонала организации, включая сотрудников IT, для повышения осведомленности в части ИБ

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

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

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

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

mailto:%[email protected]

[email protected]

Кроме того, 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 млн гривен.

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

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

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

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

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

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

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