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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

размер шрифта

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ- ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ- МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ- МЕНЕДЖМЕНТ... Актуально в 2018 году

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

***

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

Литература

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

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

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

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

Приложения:

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

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

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

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

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

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

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

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

В словаре ITSM есть два понятия, которые очень часто создают путаницу у ИТ-специалистов и пользователей: инцидент (Incident) и проблема (Problem). Оба они связаны с процессом решения возникшего сбоя и регистрируются с помощью создания тикета в системе Сервис-Деска. Однако по своей сути они достаточно сильно отличаются друг от друга и имеют различные способы решения. Рассмотрим пример, который просто объясняет разницу между этими понятиями.

Сломался чайник!

Утро. На завтрак вы решил заварить себе чашечку крепкого чая, чтобы взбодриться перед рабочим днем. Наливаете воду в чайник, включаете его в розетку, щелкаете выключателем, а он не включается. Щелкаете выключателем снова и снова, проверяете, есть ли электричество в доме, включаете чайник в другую розетку, но он все равно не работает. Возник ИНЦИДЕНТ!

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

Теперь каждое утро вы будете использовать один из перечисленных способов для нагрева воды, пока не найдете время обратиться в мастерскую, чтобы электрик разобрался с ПРОБЛЕМОЙ, из-за которой чайник не работает. Проблема – это причина поломки чайника. Электрик обнаружит, что перегорел предохранитель из-за скачка напряжения, заменит предохранитель, и вы снова сможете кипятить воду в чайнике – проблема решена.

Какое отношение чайник имеет к ИТ?

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

Это просто, но очень эффективно!

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

Время выпить вкусного чая и проверить предохранители в других домашних приборах!

Youtube