12.11.2012

”правление инцидентами в »Ѕ: формальность или необходимость?

image

¬ нашей недавней серии статей про SIEM системы упоминалась, среди прочего, встроенна€ в некоторые продукты возможность управлени€ инцидентами (incident management). —егодн€ мы расскажем о некоторых аспектах этого процесса.

јвтор: ќлес€ Ўелестова, исследовательский центр Positive Research.

—отрудники служб »Ѕ и технические специалисты занимаютс€ решением самых разных задач. ѕри этом не всегда их инициатором €вл€етс€ руководство: в случае обнаружени€ симптомов угрозы, инцидента безопасности или ошибки конфигурации сотрудник вполне может и сам про€вить инициативу. ≈сли задачу ставит руководитель, то он, как правило, устанавливает сроки и контролирует ход решени€ задачи. ќднако далеко не во всех компани€х используетс€ специализированное ѕќ дл€ контрол€ и учета задач наподобие Microsoft Project. «ачастую примен€ютс€ «самописные» или адаптированные системы Service Desk. «адачи оформл€ютс€ в подобном ѕќ, и далеко не всегда это делаетс€ должным образом.

≈сли сотрудник самосто€тельно находит инцидент и сам же занимаетс€ его решением, то позици€ руководител€ здесь: «лишь бы все работало». –едко бывает, что процесс решени€ задач регламентирован, задокументирован, что выстроена схема согласовани€. » чем больше компани€, тем ситуаци€ хуже.

¬от лишь некоторые недостатки этих двух схем:

  • ¬несение несогласованных изменений. »нформаци€ о причине тех или иных изменений в системе нигде не хранитс€, в лучшем случае все согласовани€ происход€т устно. Ќеудивительно, что спуст€ какое-то врем€ мало кто в состо€нии вспомнить последовательность произведенных действий.
  • ќтсутствие контрол€ изменений. ¬ результате неизвестно, кто и когда изменил тот или иной параметр.
  • Ќе производитс€ оценка изменений. Ќикто не задаетс€ вопросом о том, как внесенные изменени€ повли€ли на инфраструктуру и стабильность информационных систем, не породили ли они других инцидентов и проблем безопасности.
  • Ќекорректно определ€ютс€ приоритеты. ≈сли сотрудник определ€ет пор€док решени€ задач самосто€тельно, то более важную задачу он может оставить «на потом» и сфокусироватьс€ на менее сложной. ƒл€ бизнеса такой подход неприемлем.
  • ќтсутствует прозрачность работы подразделени€. –уководству необходимо знать, какие задачи, дл€ чего, почему, кто и когда решает.
  • ќтсутствуют метрики. Ќе ведетс€ учет количества задач и сроков их исполнени€ дл€ каждого сотрудника.  ак следствие, возникают проблемы при обосновании штатного расписани€ и трудности при организации service level agreement (SLA).
  • ѕроблемы не вы€вл€ютс€. Ќе €сны причины роста числа инцидентов, трудно планировать меры предупреждени€ проблем.
  • «атруднени€ при оптимизации процессов. –ешение простых задач может занимать достаточно много времени. –азобратьс€, что стало тому причиной (загруженность сотрудника, долгий процесс согласовани€), очень трудно.
  • ќтсутствие контрол€. «ачастую сотрудник приступает к решению задачи не сразу после ее постановки, а лишь спуст€ значительное врем€.
  • Ѕезответственное отношение к процессу документировани€. ƒоказательства по инцидентам хран€тс€ в разных местах, и соответственно, узнать подробности о них (на основании чего возникали, как решались, вносились ли в процессе работы над ними изменени€) — не представл€етс€ возможным.  роме того, при подобной схеме можно вообще не узнать, что инцидент имел место. Ќевозможно вручную сравнить несколько состо€ний системы или конфигураций, чтобы вы€снить, какие были внесены изменени€.
  • ќтсутствие базы знаний. ѕри посто€нном решении типовых инцидентов сотрудник набивает руку и справл€етс€ с ними все легче. ќднако иногда возникают совсем не типовые проблемы, после решени€ которых даже опытный профессионал зачастую не вспомнит, какие строки в конфигурационном файле были изменены.  роме того, в любой компании врем€ от времени по€вл€ютс€ новые сотрудники, у которых поначалу и типовые инциденты могут вызывать сложности.
  • ѕроблемы взаимодействи€ между подразделени€ми. Ќесмотр€ на то что далеко не всегда дл€ решени€ инцидентов информационной безопасности требуетс€ помощь сотрудников отдела »“, налаженное взаимодействие между »Ѕ- и »“-департаментами жизненно необходимо. ≈сли общего дл€ всех процесса работы с инцидентами нет, то врем€ их решени€ увеличиваетс€ в разы. ƒаже наличие плана реагировани€ на инциденты в данной ситуации не сильно поможет, ведь одно только назначение ответственных сотрудников может зан€ть массу времени. ѕри подобной организации управлени€ инцидентами уменьшить временные затраты можно с помощью автоматических шаблонов.

¬се вышеперечисленное существенно вли€ет на оперативность решени€ задач и инцидентов (mean time to remediate, MTTR), на риски их возникновени€, простои и даже на размер штата подразделени€. ѕри этом невозможно утверждать (и подтвердить это), что в информационных системах компании нет у€звимостей, а те, что есть, своевременно обнаруживаютс€ и устран€ютс€.

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

  • никто не любит бумажную волокиту;
  • ручное документирование задач тратит врем€ сотрудника, которое могло бы быть использовано более эффективно.

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

«ачем это нужно?

ƒл€ чего нужна автоматизаци€ и переход к управлению инцидентами?  онечно, вы можете вы€вл€ть инциденты самосто€тельно и по электронной почте или по телефону назначать задачи по их устранению конкретным сотрудникам. ќднако всегда есть риск не дозвонитьс€, а письмо может попасть в спам. —пецифика »Ѕ заключаетс€ в том, что за это врем€ вирус на рабочей станции способен перерасти в насто€щую эпидемию, злоумышленник может провести эксплуатацию у€звимости, похитить конфиденциальные данные, нанести ущерб системе. ¬о избежание подобных последствий как раз и требуетс€ снижение показател€ MTTR.

ѕредставим себе ситуацию, когда инцидент не был своевременно вы€влен. ѕричин тому может быть множество: сотрудник заболел, отвлекс€, был загружен другими задачами, банально забыл или ему не хватило опыта. ≈сли процесс управлени€ инцидентами в компании отлажен хорошо, то ситуаци€ «забыл зарегистрировать инцидент» не произойдет в принципе. »нцидент будет зарегистрирован, зафиксирован, а к решению проблемы будет привлечен компетентный сотрудник. »менно дл€ автоматического вы€влени€ и регистрации инцидентов нужны механизмы коррел€ции SIEM-систем.  стати сказать, подобные системы обычно оснащены и встроенным функционалом управлени€ инцидентами.

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

ѕон€тие и организаци€ процесса управлени€ инцидентами дл€ I“-департаментов наиболее полно и четко описаны в ITIL и ITSM. ƒл€ »Ѕ же, по большому счету, опиратьс€ можно только на стандарт NIST 800-61, хот€ на практике можно успешно пользоватьс€ и ITIL.
ѕроцесс управлени€ инцидентами включает в себ€ следующие пон€ти€:

  • —обственно, инцидент (INC, Incident) — событие (или потенциальна€ возможность событи€), которое ведет к нарушению требований информационной безопасности, конфиденциальности, целостности или доступности информационных ресурсов, либо любое нестандартное событие, которое вызывает или может вызвать снижение качества работы или прерывание доступности сервиса.
  • «апрос на изменение (RFC, Request for Change) используетс€ дл€ согласовани€ задач на изменение конфигураций, политик и т. п. и организации процесса изменени€ по задачам в рамках RFC. Ёто может быть изменение какого то конфигурационного файла, IP-адреса сервера, смена всего адресного пространства IP, установка каких-либо средств защиты или сетевых устройств.
  • ѕроблема (Problem) — может возникать при многочисленном повторении однотипного инцидента. явл€етс€ следствием прин€ти€ неэффективных или неверных мер по устранению причин возникновени€ инцидентов (или неприн€ти€ мер вообще), либо внесени€ изменений, повлекших нарушение работы информационных систем и возникновению рисков. Ќапример, пользователь каждый день обращаетс€ и сообщает, что у него заблокирована учетна€ запись. ‘акт обращени€ – это инцидент. Ќо пользователь обращаетс€ каждый день, и ежедневно на решение инцидента трат€тс€ ресурсы. ƒл€ этого заводитс€ проблема, призванна€ разобратьс€ с причинами блокировки и устранить возникающие однотипные инциденты.

ѕроцесс управлени€ инцидентами может и должен включать в себ€ часть процессов управлени€ изменени€ми и управлени€ проблемами (change management и problem management).

„тобы определить пон€ти€, используемые в процессе управлени€ инцидентами, рассмотрим простые жизненные примеры.

  • «адача вида «Ќеобходимо обновить версию программного обеспечени€» — это запрос на изменение (RFC).
  • «адача вида «”становите патч. ”€звимость не найдена, но возможна» — это RFC.
  • Ђ—канер нашел у€звимость. ”становите патч!ї Ч это инцидент. ¬ зависимости от прин€тых в условии правил RFC может быть даже открыто из инцидента на согласование изменений и установку патча.
  • ЂЌастроить серверї Ч это RFC или задача в рамках существующего RFC Ђ”становить серверї;
  • Ђнеобходимо перенастроить прокси (squid)ї Ч это RFC. ¬ случае, если эти перенастройки необходимы из-за возникающих инцидентов, задача может выполн€тьс€ в рамках этих инцидентов или же представл€ть собой запрос на изменение (RFC, св€занный с инцидентом).
  • ¬ирус или обнаруженна€ атака – это инцидент:
  • ≈сли в одном и том же сегменте инфраструктуры (напр. на сервере) часто обнаруживаютс€ вирусы – это проблема.

ƒл€ правильной организации управлени€ инцидентами необходимо обеспечить по крайней мере три линии поддержки.

  • ѕерва€ лини€ осуществл€ет прием, регистрацию, перенаправление, уточнение и обработку запросов и инцидентов.  роме того, специалисты первой линии могут заниматьс€ решением простых инцидентов. Ёти об€занности можно возложить на отдел HelpDesk или на выделенных сотрудников SOC, которые будут использовать базу знаний дл€ помощи в решении несложных инцидентов.
  • ¬тора€ лини€ решает инциденты, не требующие привлечени€ экспертов.  ак правило, этим занимаютс€ региональные отделы »Ѕ или, в случае недостатка »Ѕ-специалистов, — сотрудники I“-департамента.
  • “реть€ лини€ — эксперты. –ешают самые сложные задачи, которые выход€т за рамки компетенции специалистов первой и второй линий, а также занимаютс€ работой с критически важными дл€ бизнеса инцидентами, которые требуют оперативной реакции.

—в€зь пользователь — эксперт Ч это не лучша€ практика: тратить врем€ высокооплачиваемого специалиста на решение простых задач невыгодно.   сожалению, на практике в некоторых случа€х это необходимо, к примеру, когда у двух первых двух линий поддержки не хватает компетенции или необходимо как можно быстрее разобратьс€ с причинами инцидентами, позвонив пользователю напр€мую, а не играть в Ђиспорченный телефонї.

¬ведем еще один термин. «аголовок Ч это некое подобие задачи, котора€ представл€ет инцидент, запрос на изменение или проблему. ƒл€ того чтобы описать шаблонную автоматическую регистрацию инцидента и его назначение в качестве задачи сотруднику, каждый заголовок (инцидент, RFC, проблема) должен включать:

  • тип заголовка (инцидент, запрос на изменение, проблема);
  • тип подразделени€ (»“, »Ѕ);
  • метод регистрации в системе (коррел€ци€, пользователь, внешн€€ система);
  • наименование заголовка; тут могут использоватьс€ шаблоны вида %Ќесанкционированный доступ%, формируемые различными системами (в том числе SIEM);
  • объект (офис), в котором зарегистрирован инцидент (иногда нужно знать, где именно произошел инцидент, чтобы проще было пон€ть, кому назначить задачу по его устранению);
  • класс заголовка (например, %јнтивирус%; даетс€ по классам событий);
  • приоритет (информирует о степени критичности инцидента).

ѕрисвоение приоритета позвол€ет в первую очередь уделить больше внимани€ решению действительно значимых инцидентов. ¬ простейшем случае важность той или иной задачи определ€етс€ с помощью таблицы:

ќднако в случае наличи€ в инфраструктуре компании систем риск-менеджмента (GRC) или SIEM-систем с возможностью указывать значени€ ценности актива, все немного сложнее. ¬ общем случае кажда€ задача (заголовок) должна назначатьс€ конкретному сотруднику или определенной группе специалистов. ”ведомление о назначении должно подтверждатьс€ по электронной почте. ѕеречислим рекомендуемые статусы заголовков дл€ отслеживани€ процесса решени€ задач.

  • Ќазначен. «адача назначена определенному пользователю, он проинформирован об этом, но еще не начал работать над ней.
  • ¬ работе. —отрудник ознакомилс€ с задачей и приступил к выполнению.
  • ќтложен. –ешение отложено по какой-то причине (указываетс€ отдельно).
  • –ешен. ќтветственный сотрудник выполнил все необходимые работы по решению задачи.
  • «акрыт. –ешение подтверждено руководителем или задача закрыта по истечении определенного времени. ƒанный статус необходим дл€ повторного открыти€ заголовка в том случае, если он не был решен («отрицательное решение»).   примеру, если не удалось устранить у€звимость или меры по ее устранению по какой-либо причине не были прин€ты.

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

«а соблюдением сроков выполнени€ своих задач об€заны следить все самосто€тельно. ƒл€ того чтобы облегчить сотрудникам эту задачу, существуют автоматические уведомлени€ о просрочке, рассылаемые по электронной почте или в виде новых задач в рамках заголовков. «а соблюдением сроков выполнени€ заголовков об€заны следить перва€ лини€ поддержки и руководители. ≈сли складываетс€ ситуаци€, когда сроки выполнени€ заголовка не будут соблюдены, перва€ лини€ об€зана вы€снить причины и предприн€ть действи€ к недопущению просрочки (напомнить, оповестить, вы€снить причины). –уководители должны получать оповещени€ о фактической просрочке заголовка (например, выше 25% отведенного на решение времени).

¬ процессе управлени€ инцидентами учитываетс€ и план реагировани€, однако в терминологии SIEM подобный план — это сценарии, которые лишь выполн€ют регистрацию инцидента и первоначальную постановку задач. —истемы Service Desk позвол€ют «вести» инцидент от момента открыти€ до подтверждени€ решени€, а также подключать шаблонные планы реагировани€ — заранее заготовленные инструкции, содержащие описание шагов по устранению типового инцидента.

‘ункциональные возможности управлени€ инцидентами, реализованные в различных SIEM, перечислены в таблице:

”правление инцидентами полезно и при составлении и обосновании плана минимизации рисков. — его помощью на основании возникающих инцидентов и критичности активов можно оценить слабые места в инфраструктуре.  роме того, управление инцидентами с автоматическим формированием задач — важно дл€ контрол€ конфигураций и соответстви€ стандартам. ѕри ручной обработке формируемых отчетов довольно трудно обнаружить несоответствие какого-либо актива политике безопасности компании. ѕоэтому возникает проблема оперативного устранени€ несоответствий. ѕри использовании управлени€ инцидентами задачи на устранение несоответстви€ будут расставлены автоматически (например, »“ специалисту, ответственному за этот актив, будет поставлена задача на установку обновлени€ или исправление конфигурации в соответствии с политикой), а экспертам будет предоставлена контрольна€ информационна€ задача (чтобы уведомить о найденном несоответствии и предоставить возможность контрол€ устранени€).

ѕри совместном использовании различных систем обработки данных возникает важна€ проблема разграничени€ доступа и обеспечени€ целостности доказательной базы.  ак правило, информацию об инциденте и этапах его решени€ должны иметь далеко не все сотрудники даже внутри одного отдела. „асто именно по этой причине служба »Ѕ не использует общую с I“-департаментом систему HelpDesk. ƒоказательства по инциденту также должны хранитьс€ централизовано, а не где-то на файловом сервере.

»так, все это может вам пригодитьс€ при организации процесса управлени€ инцидентами в »Ѕ. ¬ы сможет выстроить необходимые »Ѕ-процессы компании, упростить предоставление аудиторам статистики при проверках.  роме того, вам будет легче отчитатьс€ о проделанной работе перед руководством, проще управл€ть отделом »Ѕ и распредел€ть нагрузку. Ќу и, разумеетс€, самое главное: управление инцидентами позволит вам минимизировать риски безопасности.

или введите им€

CAPTCHA
13-11-2012 10:28:51
”правление инцидентами »Ѕ безусловно необходимо. “олько вот как совместить инциденты »Ѕ из SIEM с инцидентами »“ из ITSM(Service Desk) решаетс€ каждый раз индивидуально.  ажда€ система имеет свои преимущества и недостатки, и обе они пересекаютс€ функционалом и назначением. ¬ каждой среде свои особенности, поэтому не стоит так однозначно утверждать как строить обработку »Ѕ инцидентов.
0 |