Разбор понятий инцидента и конфликтной ситуации

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

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

Что такое инцидент: история, определение

В ITIL существует четкое определение инцидента (IT Incident) — это незапланированное прерывание ИТ-услуги или снижение качества ее предоставления. Другими словами, инцидентом можно назвать любую ситуацию, которая снижает качество предоставления услуг конечному потребителю и мешает бесперебойной работе бизнеса.

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

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

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

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

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

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

• Подготовьте несколько вариантов (моделей) создания заявок об инциденте, например, по телефону, на электронную почту, в чат, через портал самообслуживания.
• Сформируйте базу знаний и пополняйте ее готовыми решениями по управлению аналогичными инцидентами.
• Для эффективного сбора информации об инцидентах опубликуйте настраиваемые формы.
• Настройте автоматическую классификацию инцидентов и определение их приоритетности на основании ряда критериев в заявке.
• Создайте уникальные рабочие процессы по управлению серьезными IT Incident.
• Свяжите SLA с инцидентами на основе таких параметров, как приоритетность.
• Техническим специалистам с одинаковыми компетенциями можно автоматически назначать заявки, опираясь на такие алгоритмы, как циклический перебор и балансировка нагрузки.
• Настройте коммуникацию с пользователем на каждом этапе цикла решения инцидентов.
• Удостоверьтесь, что специалисты закрывают инциденты только после того, как найдено эффективное решение с получением обратной связи от конечного потребителя услуги.

Почему так сложно управлять инцидентами?

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

1. Необходим не только учет инцидентов, но и их приоритетная расстановка, от которой зависит правильное распределение времени на решение задачи.
2. Нужно координировать работы сразу нескольких служб одновременно.
3. Распределять нагрузку на разные отделы равномерно.
4. Учитывать связь между системами филиалов.
5. Брать личную ответственность за локальные решения сотрудников.
6. Учитывать компетенцию специалистов, стоимость их работы.
7. Организовать несколько линий поддержки, укомплектовать их нужными специалистами.
8. Создать систему числовых метрик с точным указанием времени на решение определенных типов инцидентов.
9. Расширять количество персонала в зависимости от роста компании, проводить модернизацию рабочих инструментов и переподготовку сотрудников.

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

Как внедрить систему управления инцидентами?

Внедрить систему управления инцидентами можно двумя путями: организовав специальный отдел с наемными сотрудниками; воспользоваться компьютеризированными решениями поставщиков Service Desk / ITSM. Второй вариант решения обладает большим количеством преимуществ:

1. Постоянный доступ к информации об инциденте для всего персонала техподдержки.
2. Сокращение времени обслуживания.
3. Точная процедура отслеживания, эскалации и отработки инцидента.
4. Доступность и актуальность управленческой информации.
5. Устранение ее потерь, ошибок и дублирования.
6. Оптимальное использование квалификации персонала на всех линиях.
7. Налаживание связи структурных подразделений компании.
8. Составление отчетов и чек-листов.

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

Инциденты на производстве

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

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

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

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

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

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

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

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

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

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

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

Допустимо (и рекомендуется) совмещение функций 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.

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

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

Рассмотрим на примере

Чтобы разграничить эти два понятия, которые часто вызывают путаницу, можно рассмотреть их разницу на конкретном примере:

1. Что такое инцидент – вы включаете какое-либо устройство, а оно не работает. Вы проверяете все возможные элементы, но устройство не подает признаков жизни. Чтобы решить свою задачу, можно воспользоваться другим аналогичным устройством – так инцидент будет исчерпан.
2. Что такое проблема – из раза в раз вы не можете воспользоваться сломанным устройством и вам приходится искать пути решения проблемы, чтобы достичь результата. Решить проблему — значит, отремонтировать устройство, причём так, чтобы инциденты, то есть, поломки, больше не возникали.

Соответственно, преимущества решения проблемы очевидны:

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

Регулирующая и расследующая инциденты и аварии комиссия

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

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

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

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

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

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

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

style="">

• Сегмент сети, где находится взломанный ПК;
• Ценность данных, хранимых на взломанном компьютере;
• Тип и количество других инцидентов, затронувших тот же ПК;
• Достоверность индикатора заражения, соответствующего данному инциденту.

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

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

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

1. Соберите команду специалистов. Скоординируйте команду экспертов по безопасности, которые оценят серьезность инцидента, свяжутся с руководством и предпримут меры по смягчению последствий.
2. Выявите и оцените инцидент. Определите, что было украдено. Найдите сеть, через которую была нанесена атака и изолируйте ее. Так вы предотвратите распространение инцидента и его последствий. При этом сохраните все данные из зараженной сети для последующего анализа.
3. Восстановите сети. Если системы или сети настолько сильно повреждены, что с ними невозможно работать, то запустите полное аварийное восстановление.
4. Сообщите об атаке тем лицам, чьи данные были украдены. Если данные клиента или компании были украдены во время инцидента информационной безопасности, то уведомите пострадавших о нарушении.
5. Найдите виновного в инциденте, если возможно. Если злонамеренное действие было совершено сотрудником компании, уведомите об этом отдел кадров, чтобы можно было принять соответствующие меры.
6. Разберите инцидент безопасности на конкретные шаги. Как только инцидент безопасности будет устранен, посмотрите, что произошло, как это произошло и какие шаги можно предпринять, чтобы избежать подобных инцидентов в будущем.

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

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

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

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

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

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

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

Определение первого ответа на обнаружение инцидента

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

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

Похожие записи:

• Потеряли паспорт? Придётся восстанавливать
• Как происходит покупка вторичной квартиры в ипотеку
• Электронный больничный лист в 2023 году: инструкция для работодателя