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

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

ТТХ

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

IT-инфраструктура представляет собой следующее:

• серверы располагаются в демилитаризованной зоне, доступ по сети в ДМЗ ограничивается межсетевыми экранами;
• повсеместно введена виртуализация серверов;
• присутствует сегментация сети с ограничением доступа между сегментами. Рабочие станции разнесены по VLAN’ам, с фильтрацией трафика между ними, в соответствии с внутренней иерархией;
• права доступа пользователям выделяются по принципу минимальных привилегий;
• централизовано софт обновляется только для продуктов Microsoft;
• ведется централизованный мониторинг серверов, правда, в основном с позиции доступности.

Инцидент

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

Прекрасное солнечное утро омрачилось: смартфоны и планшеты всех собравшихся в отеле на берегу океана (и не только их) оказались девственно чисты.

Данная информация была доведена до службы безопасности, которая разумно предположила, что тут не обошлось без внешнего вмешательства. Очевидно, что у всех сразу аккаунты iCloud взломать не могли, и служба безопасности заподозрила, что угроза исходит из корпоративной сети. Удаленно очистить мобильные устройства можно только через соответствующий сервис, например через корпоративный сервер Microsoft Exchange. Команда, позволяющая очистить устройство пользователя с адресом [email protected], выглядит следующим образом:

Clear-MobileDevice -Identity WM_TonySmith -NotificationEmailAddresses "[email protected]"

ИТ-службе поставили задачу проверить журналы сервера OWA: не было ли подозрительной активности в отношении аккаунтов пострадавших и компрометации пароля администратора сервера MS Exchange. Администраторы обнаружили зацепку - доступ к аккаунтам пострадавших в предшествующие инциденту дни неоднократно осуществлялся с нескольких нетипичных для них IP-адресов. Как я позже выяснил, засвеченные IP-адреса были выходными Tor-нодами.

Анализ логов OWA

Логи OWA хранятся по умолчанию в %SystemRoot%\System32\logfiles\w3svc1 . Структура логов - обычные текстовые файлы, изучать которые без вспомогательного инструмента, особенно при большом количестве пользователей, утомительно. На помощь придет Log Parser - очень ценный инструмент, который пригодится не только в подобной ситуации.

Для удобства преобразуем все имеющиеся логи в один файл формата CSV:

C:\Program Files\Log Parser 2.2>LogParser.exe -i:iisw3c "select * into d:\temp\alllog.log from %SystemRoot%\System32\logfiles\w3svc1\*" -o:csv

После чего составим список событий, отражающих доступ пользователей к OWA:

C:\Program Files\Log Parser 2.2>LogParser.exe -i:csv "select cs-username, date,time, c-ip, cs-uri-stem, cs(User-Agent) FROM d:\temp\alllog.log to d:\temp\access.csv" -o:csv

Выясняем, кто обращался к функциям OWA, отвечающим за удаление данных с устройства:

C:\Program Files\Log Parser 2.2>LogParser.exe -i:csv "select cs-username, date, time, c-ip, cs-uri-stem, cs-uri-query, cs(User-Agent) FROM d:\temp\alllog.log to d:\temp\access2.csv WHERE cs-uri-query LIKE "%wipe%"" -o:csv

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

Поставили они такие задачи:

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

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

Перепроверил результаты анализа логов администраторами. С помощью ntfswalk проанализировал MFT на наличие удаленных в последнее время файлов. Сервер OWA был чист и нетронут.

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

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

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

Так как у меня в исследовании были только образы виртуальных машин, процедура несколько упрощалась - не нужно тратить время на снятие образов жесткого диска и оперативной памяти. Файлы жестких дисков виртуальных машин можно либо конвертировать в raw , либо монтировать как есть, с помощью соответствующих утилит. Образ RAM и файл сохраненного состояния можно сконвертировать в «сырой» образ. Не стоит забывать и про файлы подкачки - в них тоже порой находится много интересного. Volatility версии 2.3 умеет все это разбирать и конвертировать в случае необходимости.

Отличия работы с физической системой от виртуальной в том, что образ памяти заполучить сложнее - это связано с риском повредить текущее состояние и потерять данные, которые могут оказаться существенными. Также при исследовании физической системы необходимо применять дополнительные инструменты и методики для определения скрытых областей (например, Host Protected Area - HPA и Device Configuration Overlay - DCO).

Обследовать Windows-машины в моем случае я решил по следующему сценарию:

Помимо этого, можно извлечь содержимое процесса в файл для дальнейшего исследования.

След найден

В оперативной памяти одного из контроллеров домена обнаружились явные признаки компрометации:

• процесс svchost.exe запущен из C:\Windows\WOW64 , а не из System32 , как ему полагается;
• исходящие сетевые соединения, на IP-адрес частного хостинга в Штатах;
• неизвестный процесс запущен с PPID , не отображающимся в списке процессов.

Процесс был идентифицирован с помощью утилиты vol.exe .

Vol.exe pslist -f image.vmem --profile=Win2008R2SP1x64 >pslist Offset(V) Name PID PPID 0xfffffa801996cb30 spintlx64.exe 2820 1388 ....

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

vol.exe dumpfiles -r spintlx64 -f image.vmem —profile=Win2008R2SP1x64 -D ./

При проверке на VirusTotal показатель выявления был 34/50. При поверхностном анализе обнаружилось, что дата компиляции и сборки бинарника 1992-06-19 22:22:17 , а найденный при офлайн-анализе образа диска файл имел типичные для малвари изменения в атрибутах. Дата создания, изменения, последнего обращения были одинаковы и гораздо старше остальных системных файлов. Файл имел небольшой вес, создавал логи в зашифрованном виде и отправлял их по сети посредством HTTPS. С виду - типичный кейлоггер. Интересно, теперь предстоит разобраться, откуда и когда он попал в систему.

После восстановления данных все лог-файлы были загружены в Event Log Explorer для дальнейшего анализа. Штатные средства в такой ситуации не подходят: они не так поворотливы при поиске, а размеры логов очень большие (>30 Гб).

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

Обследование Linux-системы концептуально не отличается от обследования Windows-системы. Ищем все то же самое: историю действий, производимых с системой. Если копнуть глубже, то исследовать можно все, от аппаратного уровня до истории запуска Microsoft Paint или набранных текстов. Но к счастью, обычно такой задачи не стоит. Зачастую задача достаточно конкретна и нет необходимости тратить время на то, что не принесет результата.

В данном случае предстояло обследовать Linux-систему на предмет несанкционированного доступа. О сервере предварительно было известно следующее: установлен Suse Linux , Apache + PHP + MySQL + Zabbix с сопутствующим программным обеспечением - всем знакомым LAMP . Выяснилось, что сотрудник, ответственный за сервер, с ОС Linux общается на «вы». Установил и обслуживал сервер его предшественник, который давно ушел из компании.

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

Изучать образ содержимого оперативной памяти системы Linux можно тем же комплектом Volatility, желательно последнего стабильного релиза, хотя после версии 2.0 он вполне справляется. Существует некоторая разница в сравнении с анализом образов RAM семейства Windows - в Volatility нет и в принципе не может быть шаблонов структуры памяти для каждого ядра. Поэтому шаблон придется создать. Для этого необходимо:

• запустить копию исследуемой системы;
• скопировать туда директорию volatility/tools/linux ;
• собрать проект, получив в результате файл module.dwarf , и скопировать его вместе с актуальным /boot/System.map того ядра, на котором работала система при снятии образа RAM, обратно на систему исследователя;
• упаковать оба файла, например в Linux.zip , и поместить архив в volatility/plugins/overlays/linux/ .

Теперь при запуске Volatility с ключом --info созданный тобой профайл будет виден в списке и с ним уже можно начать работу над образом. Без этого ничего не получится, потому что Volatility необходимо знать структуры данных ядра (module.dwarf) и иметь имена переменных, функций и их адреса в памяти (System.map).

Вернемся к исследованию. У меня было подозрение, что система, на которой установлен Zabbix, был скомпрометирована. Осталось понять, как и кто это сделал. Лишних ключей для SSH, посторонних учетных записей в системе не обнаружилось. Я предположил, что в системе есть backdoor , а возможно, и руткит. Для установки подобного рода софта зачастую требуются максимальные привилегии. Это очевидно, достаточно вспомнить основные принципы работы более-менее передовых руткитов в Linux-системах:

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

подмена системных файлов.

В первую очередь необходимо было проверить самые простые вещи, а именно историю выполненных команд: vol -f image.vmem -profile=Linux,x86 linux_bash

История команд была совсем небольшой, и первое, что бросилось в глаза, - это insmod rt.ko . Кстати, в файле истории на диске, конечно, ничего подобного не было, более того, восстановить какие-либо данные из файла истории также не удалось - содержимое уже было перезаписано быстро генерирующимися логами. Так что без образа памяти эти данные были бы неизвестны. Далее предстояло найти упомянутый в истории команд модуль ядра. Модуль был обнаружен на диске в директории PHP-скриптов интерфейса Zabbix.

Последующий анализ этого файла показал, что он прячет сам себя, маскирует при необходимости файлы, предоставляет привилегии root по команде. Управление ведется через файловую систему /proc/rt . С сетью не взаимодействует.

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

Я обратил внимание на Zabbix и пожалел, что не присмотрелся к нему раньше, - версия была подозрительно старая - 1.8.4 . Поиск по exploit-db.com показал, что в данной версии в скрипте popup.php присутствует SQL-инъекция, позволяющая получить хеши пользователей (CVE: 2011-4674). Проверка уязвимости показала ее полную работоспособность.

Схема подключения злоумышленника стала очевидна: через веб-шелл запускался back connect , предоставляющий интерактивный шелл, после чего привилегии повышались с помощью руткита. При такой схеме злоумышленник использовал этот хост как промежуточный для передачи зловреда на контроллер домена, а также для передачи базы ntds.dit и SYSTEM . Для эффективного поиска с помощью утилиты md5deep была создана база MD5-хешей всех файлов, восстановленных с образа сервера, после чего среди них произведен поиск хеша кейлоггера. Как результат - искомый файл был найден (правда, не с тем именем), а рядом лежал psexec и другие сопутствующие утилиты, которые были удалены.

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

Кстати говоря, Zabbix хранит скрипты в БД, и их следы были обнаружены в файле ibdata1.

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

Ради эксперимента я попробовал сбрутить хеши пользователей домена. Легко и непринужденно за пару часов были вскрыты 90% паролей.

По всей видимости, когда злоумышленнику надоело просто читать почту, он решил ее удалить - тем самым развлечься, или отомстить, или выполнить заказ конкурентов? Его мотивация мне неизвестна.

В итоге система Zabbix была переведена в изолированный сегмент, сетевой трафик поставлен на запись, настроена IDS. Я ждал подключений хулигана, но это уже совсем другая история…

Как защитить свой iDevice

Любой iDevice общается с корпоративным сервером Exchange при помощи протокола ActiveSync. С позиции пользователя - защититься по умолчанию никак нельзя. Политика сервера Exchange подразумевает, что если устройство подключено к корпоративной сети, то администратор должен иметь возможность когда угодно управлять этим устройством для прекращения доступа к конфиденциальной информации. Помимо этого, пользователь, в случае утери или кражи, может зайти в OWA через любой браузер и запустить процесс удаленной очистки.

Если в организации имеется понимающий администратор Exchange - обратиться к нему и попросить убрать права на выполнение данной операции, а еще лучше - убрать доступ к пункту «Мобильные устройства» из веб-интерфейса OWA.

Вердикт

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

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

Метод критических инцидентов.

Выявление критического инцидента - это метод, предназначенный для иден-

тификации процесса, подпроцесса или проблемной области, которые стоит со-

вершенствовать. Метод разработан Лолором в 1985 году . Это вполне откры-

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

в изложении своих взглядов. Любая цензура или сокрытие информации из бояз-

ни, что она окажется слишком честной, решительно отвергается.

Метод включает три этапа:

1). Выбираются участники проведения анализа. Если цель заключается в при-

нятии решения о совершенствовании всего процесса целиком, то естественно

включить представителей различных областей в организации. Если же це-

лью является более точное определение направленности действий в рамках

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

этот процесс.

2). Затем участникам обсуждения предлагается ответить на вопросы типа:

С каким инцидентом на прошлой неделе было труднее всего справиться?

Какой эпизод создал наибольшие проблемы для удовлетворения потреб-

ностей потребителя?

Какой инцидент обошелся дороже всего с точки зрения привлечения

дополнительных ресурсов или прямых расходов?

На этом этапе использования метода важно выделить так называемые кри-

тические инциденты, которые тем или иным способом создают проблемы

для отдельных сотрудников, для всей организации и для других заинтересо-

ванных сторон. Период, к которому относится вопрос, может варьироваться

от нескольких дней до нескольких месяцев. Не рекомендуется, однако, вы-

бирать слишком долгий период, так как в этом случае может оказаться зат-

руднительным выделить самый актуальный критический инцидент, потому

что для большого периода времени таких инцидентов могло быть много.

3). Собранные ответы сортируются и определяется, какой из различных инци-

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

удобно использовать графическое представление полученных результатов. Тот

инцидент, который встретился чаще других, и будет критическим. Он - яв-

ный кандидат на профилактику. Однако бороться нужно не столько с самим

инцидентом и его симптомом, сколько с причинами, его породившими.

Пример.

Большая корпорация, имевшая в штате 15 телефонисток, приступила

к проекту улучшения телефонного обслуживания потребителей при от-

ветах на звонки. Было решено воспользоваться методом выявления кри-

тического инцидента.

Всем телефонисткам было предложено описать те инциденты, имев-

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

повторения инцидентов. Они представлены на рис. 7.1 в виде диаграммы. Из ри-

сунка видно, что критическими инцидентами были: 1) невозможность дозвониться до

человека, которому следовало бы отвечать на звонок, 2) незнание, кто именно дол-

жен отвечать. На основании результатов исследования были предприняты усилия

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

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

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

наченная для регистрации данных, Ролстадос (1995) . Одно из основных при-

ложений контрольного листка заключается в том, чтобы фиксировать, как часто

встречаются различные проблемы или инциденты. Это дает важную информа-

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

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

следует сконцентрировать усилия при проведении совершенствования.

Заполнение контрольного листка обычно идет в несколько этапов:

1) Достижение соглашения о том, какие события надо записывать. Все это надо

точно определить, чтобы не было сомнений в том, имело ли место событие

на самом деле. Желательно также включить в контрольный листок позицию

«Прочее», чтобы зарегистрировать инциденты, которые трудно отнести в

2) Определение периода регистрации данных и его удобного деления на интер-

3) Разработка формы (бланка) контрольного листка, используемого для регис-

трации. 4) Сбор данных происходит в течение всего согласованного периода времени.

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

сборе данных одинаково понимают суть происходящего. Тогда собранные

разными людьми данные будут состоятельными.

5) По окончании сбора данных производится их анализ для выявления собы-

тий, имеющих наивысшую частоту проявления. Это позволит определить

приоритеты проблемных областей в рамках заданного бизнес-процесса для

обеспечения акцентов в работе по совершенствованию. Удобное вспомога-

тельное средство для проведения такого анализа - диаграмма ПаретоДиаграмма Парето

Построение этой схемы основано на так называемом принципе Парето, сфор-

мулированном итальянским математиком Вильфредо Парето в 1800-х годах. Под-

робности данной схемы можно найти также в книге Ролстадоса . Парето был

озабочен распределением богатств в обществе и считал, что 20% населения вла-

деют 80% всех богатств. В переводе на современный язык систем качества этот

принцип заключается в том, что часто примерно 80% всех возможных проявлений

обусловлены примерно 20% всех возможных причин. Разумный подход в этом

случае - начать работу по совершенствованию с атаки именно на эти 20% при-

чин, которые обычно называют «жизненно важным меньшинством». Это совсем

не означает, что можно игнорировать оставшиеся 80% причин: в надлежащий

момент времени этими причинами, которые называют «этим важным большин-

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

блем, за решение которых следует браться.

Диаграмма Парето сама по себе представляет графическую интерпретацию в

виде скошенного распределения так называемого правила «80/20». Это причины,

рассортированные по степени важности, по частоте возникновения, по затратам,

по уровню показателей и т.д. При упорядочивании причин на диаграмме Парето

самые важные из них относят к левому краю схемы, так, чтобы это «жизненно

важное меньшинство» было легко идентифицировать. Для повышения информа-

тивности диаграммы Парето обычно на нее наносят и кривую накопленных час-

тот. Пример построения диаграммы представлен на рис. 7.4.

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

1). Определите главную проблему события и ее различные потенциальные при-

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

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

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

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

2). Определите, какой количественный показатель будет использоваться при

сравнении возможных причин. В качестве такого показателя можно было бы

взять частоту возникновения разного рода проблем или их следствий в тер-

минах денежных затрат и других условий.

3). Определите период времени, в течение которого будут собраны данные и со-

берите их. Часто эта работа уже оказывается выполненной ранее при за-

полнении контрольных листков. Суть контрольного листка описана в § 7.2.

4). Расположите причины слева направо вдоль горизонтальной оси диаграммы

Парето по убыванию степени их относительной важности. Нарисуйте стол-

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

ветствующей причины. 5). Отметьтеполученные абсолютные значения показателей на левой вертикаль-

ной оси. Отметьте относительные значения показателей в процентах на пра-

вой вертикальной оси. Нарисуйте кривую накопления важности вдоль верх-

него края столбиков.

Изучение диаграммы Парето может дать ответ на вопросы типа: 1) «Что пред-

ставляют собой две-три основные причины низкого уровня показателей данного

процесса?» или 2) «Какова доля затрат, приходящихся на самые жизненно важ-

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

правленных на усилия по совершенствованию процесса в сторону достижения

его наивысших результатов.

Построение диаграммы Парето можно упростить, если пользоваться стандар-

тным компьютерным обеспечением, предназначенным для составления элект-

ронных таблиц. Вместе с тем для построения диаграмм Парето есть и специали-

зированное программное обеспечение. Две такие специализированные компьютерные программы - это StatGraphics Plus и ASAS/QC. Они также дают воз-

можность пользователю строить контрольные карты СУП"а. Отметим также пакет

Memory Jogger software, который может применяться с некоторыми инструментами

повышения качества.

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

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

Примеры авиационных происшествий и инцидентов.

Произошло несколько инцидентов высокого уровня и авиационных происшествий из-за человеческих факторов. Сайт интернета по Человеческим факторам при авиационном обслуживании и инспекциях (HFAMI) содержит 24 доклада NTSB об инцидентах, причинами которых стали человеческие факторы. В Великобритании произошло несколько происшествий и инцидентов. Подробности о них содержаться на сайте AAIB. Некоторые из этих инцидентов приведены ниже:

• Инцидент с Боингом-737,(Алоха рейс 243), Мауи, Гавайи, Апрель 1988;
• Инцидент с ВАС 1-11, G-BJRT (British Airways рейс 5390), Дидкот, Оксфордшир, 10 июня 1990.
• Инцидент с А-320, G-KMAM в Лондонском аэропорту Гатвик 26 августа 1993;
• Инцидент с Боингом-737, G-OBMM около Дэвинтри 23 февраля 1995.

Инцидент, произошедший с рейсом Алоха № 243 в апреле 1988 связан с тем, что 18 футов верхней обшивки кабины во время полета были сорваны. Самолет перед полетом проверялся согласно требованиям США двумя авиационными инспекторами. Один инспектор имел стаж работы 22 года, а второй, старший из них 33 года. Ни один не обнаружил трещин во время инспекции. Анализы, проведенные после инцидента обнаружили наличие свыше 240 трещин в обшивке этого самолета на время инспекции. Вытекающие из этого определили много проблем связанных с человеческими факторами ведущими к ненадлежащим инспекциям.

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

10 июня 1990г. в Великобритании самолет ВАС 1-11 (British Airways рейс 5390) вылетел из аэропорта Бирмингема. После набора высоты 17,300 футов в кабине пилотов было выдавлено давлением наружу левое лобовое стекло. Это стекло было заменено перед полетом. Оказалось, что из 90 крепящих болтов 84 оказались меньшего диаметра, чем необходимо. Командира корабля наполовину вытянуло из кабины через отверстие окна и его удерживали члены экипажа, пока второй пилот не произвел благополучную посадку в аэропорту Саутгэмптона.

Начальник смены (SMM) из-за недокомплекта людей во время ночной смены, решил провести замену лобового стекла самостоятельно. Он просмотрел Инструкцию (ММ) и пришел к выводу, что это простая работа. Он решил заменить крепежные болты и взяв один в качестве образца (7D)

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

Самолет А-320 в Великобритании в августе 1993г. Во время первого полета после замены закрылка произошло резкое сваливание направо сразу же после взлета. Самолет вернулся в Гатвик и благополучно приземлился. Расследование показало, что во время обслуживания, для того, чтобы заменить правый закрылок, спойлеры были переведены в режим обслуживания и сдвинуты при незавершенной процедуре; соответственно отбортовки и флажки не были установлены. Назначение отбортовок и спойлеров инженерами недостаточно понималось.

Это непонимание частично было вызвано знакомство и привычка к самолету другого

типа (Боинг 757) и выразилось в недостаточном обозначении состояния спойлеров во время передачи смен. Запертый спойлер не был обнаружен во время проведения пилотом стандартных проверок.

В феврале 1995г. на самолете Боинг 757-400 обнаружилась потеря давления масла на обоих двигателях. Самолет развернулся и благополучно приземлился в аэропорту Лутона. Расследование показало, что предыдущей ночью на самолете проводилось бороскопическое исследование обоих двигателей и кожухи приводов роторов высокого давления, после выполнения работ не были установлены. В результате этого, во время полета было потеряно почти все масло из обоих двигателей. Инженер по линейному обслуживанию первоначально должен был выполнить эту работу, но по различным причинам он передал работу контролеру базового обслуживания. Контролер не имел при себе необходимых документов по работам. Контролер и слесарь выполнили работу, не смотря на многочисленные перерывы, но не установили кожухи роторов. На земле не были проведены испытания двигателей на холостых оборотах для обнаружения течей масла. Работа была расписана как выполненная.

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

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

Инциденты и аварии – Нарушение человеческих факторов.

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

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

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