Разработка и реализация процесса управления инцидентами иб в со­ответствии с лучшими практиками обеспечивает следующее

Временная информация хранится в системной памяти (в системном реестре, в кэше, в RAM) и теряется в случае перезагрузки или выключе­ния системы. Она бывает сетевая и системная.
Временная сетевая информация содержит сведения о текущей сете­вой конфигурации системы, вовлеченной в инцидент ИБ. Ее примеры: открытые соединения, очередь запросов на установление сетевых со­единений, открытые TCP/UDP-порты, маршрутная информация и кон­фигурация, стазу с сетевого интерфейса и конфигурация.
Временная системная информация показывает текущую конфигура­цию и текущее состоянии системы, вовлеченной в инцидент ИБ. При­меры такой информации: системный профиль (дает информацию о те­кущей конфигурации системы, вовлеченной в инцидент ИБ), текущая системная дата и время, история команд (включает в себя список недав­но запущенных команд как локальными, так и удаленными пользовате-
лями), время, прошедшее с момента последней перезагрузки системы (укажет на наличие/отсутствие временной информации, созданной во время инцидента ИБ), запущенные процессы (среди них могут находит­ся нетипичные, а, возможно и вредоносные), образы программ, которые были удалены с носителей, но все еще активны в ОЗУ, открытые файлы, информация в буфере обмена, подключенные пользователи, программ­ные модули, загруженные в области виртуальной памяти, зарезервиро­ванные для ядра ОС, DLL-файлы или разделяемые библиотеки (для изучения, насколько законно их использование) и т. п.
Первым шагом должен стать сбор именно такой информации, кото­рая поможет определить, как развивался инцидент ИБ и, возможно, на­рушителей. Она обязательно должна быть проанализирована для приня­тия решения о дальнейших действиях. Например, если собранной ин­формации достаточно для того, чтобы понять, что это не ложная тревога, и что в системе запущен какой-либо странный процесс, кото­рый может быть причиной инцидента ИБ, то можно инициировать про­цесс сбора постоянной информации.
Постоянная информация хранится на жестком диске системы или на другом типе носителей информации (например, подключенные USB- носители, flash-карты, CD-ROM, внешние жесткие диски) и не потеря­ется в случае перезагрузки или выключения системы. Примерами тако­го рода доказательств могут стать различные документы, сообщения электронной почты и удаленные файлы. Это также системные файлы, включая настройки параметров базовой системы ввода/вывода (BIOS), загрузочные записи, журналы регистрации событий и системные жур­налы, системный реестр; временные файлы, включая *Лтр-файлы и спул-файлы; следы веб-активности, источниками которых могут быть закладки, cookies, журнал посещенных URL, временные интернет- файл ы (англ. Temporary Internet Files), данные реестра; файлы, включая удаленные файлы, неиспользованное пространство, файлы подкачки, неразмеченную область, фрагментированные файлы, скрытые файлы.
Исследование постоянной информации часто не является очень слож­ным процессом - большая часть пользователей умеет искать файлы, смот­реть, какие сайты в Интернете были посещены, а также выявлять наличие вредоносных программ. Но нахождение скрытой постоянной информации и умение коррелировать с первого взгляда не имеющие ничего общего со­бытия, записи, файлы и т. п. требует определенных навыков и знаний.
Важно помнить, что любое исследование системы, вовлеченной в инцидент ИБ, может привести к изменению доказательств и сделает этот процесс неэффективным. В случае сбора временной информации может измениться, например, время последнего доступа к файлам и да­же произойти перезагрузка компьютера и, как следствие, потеря важных данных. Любое средство для сбора данных, запущенное на уровне поль­зователя или ядра ОС, естественным образом изменяет состояние ис­следуемой системы. Запуская его в работающей системе, создается как минимум один процесс, который может быть записан в область, где до этого, возможно, хранились данные, имеющие доказательное значение. При создании нового процесса менеджер памяти ОС резервирует для него область памяти. При этом данные, которые находились в этот мо­мент в свободной области памяти или в области подкачки файловой системы, могут быть в дальнейшем перезаписаны данными нового про­цесса. Поэтому предотвращение внесения изменений в исследуемую систему при сборе доказательств - первая из задач, которая может быть достигнута с помощью применения различных техник и соответствую­щих инструментальных средств. Все подобные виды влияния, оказы­ваемые инструментами сбора доказательств на исследуемую систему, должны быть выявлены и зафиксированы на этапе тестирования этих инструментов и создания набора инструментальных средств сбора дока­зательств инцидентов ИБ [22].
Для своевременного сбора доказательств инцидента ИБ еще до того, как он произошел, в организации подбираются соответствующие инст­рументальные средства. Методика составления необходимого набора таких средств включает в себя следующие процедуры, позволяющие быть уверенными в целостности и надежности каждого отдельного ис­пользуемого инструмента, команды и приложения [7, 21]:

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

6. 
   Передача информации
   

После подтверждения ГРИИБ реальности инцидента ИБ часто воз­никает необходимость проинформировать об этом конкретных лиц как внутри организации (находящихся вне обычных линий связи между ГРИИБ и руководством), так и за ее пределами, включая СМИ [3-5]. Для этого требуется, например, подтверждение реальности и подкон­трольности инцидента ИБ, его определения как объекта антикризисной деятельности, закрытия и завершения анализа инцидента, а также фор­мирование вывода о нем.
Для оказания содействия такой деятельности заранее готовится не­кий шаблон передаваемой информации, который, в случае необходимо­сти, быстро адаптируется к обстоятельствам возникновения конкретно­го инцидента ИБ, и ее предоставления прессе и/или другим СМИ. Ин­формация, подлежащая распространению среди общественности, анали­зируется соответствующими лицами, координаторами по связям с об­щественностью и персоналом службы ИБ. Если прессе предоставляется неполная информация по инциденту ИБ, то это делается в соответствии с политикой распространения информации, принятой в организации.

6. 
   Расширение области принятия решений
   

При некоторых обстоятельствах решение по инциденту ИБ прини­мается совместно с высшим руководством, другой группой внутри ор­ганизации или лицом/группой из сторонней организации. Такими об­стоятельствами являются случаи принятия решений относительно ре­комендуемых действий, относящихся к инциденту ИБ, или дальнейшей оценки с целью определения требуемых действий [3-5]. Тогда после или даже в ходе (если проблема проявилась на ранней стадии ее обна­ружения) процессов оценки требуется расширить область принятия ре­шений. В документации СУИИБ описываются соответствующие дейст­вия тех, кому когда-либо придется принимать решение о расширении области принятия решений, то есть ГОЭ и членов ГРИИБ.

6. 
   Регистрация деятельности и контроль за внесением
   ИЗМЕНЕНИЙ
   

В стандартах [3-5] особо отмечено, что все, кто причастен к опове­щению (информированию) и управлению инцидентами ИБ, регистри­руют все действия надлежащим образом на случай их дальнейшего ана­лиза. Информация об этих действиях вносится в форму отчета об инци­дентах ИБ и в БДСИИБ, непрерывно обновляемую в течение всего времени действия инцидента ИБ - начиная с первой формы отчета и до завершения анализа инцидента. Эта информация хранится по возмож­ности с применением средств защиты и обеспечением соответствующе­го режима резервирования. Кроме того, все изменения, вносимые в про­цессе отслеживания инцидента ИБ, обновления форм отчета и БДСИИБ, регистрируются в соответствии с установленной формой системы кон­троля за внесением изменений.

6. 
   Техническая поддержка реагирования
   НА ИНЦИДЕНТЫ ИБ
   

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

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

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

• 
  быстрому получению отчетов о событиях и инцидентах ИБ;
  
• 
  уведомлению ранее отобранного персонала (соответствующих сто­ронних лиц) подходящими для этого средствами (например, через электронную почту, факс, телефон и т. д.), то есть запрашивая под­держку надежной контактной БД (которая должна быть всегда лег­кодоступной и должна включать бумажные и другие копии) и сред­ство передачи информации защищенным способом (при необходи­мости);
  
• 
  соблюдению предосторожностей, соответствующих оцененным рис­кам ИБ, избежанию прослушивания и сохранения доступности элек­тронной связи, реализуемой через Интернет или иным образом, во время атаки на систему, сервис и/или сеть;
  
• 
  процессу сбора всех данных о системе, сервисе и/или сети и всех об­рабатываемых данных;
  
• 
  использованию контроля целостности, если это соответствует оце­ненным рискам ИБ, для содействия в определении наличия измене­ний и того, какие части системы, сервиса и/или сети и данные под­верглись изменениям;
  
• 
  упрощению архивирования и защиты собранной информации (на­пример, применяя электронную цифровую подпись (ЭЦП) в записях в журнале регистрации или другие свидетельства при хранении в ав­тономном режиме на носителях, предназначенных только для чтения на устройствах CD или DVD ROM);
  
• 
  подготовке распечаток (например, журналов регистрации), демонст­рирующих процесс развития инцидента ИБ и его разрешение и обес­печивающих сохранность информации;
  
• 
  восстановлению штатного режима работы системы, сервиса и/или сети с помощью оптимальных процедур резервирования, четких и надежных резервных копий, тестирования резервных копий, контро­ля вредоносных программ, исходных носителей информации с сис­темным и прикладным ПО; надежных и обновленных исправлений («патчей») для систем и приложений, согласованных с соответст­вующим планом ОНБ.
  

АтС в результате инцидента ИБ могут функционировать неверно. Поэтому работа технического средства (ПО или АО), необходимого для реагирования на инцидент ИБ, не должна зависеть от используемых в организации систем, сервисов и/или сетей. По возможности, такие сред­ства должны быть полностью автономными.
Все технические средства тщательно отбираются, правильно вне­дряются и регулярно тестируются (включая тестирование полученных резервных копий).
Подразумеваемые технические средства не включают в себя те, ко­торые используются непосредственно для обнаружения инцидентов ИБ и автоматического оповещения соответствующих лиц.
2.8. Документация системы управления
инцидентами ИБ
В стандартах [3-5, 7] определяются важные требования к докумен­тации СУИИБ, включая ее основные составные элементы:

• 
  Основанная на фактическом или предполагаемом ущербе для биз- нес-операций организации шкала серьезности для классификации инцидентов ИБ, состоящая, например, из двух значений: значитель­ная и незначительная.
  
• 
  Формы докладов (по возможности в электронной форме) о событиях и инцидентах ИБ, соответствующие документированные процедуры и действия, связанные со ссылками на нормативные процедуры ис­пользования данных и системы, сервисов и/или сетевого резервиро­вания, планами ОНБ. Форма докладов о событиях ИБ заполняется лицом, принимающим сообщение, то есть не членом группы управ­ления инцидентами ИБ. Эти формы используются персоналом управления инцидентами ИБ для пополнения первоначальной ин­формации о событии ИБ, текущего ведения записи оценок инциден­та и прочего до полного разрешения инцидента. На каждой стадии в БДСИИБ включаются обновления. Запись в БД, содержащая запол­ненную форму или сведения о событиях/инцидентах ИБ, далее ис­пользуется при разрешении инцидента.
  
• 
  Операционные процедуры для ГРИИБ с документированными обя­занностями и распределением функций между назначенными ответ­ственными лицами для ведения различных видов деятельности, на­пример:
  

• 
  отключение АтС при определенных обстоятельствах по согласо­ванию с соответствующим руководством ИТ и/или бизнеса и в соответствии с предварительным соглашением;
  
• 
  оставление АтС в работающем состоянии и подключенной к сети;
  
• 
  ведение мониторинга потока данных, выходящих, входящих или находящихся в АтС данных;
  
• 
  активация нормальных дублирующих процедур и действий по пла­нированию ОНБ согласно ПолИБ системы, сервиса и/или сети;
  
• 
  ведение мониторинга и организация защищенного хранения сви­детельств в электронном виде на случай их востребования для судебного разбирательства или внутреннего дисциплинарного расследования внутри организации;
  
• 
  передача подробностей об инциденте ИБ сотрудникам своей ор­ганизации и сторонним лицам или организациям.
  

• 
  Тестирование функционирования СУИИБ, ее процессов и процедур.
  
• 
  Обновление политик управления и анализа рисков ИБ, корпоративной и частных ПолИБ для систем, сервисов и/или сетей для включения ссы­лок на управление инцидентами ИБ и обеспечения регулярного пере­смотра этих политик в контексте выходных данных СУИИБ.
  
• 
  Создание ГРИИБ с соответствующей программой обучения ее пер­сонала.
  
• 
  Технические и другие средства поддержки СУИИБ (и деятельность ГРИИБ).
  
• 
  Проектирование и разработка ПО осведомленности об управлении инцидентами ИБ, ознакомление с этой программой всего персонала организации (и повторное проведение ознакомления в дальнейшем в случае кадровых изменений).
  

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

1. 
   Политика управления инцидентами ИБ
   

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

• 
  Значимость управления инцидентами ИБ для организации, а также обязательства высшего руководства относительно поддержки управ­ления и его системы.
  
• 
  Общее представление об обнаружении событий ИБ, оповещении о них, сборе соответствующей информации и путях ее использования для определения инцидентов ИБ. Сюда включается перечень воз­можных событий ИБ, а также информация о том, как сообщать о них, что сообщать, где и кому, а также как обращаться с совершенно новыми типами событий ИБ.
  
• 
  Общее представление об оценке инцидентов ИБ, включая перечень ответственных лиц, необходимые для выполнения действия, уведом­ления об инцидентах ИБ и дальнейшие действия ответственных лиц.
  
• 
  Краткое изложение действий после подтверждения категории инци­дента ИБ, включая немедленное реагирование, правовую экспертизу, передачу информации соответствующему персоналу или сторонним организациям, проверку контролируемости инцидента ИБ, дальней­шее реагирование, объявление антикризисной ситуации, определе­ние критериев усиления реагирования на инцидент ИБ, установление ответственного за инцидент лица (виновного).
  
• 
  Ссылку на необходимость правильной регистрации всех видов дей­ствия для дальнейшего и непрерывного мониторинга с целью обес­печения защищенного хранения свидетельств в электронном виде на случай их востребования для судебного разбирательства или дисци­плинарного расследования внутри организации.
  
• 
  Действия, следующие за разрешением инцидента ИБ, включая извлече­ние уроков и улучшение процесса, следующего за инцидентами ИБ.
  
• 
  Подробности места хранения документации о системе, включая про­цедуры хранения.
  
• 
  Общее представление о деятельности ГРИИБ, включая:
  

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

• 
  Формулировку целей ГРИИБ применительно к основной деятельно­сти персонала. Для выполнения своих функций персонал должен участвовать в оценке инцидентов ИБ, реагировании на них и управ­лении ими, а также в их успешном разрешении. Для установления целей и назначения ГРИИБ требуется четкое и однозначное опреде­ление области ее действия (обычно в нее входят все системы, серви­сы и сети организации; в некоторых случаях для организации может потребоваться сужение этой области, тогда необходимо четко доку­ментировать то, что входит и что не входит в нее) и личность учре­дителя ГРИИБ (старшее должностное лицо (член правления), стар­ший руководитель), который санкционирует действия ГРИИБ и устанавливает уровни полномочий, переданные ГРИИБ. Осведом­ленность об этом поможет всему персоналу организации понять предпосылки создания и структуру ГРИИБ, что является крайне важной информацией для формирования доверия к ГРИИБ. Перед обнародованием таких деталей необходимо проверить законность этого действия (в некоторых обстоятельствах раскрытие полномочий группы персонала может послужить причиной предъявления ей пре­тензий по нарушению обстоятельств).
  
• 
  Общее представление о программе обеспечения осведомленности и обучения управлению инцидентами ИБ.
  
• 
  Перечень затронутых правовых и нормативных аспектов.
  

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

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

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

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

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

• 
  Обзор политики управления инцидентами ИБ.
  
• 
  Обзор СУИИБ в целом.
  
• 
  Детальные процессы и процедуры (по усмотрению организации все или некоторые из них могут быть изложены в дополнительных до­кументах), информация о соответствующих сервисных программах и шкалах, связанные со следующим:.
  

1. 
   Для этапа «Планирование и подготовка»:
   

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

2. 
   Для этапа «Использование» (при подтверждении инцидентов ИБ):
   

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

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

3. 
   Для этапа «Анализ» связанные:
   

• 
  С проведением, если потребуется, дальнейшей правовой экспертизы.
  
• 
  Идентификацией и документированием опыта, извлеченного из инцидентов ИБ.
  
• 
  Определением и анализом улучшений ИБ на основе полученного опыта.
  
• 
  Анализом эффективности процессов и процедур реагирования на инциденты ИБ, оценкой инцидентов ИБ и восстановлением после каждого из них, а также определением улучшений СУИИБ в це­лом (на основе полученного опыта).
  
• 
  Обновлением БДСИИБ.
  

4. 
   Для этапа «Улучшение» (уточнение на основе полученного опыта) связанные:
   

• С результатами анализа и управления рисками ИБ.

• 
  Программой управления инцидентам ИБ (например, процессами и процедурами, формами оповещения (информирования) и/или структурой организации).
  
• 
  Общей безопасностью внедрения новых и/или улучшенных за­щитных мер.
  
• 
  Градацией шкалы серьезности событий/инцидентов ИБ (напри­мер, значительный, незначительный, существенный, экстренный, неэкстренный) и соответствующими руководствами.
  
• 
  Руководством для решения о необходимости развития интенси­фикации каждого процесса, для кого они должна проводиться и в соответствии с какими процедурами. Персонал, оценивающий событие или инцидент ИБ, должен знать, основываясь на руково­дствах из документации программы управления инцидентами ИБ, когда при нормальных обстоятельствах необходимо переходить к интенсификации процесса и для кого. Кроме того, возможно воз­никновение непредвиденных обстоятельств, когда интенсифика­ция процесса может стать необходимой. Например, незначитель­ный инцидент ИБ может перейти в категорию существенных или в кризисную ситуацию в случае его неправильной обработки, или не обработанный в течение недели незначительный инцидент ИБ может стать значительным. В руководстве должны определяться типы событий и инцидентов ИБ, типы интенсификации процес­сов и лица, которые могут ее проводить.
  
• 
  Необходимыми процедуры для надлежащей регистрации всех действий в соответствующей форме и проведением анализа жур­нала регистрации назначенным персоналом.
  
• 
  Процедурами и механизмами поддержания режима контроля из­менений, который включает в себя прослеживание событий и ин­цидентов ИБ, обновление отчета об инцидентах ИБ и обновление самой программы.
  
• 
  Процедурами правовой экспертизы.
  
• 
  Процедурами и руководством по использованию СОВ, обеспечи­вающие соблюдение связанных с ними правовых и нормативных аспектов. Руководство должно включать в себя рассмотрение преимуществ и недостатков действий по наблюдению за зло­умышленником. Дополнительная информация по СОВ содержит­ся в ИСО/МЭК ТО 15947 «Структура системы обнаружения вторжений в сфере ИТ» и ИСО/МЭК ТО 18043 «Рекомендации по выбору, развертыванию и эксплуатации систем обнаружения вторжений».
  
• 
  Структурой организации программы.
  
• 
  Компетенцией и обязанностями ГРИИБ в целом и отдельных ее членов.
  
• 
  Важной информацией о контактах группы.
  

Перед началом применения программы управления инцидентами ИБ необходимо иметь в наличии документированные и проверенные про­цедуры. В документации по каждой процедуре указываются лица из ГОЭ и/или ГРИИБ, ответственные за использование и управление ею. Такие процедуры обычно включают в себя процедуры сбора и защи­щенного хранения электронных свидетельств, которые должны непре­рывно контролироваться на случай судебного разбирательства или дис­циплинарного расследования внутри организации. Сюда относятся и процедуры, задействованные в правовой экспертизе и антикризисной деятельности, если они не описаны где-либо еще, например в плане ОНБ. Документированные процедуры должны полностью соответство­вать документированной политике управления инцидентами ИБ и дру­гой документации, относящейся к управлению инцидентами ИБ.
Не все процедуры должны быть общеизвестны. Например, нежела­тельно, чтобы весь персонал организации знал подробности о работе ГРИИБ при взаимодействии с ней. Вполне достаточно того, что у ГРИИБ есть руководство, с которым можно связаться. Кроме этого часть полученной в результате анализа инцидентов ИБ информации может быть представлена для всеобщего доступа, например, в интране­те организации. Более того, иногда нежелательно раскрывать некоторые детали программы управления инцидентами ИБ, чтобы лицо, обладаю­щее конфиденциальной информацией внутри организации (инсайдер), не могло помешать процессу расследования. Например, если присваи­вающий денежные средства банковский служащий осведомлен о неко­торых деталях программы, то он может лучше скрывать свою деятель­ность от следствия или иным образом препятствовать обнаружению и расследованию инцидента ИБ и восстановлению после него.
Содержание рабочих процедур программы зависит от многих факто­ров, особенно связанных с характером уже известных возможных собы­тий и инцидентов ИБ и типами затрагиваемых при этом активов ИС и их средой. Так, некая рабочая процедура может быть связана с опреде­ленными типами инцидентов ИБ и активов (например, МЭ, БД, ОС, приложения) или со специфическими активами. Для каждой рабочей процедуры четко определяется, какие шаги необходимо предпринять и кому. Она обычно зависит от опыта и лучших практик, полученных как от внутренних, так и внешних источников (например, государственных или коммерческих КГБР или аналогичных групп, а также поставщиков и разработчиков).
Рабочие процедуры, которых нужно придерживаться, существуют для обработки уже известных типов событий и инцидентов ИБ. Они также необходимы, если тип обнаруженного инцидента ИБ или события еще неизвестен. В этом случае рассматриваются следующие аспекты: ■ процесс оповещения для обработки таких исключительных случаев;

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

Для выявления потенциальных дефектов и проблем, возникающих в процессе управления инцидентами ИБ, обязательно планируются регу­лярные проверки и тестирование процессов и процедур управления ин­цидентами ИБ. Любые изменения, появляющиеся в результате анализа реагирования на инциденты ИБ, перед их внедрением на практике под­вергаются строгой проверке и тестированию.
2.9. Группа реагирования на инциденты ИБ
В англоязычной литературе, посвященной инцидентам ИБ, можно встретить различные обозначения для ГРИИБ - специально созданной группы/команды, ответственной за получение, рассмотрение и реагиро­вание на сообщения о компьютерных инцидентах:

1. 
   CERT или CERT/CC (Computer Emergency Response Team/Coordi- nation Center) - группа оперативного реагирования на компьютерные инциденты/координационная группа, основной целью которой является оказание услуг по обработке компьютерных инцидентов для минимиза­ции ущерба и эффективного восстановления после инцидента, связан­ного с компьютерной безопасностью;
   
2. 
   CIRT (Computer Incident Response Team) - группа реагирования на компьютерные инциденты;
   
3. 
   CSIRT (Computer Security Incident Response Team) - группа реаги­рования на инциденты компьютерной безопасности [этот термин ис­пользуется преимущественно в Европе для обозначения, защищенного авторским правом термина CERT, официально зарегистрированного в США Координационной Группой CERT (CERT/CC)];
   
4. 
   IRT (Incident Response Team) - группа реагирования на инциденты;
   
5. 
   SERT (Security Emergency Response Team) - группа оперативного реагирования на инциденты безопасности.
   

Первая в мире CERT была создана в США в 1988 г. на базе Институ­та Программной Инженерии Университета Карнеги Меллона (Carnegie Mellon University) сразу после компьютерной эпидемии (известной как «червь Морриса»), парализовавшей тогдашний прототип Интернета. В настоящее время она называется Координационный Центр CERT и помогает организациям в планировании, формировании и развитии по­тенциала по управлению инцидентами ИБ. Любые организации могут воспользоваться техническими отчетами и продуктами, доступными на сайте http://www.cert.org/csirts. Также CERT/CC предоставляет образо­вательные курсы для менеджеров и технического персонала по созда­нию и управлению ГРИИБ, основам и расширенной обработке инциден­тов, обезвреживанию вредоносных программ. Для технического персо­нала и членов ГРИИБ, сетевых и системных администраторов с опытом обработки инцидентов, профессионалов в области управления инциден­тами созданы свои программы (CERT/CC Handler - С SIH).
В 1992 г. датский академический провайдер SURFnet создал первую CSIRT в Европе под названием SURFnet—CSIRT.
Теперь в разных странах действует большое количество групп CERT. Они расширили свои возможности от простых откликов на ин­циденты до предоставления разнообразных сервисов ИБ, включая пре­дупредительные (профилактические) сервисы, рекомендации по ОИБ, тренинги и управление СОИБ. В конце 90-х годов был принят термин CSIRT, который более точен, чем наравне с ним используемый в на­стоящее время CERT.
Существует признанный глобальный лидер в реагировании на инци­денты компьютерной безопасности - FIRST (Forum of Incident Response and Security Teams) - Форум команд реагирования на инциденты безо­пасности [www.first.org]. FIRST сводит друг с другом команды CSIRT из государственных, коммерческих и образовательных организаций. Целями FIRST являются поощрение сотрудничества и координации по предупреждению инцидентов, стимулирование быстрой реакции на ин­циденты и продвижение обмена информации среди членов сообщества в целом.
В Европе сотрудничество между CSIRT продвигает Оперативная группа TF-CSIRT. Ее основными целями являются организация форума для обмена опытом и знаниями, запуск пилотных сервисов для европей­ского сообщества CSIRT и помощь в создании новых CSIRT и обучении их персонала. Она также решает задачи продвижения общих стандартов и процедур реагирования на инциденты ИБ.
Сервис Trusted Introducer (TI) [www.trustedintroducer.nl] оказывает услуги в рамках Трансъевропейской ассоциации научно-исследова­тельских и образовательных сетей TERENA (Trans-European Research and Education Networking Association). Основной задачей TI является создание инфраструктуры доверия между ГРИИБ европейских стран, в которой TI играет роль доверенной третьей стороны и занимается во­просами регистрации, аккредитации и сертификации этих групп. TI предоставляет доступ к постоянно обновляемым специальным инфор­мационным материалам и базам данных, системе предупреждения, ор­ганизует мероприятия, предусмотренные только для членов TI, поддер­живает инфраструктуру шифрования и электронной подписи для обме­на информацией во время обработки инцидентов и т. д.
RU-CERT - российский центр реагирования на компьютерные инци­денты [www.cert.ru], основной задачей которого определено снижение уровня угроз ИБ для пользователей российского сегмента Интернета.
В этих целях RU-CERT оказывает содействие российским и зарубеж­ным юридическим и физическим лицам при выявлении, предупрежде­нии и пресечении противоправной деятельности, имеющей отношение к расположенным на территории РФ сетевым ресурсам. RU-CERT осуще­ствляет сбор, хранение и обработку статистических данных, связанных с распространением вредоносных программ и сетевых атак на террито­рии РФ. Для реализации поставленных задач RU-CERT взаимодейству­ет с ведущими российскими ИТ-компаниями, субъектами оперативно­розыскной деятельности, органами государственной власти и управле­ния РФ, зарубежными центрами реагирования на компьютерные инци­денты и другими организациями, осуществляющими свою деятельность в области компьютерной и информационной безопасности. RU-CERT входит в состав международных объединений CSIRT/CERT центров (FIRST, TI) и, официально в рамках данных объединений, выполняет функции контактной стороны в РФ. Действуя в рамках нормативной правовой базы РФ, RU-CERT не уполномочен заниматься решением во­просов, находящихся в ведении правоохранительных органов (ФСБ или МВД РФ).
Как уже отмечалось выше, целью создания ГРИИБ является обеспе­чение организации соответствующим персоналом для оценки, реагиро­вания на инциденты ИБ и извлечение уроков из них, а также необходи­мой координации, управления, обратной связи и процесса передачи информации. Члены ГРИИБ участвуют в снижении физического и фи­нансового ущерба, а также ущерба репутации для организации, связан­ного с инцидентами ИБ.
Дополнительно члены ГРИИБ могут оказывать консультационные услуги, осуществлять оценку уязвимостей, установку соответствующих обновлений, обнаружение вторжений, обучение и тренинги и т. п. [7].
В стандартах [3-5] отмечено, что состав и количество персонала, а так­же структура ГРИИБ должны соответствовать масштабу и структуре орга­низации. Она также зависит от доступности квалифицированных экспер­тов, нанимаемых на постоянной основе или для конкретной задачи.
Для типичной ГРИИБ обычно выделяют следующие роли внутри группы: