Управление инцидентами и проблемами — понятия и принципы. Расследование инцидента иб по горячим следам

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

Произошло несколько инцидентов высокого уровня и авиационных происшествий из-за человеческих факторов. Сайт интернета по Человеческим факторам при авиационном обслуживании и инспекциях (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. Цепь ошибок.

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

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

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

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

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

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

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

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

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

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

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

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

Аннотация

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

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

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

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

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

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

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

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

Причины

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

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

Последствия

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

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

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

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

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

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

Аннотация

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

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

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

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

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

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

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

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

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

Последствия

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

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

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

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

Аннотация

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

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

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

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

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

Последствия

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

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

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

Аннотация

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

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

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

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

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

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

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

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

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

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

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

Последствия

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

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

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

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

Аннотация

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

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

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

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

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

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

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

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

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

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

Причины

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

Последствия

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

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

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

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

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

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

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

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

Из книги Пенсия: расчет и порядок оформления автора Минаева Любовь Николаевна

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

Из книги Дейтрейдинг на рынке Forex. Стратегии извлечения прибыли автора Лин Кетти

2.5. Примеры Рассмотрим некоторые варианты назначения трудовых пенсий в случае передачи документов в территориальные органы Пенсионного фонда почтовым отправлением:Пример 1 Заявление о назначении трудовой пенсии по старости выслано в территориальный орган фонда

Из книги Практика управления человеческими ресурсами автора Армстронг Майкл

3.5. Примеры Пример 1 Трудовой стаж состоит из периодов работы с 15.03.1966 г. по 23.05.1967 г.; с 15.09.1970 г. по 21.05.1987 г.; с 01.01.1989 г. по 31.12.1989 г.; с 04.09.1991 г. по 14.07.1996 г.; с 15.07.1996 г. по 12.07.1998 г. и службы в армии с 27.05.1967 г. по 09.06.1969 г.Подсчитаем трудовой стаж для оценки пенсионных прав

Из книги автора

4.4. Примеры Пример 1 Инженер Сергеев А. П., 1950 г. р., обратился за назначением трудовой пенсии по старости в марте 2010 г. В 2010 г. ему исполнилось 60 лет. Общий трудовой стаж для оценки пенсионных прав на 01.01.2002 г. составляет 32 года 5 мес 18 дней, в том числе до 1991 г. – 30 лет.

Из книги автора

6.3. Примеры Пример 1 Менеджер по продаже Соколов В. Н. работал по трудовому договору с 01.01.2010 г.1 января 2013 г. он умирает в возрасте 25 лет. При этом у него остаются трудоспособные родители, трудоспособная жена и дочь в возрасте 3 лет. В этом случае право на получение трудовой

Из книги автора

7.4. Примеры Пример 1 Менеджер Васильев Р. С., 60 лет. Общий трудовой стаж по трудовой книжке для оценки пенсионных прав на 01.01.2002 г. составляет 40 лет. Среднемесячный заработок за 2000–2001 гг., по данным персонифицированного учета, – 4000 руб. Рассчитаем и сравним размеры пенсий по

Из книги автора

8.3. Примеры Пример 1 Пенсионер получает пенсию по инвалидности I группы. С 20 мая по 5 июня 2009 г. он проходил очередное переосвидетельствование в БМСЭ и был признан инвалидом III группы 3 июня 2009 г. Группа инвалидности в этом случае снизилась. Базовая часть пенсии подлежит

Из книги автора

10.4. Примеры Пример 1 Смерть пенсионера наступила 28 января 2009 г. За пенсией вдова пенсионера обратилась в феврале 2009 г. Совместное проживание вдовы с пенсионером на день смерти не установлено.По данному пенсионному делу территориальным органом фонда были приняты

Из книги автора

14.7. Примеры Пример 1 Кошкина В. Н., находившаяся на иждивении умершего мужа, достигла 55 лет через 3 месяца после его смерти. За назначением пенсии обратилась по истечении 1 года со дня смерти супруга.Согласно пенсионному законодательству, пенсия будет назначена со дня

Из книги автора

17.5. Примеры Пример 1 У индивидуального предпринимателя по трудовому договору работают четыре человека: Мороз К. В. (1978 г. р.), СветловаТ. Г. (1968 г. р.), Леонова Т. Н. (1956 г. р.) и Комаров С. Н. (1952 г. р.). Предположим, ежемесячная заработная плата каждого из них составляет 7000 руб.

Из книги автора

Примеры Рассмотрим некоторые примеры работы этой стратегии.1. 15-минутный график EUR/USD на рис. 8.8. В соответствии с правилами этой стратегии, мы видим, что EUR/USD упал и торговался ниже 20-дневной скользящей средней. Цены продолжали снижаться, двигаясь к 1,2800, которое является

Из книги автора

Примеры Изучим несколько примеров.1. На рис. 8.22 приведен 15-минутный график USD/CAD . Общий диапазон канала составляет примерно 30 пунктов. В соответствии с нашей стратегией, мы ставим ордера на вход на 10 пунктов выше и ниже канала, т. е. на 1,2395 и 1,2349. Ордер на покупку исполнен

Из книги автора

Примеры Рассмотрим некоторые примеры этой стратегии в действии.1. На рис. 8.25 показан дневной график EUR/USD . 27 октября 2004 г. скользящие средние EUR/USD образовали последовательный правильный порядок. Мы открываем позицию через пять свечей после начала формирования по 1,2820.

Инцидент (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.

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

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

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

Дискуссии на эту тему стары, как все вместе взятые методологии управления IT, тем не менее, давайте обратимся к первоисточникам.

Что нам говорит ITIL (официальный перевод глоссария по третьей версии):

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

Инцидент - незапланированное прерывание ИТ-услуги или снижение качества ИТ-услуги.

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

1) Христоматийный звонок пользователя с просьбой сбросить пароль - как его классифицировать, как запрос на обслуживание или как инцидент? Или, может быть, как инцидент информационной безопасности?

2) Звонок от пользователя, у которого не работает корпоративная почта. Беглый анализ обращения говорит о том, что пользователю необходимо провести первичную настройку почтового клиента. Тем не менее с его точки зрения это инцидент, т.к. сервис не доступен, а его никто не уведомил, что «сама почта не полетит»

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

Мое понимание этого вопроса сводится к вопросу оценки прерывания сервиса для конечного потребителя, и таким образом:

Инцидент - это, в большинстве случаев, прерывание или частичное прерывание ИТ-услуги, которая ранее предоставлялась пользователю в утвержденном режиме (сервис доступен 24/7, либо 5/8).

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

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

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

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

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. Оповестите сотрудников о наличие инцидента, что бы во-первых они не мешали вам в расследовании, во-вторых исключили пользование затронутыми активами на время расследования.

Вам могут быть интересны следующие материалы

Бизнес

Вопросы

Интернет

Недвижимость

Страхование

Услуги

© 2024 Финансы. Бизнес. Недвижимость. Услуги. Страхование