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


Таблица 2,1, Примерное распределение обязанностей членов ГРИИБ


Download 1.2 Mb.
bet17/43
Sana30.03.2023
Hajmi1.2 Mb.
#1309469
1   ...   13   14   15   16   17   18   19   20   ...   43
Bog'liq
текст лекции

Таблица 2,1, Примерное распределение обязанностей членов ГРИИБ

Действие

Роль

Коорди­натор

Посредник ИТ-отдела

Юрист

Специалист по связям

Руково­дство

Первоначальная оценка

О

К

-



-

Первоначальные меры

О

Р

д

д

д

Сбор свидетельств для суда

Р

К

О

-

-

Реализация временных исправлений

О

Р

д

д

к

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

к

К

к

р

О

Взаимодействие с пра­воохранительными ор­ганами

д

д

р

д

О

Реализация непрерыв­ных исправлений

О

р

д

д

д

Определение финан­совых последствий для предприятия

д

д

к

д

О

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


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

  • представителя организации по работе со СМИ;

  • метод взаимодействия подразделений организации с ГРИИБ.

Также устанавливаются связи между ГРИИБ и соответствующими сторонними лицами и организациями, к которым относятся сторонний вспомогательный персонал, работающий по контракту, например: КГБР, ГРИИБ сторонних организаций, правоприменяющие организа­ции, аварийные службы (например, пожарная бригада), соответствую­щие государственные организации, юридический персонал, официаль­ные лица по связям с общественностью и/или представителями СМИ, партнеры по бизнесу, потребители и общественность.
Основными источниками научно-методических разработок по тема­тике ГРИИБ являются CERT/CC, Институт SANS (SysAdmin, Audit, Network, Security) и агентство ENISA (European Network and Information Security Agency, Европейское агентство по сетевой и информационной безопасности).
На сайте SANS представлены статьи по тематике управления инци­дентами ИБ [www.sans.org/reading_room/whitepapers/incident]. В середи­не 1990-х гг. SANS подготовил документ «Computer Security Incident Handling. Step By Step», в версии 2.3.1 которого представлены шесть по­следовательных процессов обработки инцидентов (подготовка, иденти­фикация, локализация, устранение причин, восстановление, извлечение уроков) и описаны специальные действия для восьми типов инцидентов (вредоносный код, сканирование, DoS, незаконное использование, шпионаж, мистификация (hoax), неавторизованный доступ, интеллекту­альное право). Институт SANS также предлагает курс «SANS Security 504 Hacker Techniques, Exploits and Incident Handling».
Для поддержки создания новых ГРИИБ ENISA разработало «Поша­говое руководство по созданию CSIRT» [www.enisa.europa.eu/activities/ cert/support], доступное на 20 языках, включая русский. Данный доку­мент детально описывает процесс создания CSIRT с точки зрения управления бизнес-процессом и технических вопросов. Кроме этого ENISA разработало еще несколько документов: базовый набор хороших практик эксплуатации CSIRT; набор упражнений для тренинга CSIRT; потенциальные возможности для национальных/государственных
CSIRT; руководство по управлению инцидентами; обзор распростра­ненных инструментов обработки инцидентов.

    1. Обеспечение осведомленности и обучение
      в области инцидентов ИБ


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

  • основы работы СУИИБ, включая область ее действия и технологию работ по управлению инцидентов ИБ;

  • способы оповещения о событиях и инцидентах ИБ;

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

  • соглашения об уровне сервиса системы;

  • уведомления о результатах - на каких условиях будут информирова­ны источники;

  • любые ограничения, накладываемые соглашениями о неразглашении;

  • полномочия организации при управлении инцидентами ИБ и ис­пользуемые линии оповещения;

  • кто и как получает отчеты от СУИИБ.

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

    1. Сохранение доказательств инцидента ИБ

Если после инцидента ИБ, направленного против людей или органи­зации, возбуждается судебный иск (гражданский или уголовный), то со­бираются, сохраняются и представляются свидетельства (доказательст­ва), что осуществляется в соответствии с правилами, сформулирован­ными в соответствующей юрисдикции (юрисдикциях) [23, 24].
В зарубежной практике существует специальный термин «компью­терная экспертиза» (англ, computer forensics, аналоги - forensic comput­ing, investigative computing, digital forensics [www.netforensics.com, www.computerforensicsworld.com,www.opensourceforensics.org]). По оп­ределению ФБР это наука о получении, сохранении и представлении электронных данных, хранящихся на электронном носителе. В России данный термин используется в основном в судебной практике. Одной из первых публикаций в России по данному вопросу была статья С. А. Кат­кова, И. В. Собецкого и А. Л. Федорова [http://cyber-crimes.ru/library/ articles/expertise/], которые предложили называть эту экспертизу про- граммно-технической. Однако такое название было слишком узким и не отвечало всему кругу решаемых этой экспертизой задач. Появились и другие наименования: инженерно-компьютерная, судебно-техническая экспертиза информационно-вычислительных систем, судебно-киберне­тическая экспертиза, компьютерно-техническая экспертиза (КТЭ). Так КТЭ определяется как самостоятельный род судебных экспертиз, отно­сящийся к классу инженерно-технических экспертиз. Проводится в це­лях определения статуса объекта как компьютерного средства, выявле­ния и изучения его следовой картины в расследуемом преступлении, а также получения доступа к информации на носителях данных с после­дующим всесторонним её исследованием [25]. В России КТЭ рассмат­ривается именно как правовая экспертиза, связанная с извлечением, восстановлением, сохранением, анализом и представлением электрон­ных данных, хранящихся на электронном носителе, для их дальнейшего использования в качестве доказательств в суде.
В общих чертах, правила для доказательств охватывают следующее [23, 24]:

  1. допустимость доказательства: может ли оно использоваться в суде;

  2. весомость доказательства: его качество и полнота;

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

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

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

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

Когда событие ИБ обнаруживается впервые, может не быть очевид­ным, последует ли за событием судебное разбирательство. Поэтому су­ществует опасность того, что прежде, чем будет осознана серьезность инцидента ИБ, необходимые доказательства могут быть уничтожены преднамеренно или случайно. Желательно привлечь юриста или поли­цию в начале любого обдумываемого юридического действия и совето­ваться с ним по требуемым доказательствам.
Доказательство может находиться за пределами организации и/или ее юрисдикции. В таких случаях надо обеспечить право организации на сбор необходимой информации в качестве доказательства. Также при этом важно учитывать требования разных юрисдикций, если возникают такие ситуации.
Для того чтобы обеспечить возможность использования информации в качестве доказательства, управление ею должно осуществляться с применением защищенных систем на протяжении всего её жизненного цикла (который может длиться много лет). Если информация по какой- либо причине ставится под сомнение, то её доказательная сила может существенно уменьшиться, что потенциально может негативно отра­зиться на ходе судебного разбирательства [14].
При сборе доказательств инцидента ИБ нужно придерживаться сле­дующих важных принципов и последовательности действий [26].
Если по результатам расследования в дальнейшем планируется при­нятие мер юридического характера, то обеспечивается полное соответ­ствие собранных доказательств нормам местного законодательства.
В организации заранее разрабатывается план действий и детально описываются процедуры сбора информации для АтС. После выполне­ния каждого этапа исследований и в случае возникновения нештатных ситуаций в план и описание вносятся дополнительные мероприятия.
По возможности любой пользователь, имеющий средства или повод для взлома системы, сервиса и/или сети, должен лишиться дальнейшего доступа к АтС. Причина закрытия доступа не в том, чтобы установить возможного нападавшего (этим займется полиция), а скорее гарантиро­вать целостность доказательств.
Сами методы мониторинга и обнаружения инцидентов ИБ периоди­чески исследуются для обнаружения в них уязвимостей, иначе качество обеспечиваемых ими доказательств будет поставлено под сомнение, а фактическая информация, представленная суду, будет подозритель­ной, поскольку она, возможно, была подменена или в течение самого инцидента ИБ или при его обработке. Так файлы регистрации вызывают подозрения, если они поддаются трудной расшифровке и допускают неоднозначное толкование, а также если те, кто работают с ними повсе­дневно, не доверяют их содержанию полностью. Поэтому любая проце­дура сбора доказательств разрабатывается, помня об оправданной избы­точности и целостности. Удобство обработки доказательной информа­ции - не самое главное после того, как совершена атака; скорее наоборот - оно должно быть минимальным для самого нападающего, что затруднит стирание им следов. Проблема целостности решается по­средством четкого процедурного контроля, а избыточные средства ре­гистрации - это техническая проблема, решаемая расширением интег­рированной инфраструктуры осуществления мониторинга в системах, сервисах и/или сетях.
Перед выполнением каких-либо работ по поиску, сбору и фиксации доказательств инцидента ИБ группа экспертов знакомится с окружаю­щими АтС условиями и определяет, можно ли использовать для целей расследования работающую АтС или нет.
Физическое и логическое расположение АтС фиксируется (докумен­тируется), что позволяет прослеживать идущие к ней обращения.
Если АтС - устройство класса сервера, то удаление сервера из ин­транета часто практически неприемлемо. Тогда разумные действия та­ковы. Сохранить все полезные файлы регистрации. Записать все дейст­вия, произошедшие в системе, по крайней мере, за 24 часа до инцидента ИБ. Установить отклонение от обычных событий/действий и задоку­ментировать данную аномалию. Записать и исследовать возможные пу­ти перемещения нападающего. Использовались ли при этом какие-либо доверительные отношения? Каким путем был получен доступ? «Дове­рял» ли атакованный сервер любым другим системам, находящимся на пути в интранет или его сегмент? Если да, то список подлежащих ис­следованию компьютеров существенно возрастет.
Необходимо сделать фотографию АтС, особенно экранов мониторов и сообщений об ошибках, а также текущего времени. На фото также фиксируется конфигурация системы, включая память, платы расшире­ния, системы памяти большой емкости, сетевые платы и т. д.
Для проведения исследований АтС подготавливается защищенный от записи сменный носитель (загружаемый компакт-диск или другой сменный диск) с необходимыми программными средствами, размещен­ными непосредственно в корневом каталоге. До начала сбора данных на АтС запускается командный процессор, заранее скомпилированный и статически скомпонованный на другом компьютере и записанный на сменный носитель. Этот носитель монтируется в АтС.
В первую очередь с АтС собирается и фиксируется информация, вы­зывающая подозрение, а именно:

  • один из запущенных процессов использует нестандартные TCP/UDP-порты для приема данных или обращается непосредствен­но к интерфейсу raw socket;

  • процесс использует сетевое соединение с удаленным компьютером;

  • ранее запущенная программа впоследствии была уничтожена;

  • файл, открытый процессом, был стерт (например, журнал регистрации);

  • подозрительное имя процесса;

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

Для обнаруженных подозрительных процессов рекомендуется соз­дать их копии и скопировать содержимое только отдельных интересных участков из выделенной процессу области памяти.
После фиксации подверженных быстрому изменению данных по­средством выполнения команд на самой АтС собирается другая полез­ная (постоянная) информация о ней. Создаются копии файловой систе­мы АтС, отдельных разделов и всего жесткого диска целиком.
Для собираемых данных нужно использовать средства подсчета кон­трольных сумм. Важно убедиться, что данные не подвергались измене­нию в процессе сбора и записаны в неизменном виде на внешний носи­тель (исключение - невозможно вычислить контрольную сумму непо­средственно на АтС для содержимого ОЗУ, так как каждый раз создается новый процесс, загружаемый в память и изменяющий ее со­держимое). Один полезный прием - создать две контрольные суммы для всех файлов, содержащих данные с АтС. Первая сумма вычисляется не­медленно после создания файла, вторая - после анализа его содержимо­го. Сравнивая две величины, можно обнаружить, был ли файл изменен во время сбора доказательств.
После сбора доказательств АтС можно выключить. Но не следует использовать для этого команды shutdown или init - лучше выдернуть шнур питания из системного блока или устройства бесперебойного пи­тания (UPS). Из атакованного компьютера жесткий диск вынимается и помещается в специально оговоренное место, например в сейф (для его большей сохранности).
Необходимо избегать изменений любых данных на АтС (например, не запускать программы, изменяющие метаданные файлов и каталогов). Для их сохранения следует сделать копию исследуемого жесткого диска и убедиться, что она точно соответствует оригиналу (большинство ана­литических инструментов разрабатываются для работы с копиями дис­ков, чтобы не потерять ценную информацию, например, о времени дос­тупа). Идеальным решением данных проблем является устройство, ко­торое позволяло бы записать образ содержимого ОЗУ на внешний носитель без использования функций ОС АтС. Это может быть компью­тер, подключенный к АтС по сети.
Все результаты исследований АтС записываются на этот компьютер и хранятся автономно (off-line). Для передачи данных по сети можно использовать, например, конвейерное перенаправление данных. Если есть опасения, что в исследуемом сегменте интранета присутствует ус­тановленный злоумышленником сниффер, то передавать данные через сеть лучше в зашифрованном виде.
Нельзя доверять установленным на АтС программам, системным командам (например, netstat), библиотекам (например, libproc) и дан­ным, которые могли быть изменены злоумышленником в результате инцидента ИБ (применяя аналитический инструментарий к диску- копии, можно выявить потенциально испорченные данные и програм­мы). Поэтому для сбора информации в АтС рекомендуется использо­вать только программные средства, скомпилированные и скомпонован­ные не на АтС, а отдельно - на другом компьютере.
Все операции процесса исследований, включая копирование и ана­лиз, в обязательном порядке документируются. Хороший метод - соз­дать контрольные суммы пораженного диска и исследуемого образа. Следует также документировать программы, которые были использова­ны, и полученные с их помощью результаты. Если предстоит обращать­ся в суд, то рекомендуется выполнять все операции по копированию и анализу при двух свидетелях.
Анализ собранных данных включает предварительное изучение дан­ных и поиск в них доказательств инцидента ИБ по ключевым словам, а также углубленное исследование.
Анализу подлежат файлы протоколов работы, конфигурационные файлы, истории браузеров (включая cookies), сообщения электронной почты и прикрепленные файлы, инсталлированные приложения, графи­ческие файлы и прочее. Необходимо провести анализ ПО, поиск по ключевым словам, проверить дату и время инцидента ИБ. Важно про­вести анализ и на «низком» уровне: поиск удаленных файлов и обл ас­тей, потерянных кластеров, свободного места, а также анализ восста­новленных данных с разрушенных носителей (например, по остаточной намагниченности). При анализе предпочтителен подход «сверху вниз»: он начинается с наиболее общих вопросов (структура интранета, его сегментов и т. п.) и заканчивается поминутной детализацией физиче­ской конфигурации АО. Именно такой подход предназначен для того, чтобы нетехнический персонал мог безопасно пользоваться им, не боясь скомпрометировать законность доказательств.
Важно иметь систему хранения собранной в АтС информации с од­нократной записью - если данные будут записаны в ней, то их уже не изменить. Например, диски WORM (Write-Once-Read-Many - пишутся однократно, читаются многократно) исторически использовались имен­но для аналогичных сбору доказательств целей.
За данными должен осуществляться и физический контроль. Если возможно, взломанные дисковые системы удаляются и тщательно упа­ковываются. Упаковка опечатывается, что гарантирует сохранность до­казательств. Банковские сейфы являются хорошим средством хранения дисков на период расследования атаки. Это предотвратит обвинение, что в доказательства, возможно, кто-то вмешивался. Записи о доступе к сейфу могут в суде служить доказательством того, что к дискам никто не обращался после атаки. Также это предотвращает случайную потерю доказательств. Файлы регистрации и контрольные архивы переносятся на CD-ROM, что позволяет всем аналитикам иметь рабочую копию. Чем большее таких копий, тем тяжелее подменить записи в файлах регист­рации.
К файлам регистрации для их архивации можно применить про­граммы tar и gzip. Архив можно хранить на переносных носителях, а файлы регистрации можно извлекать с них для прочтения по мере не­обходимости.
Нельзя полагаться только на компьютерные файлы - журнал собы­тий, который ведется вручную, также важен, поскольку его труднее из­менить (легко установить факт внесения данных кем-то посторонним).
По окончании процесса исследования АтС все результаты должны быть представлены в удобном и понятном виде.
Конечно, данные рекомендации требуют дополнения и существен­ного уточнения, но это предмет для особого обсуждения, очень серьез­ный и объемный и не являющийся основным в рамках данного учебного пособия.

    1. Средства управления событиями ИБ

В течение только одного дня в крупных интранетах СЗИ могут реги­стрировать миллионы событий ИБ, имеющих разные происхождение и последствия. Объем трудозатрат, необходимый для выявления действи­тельно важных с точки зрения ИБ событий и для получения информа­ции об инцидентах ИБ, может оказаться чрезвычайно большим. Для решения задачи управления потоком событий ИБ, получаемых от СЗИ, и для автоматизации ряда процессов управления инцидентами ИБ ис­пользуются автоматизированные средства управления событиями ИБ - системы класса SIEM (от англ. Security Information and Event Mana­gement - управление информацией и событиями ИБ). Эти системы по­зволяют достичь следующих целей при управлении ИБ:

  • получить информацию о реальном состоянии уровня защищенности активов организации;

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

  • обнаружить расхождения и привести активы, бизнес-процессы в со­ответствии с внутренними ПолИБ, требованиями регуляторов и ау­диторов;

  • формализовать и осуществить эффективное принятие решений в облас­ти ИБ;

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

К функциям таких средств могут относиться следующие:

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

  • обработка собранной информации: фильтрация, агрегация, нормали­зация и корреляция;

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

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

Для выполнения данных функций архитектура типичного решения по управлению событиями ИБ состоит обычно из трех уровней: ядро, взаимодействующее с собирающими данные распределенными агента­ми (коллекторами) и занимающееся обработкой событий; БД, отвечаю­щих за хранение как накопленных необработанных данных, так и обра­ботанной информации о событиях ИБ; управляющий интерфейс с кон­солью центра управления.
Первым шагом анализа событий ИБ в типичных решениях является визуализация собранных данных - их отображение в виде таблиц, гра­фиков, индикаторов, расчет различных метрик, показателей эффектив­ности, включая количество событий и инцидентов ИБ по типам, кри­тичности, местам возникновения и т. п., статусы и текущие состояния инцидентов и т. д.
Моделирование инцидентов ИБ позволяет не просто учитывать факт его возникновения, но и установить причинно-следственные связи, вве­сти классификацию, автоматически выделять аномальные значения, вы­бросы, отклонения, оценить степень влияния различных факторов. Для решения задач моделирования применяются технологии Data Mining, позволяющие обнаруживать в больших объемах необработанных (сы­рых - от англ, raw) данных ранее неизвестные, необычные, практически полезные интерпретации знаний и соответственно самостоятельно под­страиваться под изменение среды. Наличие моделей инцидентов ИБ по­зволяет прогнозировать их развитие, оценивать вероятность возникно­вения той или иной проблемы как отдельно, так и в сочетании с други­ми событиями (так называемая корреляция событий).
Использование систем управления событиями ИБ позволяет достичь следующих результатов:

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

  • сократить затраты на подготовку персонала служб ИБ, которому нужно изучить только интерфейс такой системы, а не всех исполь­зуемых в интранете разнородных СЗИ;

  • снять необходимость в увеличении штата службы ИБ при увеличе­нии количества наблюдаемых СЗИ;

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

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

  • четкое определение ролей и ответственности всех специалистов за качественное и своевременное реагирование на инциденты ИБ;

  • предоставление процессом оперативной информации для монито­ринга эффективности принимаемых защитных мер;

  • предоставление процессом необходимой информации для коррект­ного проведения анализа рисков ИБ;

■ предотвращение инцидентов ИБ в будущем благодаря оперативному предоставлению сведений об имеющихся инцидентах ИБ, эффектив­ности реагирования на них, анализу динамики инцидентов ИБ и др.
Таким образом, можно сделать вывод, что внедрение разработанного процесса в рамках созданной в организации СУИИБ помогает решить проблемы, с которыми сталкиваются динамично развивающиеся компа­нии: увеличение ущерба от инцидентов ИБ, факт которых в большинст­ве случае даже не известен; а также выбор и принятие адекватных ре­шений, минимизирующих проблемы обеспечения ИБ.
Однако при внедрении процесса не стоит рассчитывать на мгновен­ный результат: процесс становится тем более эффективным, чем дольше он работает. За счет следования циклической модели PDCA и разбиения процесса управления инцидентами ИБ на планирование и подготовку, использование, анализ и улучшение происходит постоянное усовершен­ствование процесса. Отдельно должны быть рассмотрены подпроцессы обнаружения событий и инцидентов ИБ и оповещения о них, обработка событий и инцидентов ИБ, включая первую оценку и предварительное решение по событию ИБ и вторую оценку и подтверждение инцидента ИБ, а также реагирование на инциденты ИБ и его составляющие: не­медленное реагирование, контроль, последующее реагирование, анти­кризисные действия, правовая экспертиза, передача информации, рас­ширение области принятия решений, регистрация деятельности и кон­троль за внесением изменений и техническая поддержка реагирования на инциденты ИБ. Помимо этого происходит накопление данных об ин­цидентах ИБ, о способах реагирования на них, а также отрабатывается взаимодействие между специалистами, участвующими в работе процес­са. Помочь в этом также могут наиболее полная и качественно подго­товленная документация СУИИБ, включающая соответствующую поли­тику и программу, спланированная заранее и четко осуществляемая деятельность группы реагирования на инциденты ИБ, осведомленность и обученность в вопросах ОИБ и реагирования на инциденты ИБ персо­нала организации, а также использование современных инструменталь­ных средств управления событиями и инцидентами ИБ. Кроме этого значительное внимание должно уделяться в организации сохранению доказательств инцидента ИБ для его дальнейшей правовой экспертизы.
Вопросы для самоконтроля

  1. Какова роль процесса управления инцидентами ИБ в рамках СУИБ?

  2. Какова взаимосвязь между процессами управления рисками ИБ и управле­ния инцидентами ИБ?

  3. Каковы основные этапы работы процесса управления инцидентами ИБ? На каких этапах процесса может потребоваться участие владельцев бизнес- процессов и почему?

  4. Какие подпроцессы включает в себя деятельность по управлению инциден­тами ИБ?

  5. Каковы основные цели и задачи управления инцидентами ИБ?

  6. В чем состоят преимущества построения процесса управления инцидентами ИБ, соответствующего стандарту ГОСТ Р ИСО/МЭК 18044-2007, в случае если в организации разрабатывается СУИБ, в соответствии с требованиями ИСО/МЭК 27001?

  7. От чего зависит эффективность процесса управления инцидентами ИБ? В чем она выражается?

  8. Опишите основные этапы работы процесса управления инцидентами ИБ.

  9. Какой из подпроцессов управления инцидентами ИБ является наиболее объ­емным и трудоемким?

  10. Что понимают под системой управления инцидентами ИБ?

  11. Что необходимо принимать во внимание для создания оптимальной СУИИБ?

  12. В чем сходства и различия между понятиями «событие ИБ» и «инцидент ИБ»?

  13. Какие примеры событий ИБ и инцидентов ИБ можно привести?

  14. Каким образом может осуществляться выявление событий и инцидентов ИБ?

  15. Какую информацию об инциденте ИБ необходимо собирать для целей про­ведения анализа произошедших инцидентов ИБ?

  16. Какая информация об инциденте ИБ может быть получена в результате ана­лиза инцидента ИБ?

  17. Что должно включаться в отчет о событии ИБ?

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

  19. В чем состоит целесообразность ведения единой базы по произошедшим инцидентами ИБ и методам их разрешения?

  20. Какие преимущества дает введение подробной классификации инцидентов ИБ в рамках организации?

  21. Что подразумевается под процессом обработки сообщений о событиях ИБ?

  22. Если инцидент ИБ определен как реальный, то как проводится его дальней­шая оценка?

  23. Какие стратегии реагирования на инциденты ИБ можно выделить?

  24. В чем различия немедленного и последующего реагирования на инцидент ИБ?

  25. Каковы функции и полномочия группы реагирования на инциденты ИБ?

  26. Какими средствами реализуется техническая поддержка реагирования на инцидент ИБ?

  27. Что такое режим антикризисных действий?

  28. На основе анализа каких данных должно приниматься решение о необходи­мости расследования инцидента ИБ?

  29. Как осуществляется правовая экспертиза инцидента ИБ?

  30. Какие типы информации подлежат сбору для правовой экспертизы инциден­тов ИБ?

  31. Приведите примеры временной и постоянной информации, собираемой во время проведения правовой экспертизы инцидента ИБ. В чем состоят осо­бенности сбора временной информации?

  32. Почему еще до начала проведения расследования инцидента ИБ необходимо определить тип расследования: служебное расследование или расследование с привлечением правоохранительных органов?

  33. Каких важных принципов необходимо придерживаться при сборе доказа­тельств инцидента ИБ?

  34. Каким образом необходимо составлять набор инструментальных средств для сбора доказательств инцидентов ИБ и почему?

  35. Что относится к документации, используемой СУИИБ?

  36. Из каких разделов состоит политика управления инцидентами ИБ?

  37. Что должно быть отражено в программе управления инцидентами ИБ?

  38. Какими средствами осуществляется обеспечение осведомленности и обуче­ния в области инцидентов ИБ?

  39. С чем связано повышение эффективности работы процесса управления ин­цидентами ИБ с течением времени?

  40. Что может принести больше пользы: выстраивание процесса управления инцидента ИБ и его последующее непрерывное улучшение или автоматиза­ция операций реагирования на инциденты ИБ без выстраивания процесса? Почему?

  41. Каковы функции инструментальных средств управления событиями ИБ?

3. УПРАВЛЕНИЕ НЕПРЕРЫВНОСТЬЮ
БИЗНЕСА ОРГАНИЗАЦИИ

Все организации, независимо от их размера и вида деятельности, имеют собственные цели и задачи, которые обычно реализуются путем выполнения стратегических планов и достижения установленных крат­ко-, средне- и долгосрочных показателей этой деятельности. В совре­менных условиях сложной взаимозависимости различных подразделе­ний в рамках одной организации, ее зависимости от своих контрагентов, необходимости доступности систем обеспечения непрерывного функ­ционирования всех видов деятельности являются ключевыми задачами, стоящими перед руководством любой организации. Каждая из них так или иначе сталкивалась с проблемами нарушения или прерывания дея­тельности - вследствие сбоев энергетики, поставок или функциониро­вания информационных и телекоммуникационных систем, нарушений информационной безопасности, недоступности офиса, ухода ключевого персонала, преднамеренных действий или ошибок персонала, а также пожаров, наводнений, техногенных катастроф и т. д. В ряде высокотех­нологичных отраслей, таких как, например, телекоммуникации, непре­рывность деятельности является не просто потребностью бизнеса, но и требованием законодательства. Временное непредоставление услуг вне зависимости от причин, вызвавших этот перерыв, может привести к от­зыву лицензии и, следовательно, полному прекращению деятельности.
В 50-х гг. XX века организации столкнулись с проблемой аварийно­го восстановления деятельности и начали хранить дубликаты критич­ных данных в электронной и бумажной форме в удаленных помещениях [27]. В 1970-х гг. необходимость таких действий стала очевидной, при­меняться они стали довольно часто. Появились специализированные компании, предлагавшие услуги по хранению данных. Позже возник рынок резервных «горячих» вычислительных центров, ставший очень популярным решением среди финансовых организаций с централизо­ванной ИТ-инфраструктурой, которые очень сильно зависели от нали­чия и доступности данных. Аварийное восстановление окончательно сформировалось в 1980-х гг., когда только в США такие услуги предла­гали более ста компаний. В 1990-е гг. бурное развитие компьютерной индустрии привело к кардинальным переменам: появились персональ­ные компьютеры и соответственно изменились подходы к аварийному восстановлению ИС. Большинство организаций отказались от единого центрального мэйнфрейма, заменив его большим количеством распре­деленных по всей организации серверов и пользовательских мест. Де­централизация информационно-вычислительной инфраструктуры и, как следствие, большое количество разнообразных комбинаций неисправ­ностей АО и ПО существенно повысили сложность аварийного восста-
новления ИС. Во второй половине 1990-х на смену термину «аварийное восстановление» пришел термин «непрерывность бизнеса». Причиной этому послужил тот факт, что профессиональные составители планов аварийного восстановления старались уменьшить количество уязвимо­стей (начиная с человеческого фактора, недоступности компьютерных сетей, сетевых атак и заканчивая авариями телекоммуникаций), воз­никших благодаря децентрализованной архитектуре. Термин «аварий­ное восстановление» стал использоваться для описания традиционных информационно-технологических вопросов, связанных с резервным ко­пированием и восстановлением данных, тогда как о «непрерывности бизнеса» (НБ) стали говорить в связи с бесперебойной деятельностью всей организации, включая в первую очередь все ее бизнес-процессы (основные и вспомогательные), а потом уже производственное оборудо­вание, средства коммуникации, сервисы и персонал.
Планирование ОНБ стало процессом обеспечения гарантии восста­новления функционирования организации в случае возникновения како­го-либо неожиданного или нежелательного инцидента, способного не­гативно воздействовать на непрерывность важных функций бизнеса и поддерживающих его элементов, с угрозой потери всего бизнеса. Про­цесс ОНБ также обеспечивает уверенность в том, что восстановление всех функций бизнеса в исходное состояние достигается с учетом за­данных очередностей и интервалов времени и за счет применения необ­ходимых плановых мер и средств. Поэтому перед каждой организацией рано или поздно встают следующие вопросы:

  • насколько применим и критичен для нее тот или иной риск прерыва­ния бизнеса;

  • как избежать данного риска или минимизировать его негативные по­следствия;

  • что нужно сделать заранее;

  • как найти «золотую середину» между приемлемыми инвестициями в превентивные меры (по предотвращению прерываний и минимиза­ции их последствий) и возможными потерями.

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

  • анализ рисков ИБ, связанных с чрезвычайными ситуациями (ЧС);

  • установление критериев оценки возможности перерастания инци­дента ИБ в ЧС и планирование действий в данном случае;

  • определение сценариев реализации ЧС, связанных с ИБ, для которых будут разработаны соответствующие планы;

  • выбор стратегии ОИБ в процессе ЧС;

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

  • разработка, тестирование и обновление плана восстановления рабо­ты защитных мер после ЧС (или включение соответствующих разде­лов в уже имеющиеся планы в организации).

Таким образом, УНБ и ОИБ тесно связаны между собой. Одни ана­литики считают, что ИБ - часть НБ. Другие полагают, что НБ - состав­ная часть ИБ. Ключевой стандарт ИБ ISO/IEC 27001 и все семейство стандартов серии 27000 рассматривают НБ как одну из И областей управления. Поэтому можно сказать, что формально НБ - часть науки об ИБ. С другой - бизнес или, более широко, деятельность можно осу­ществлять и без применения ИТ. В стандарте ISO/IEC 27002 отмечено, что ОИБ - это защита информации от различного вида угроз, способная обеспечить НБ, минимизировать риски, максимизировать возврат инве­стиций и преимущества для бизнеса. Иными словами, ИБ служит общей цели развития бизнеса и обеспечения его непрерывности.
В данной главе вводятся определения НБ, УНБ и СУНБ. Рассматри­вается применение цикла PDCA к СУНБ. Детально описывается жиз­ненный цикл УНБ, включающий шесть элементов: управление про­граммой УНБ, анализ НБ организации, определение стратегии УНБ, разработка и внедрение в УНБ ответных мер на инциденты, меры по применению, поддержке и анализу УНБ и внедрение УНБ в культуру организации. Определяется состав документации в области НБ, в част­ности политика УНБ и планы управления инцидентом, обеспечения не­прерывности и восстановления бизнеса. Анализируются готовность ИТТ к ОНБ и интеграция процессов готовности ИТТ и ОНБ в рамках цикла PDCA.
3.1. Определения непрерывности бизнеса
и управления ею

Под деятельностью (англ, activity) понимается процесс или система процессов, осуществляемых организацией с целью производства одного или более видов продукции, оказания услуг или их поддержки [9-13]. Примерами деятельности являются бухгалтерский учет, обеспечение ИТТ, ОИБ и т. п.
Среди всех видов деятельности организации выделяют критические (англ, critical activities) - такие, которые должны осуществляться для обеспечения поставки ключевой продукции и услуг, позволяющие дос­тигать наиболее важных и первоочередных целей организации. Каждый критический вид деятельности (КВД) обычно поддерживает одну или более ключевую продукцию или услугу. Потеря такой деятельности может оказать в краткосрочный период времени максимальное негатив­ное воздействие на организацию. Она должна быть восстановлена в кратчайшие сроки.
При нарушении деятельности организации (англ, disruption) возни­кает невозможность поставки продукции или оказания услуг, установ­ленных в соответствии с целями организации, или перебои в этой дея­тельности, вызванные ожидаемым (например, забастовка рабочих) или непредвиденным (например, отключение электрической энергии) собы­тием или явлением.
В противоположность этому непрерывность бизнеса (англ, business continuity) определяется как стратегическая и тактическая способ­ность организации планировать свою работу в случае инцидентов и нарушения ее деятельности, направленная на обеспечение непре­рывности бизнес-операций на установленном приемлемом уровне [9- 13]. Соответственно ОНБ-это обеспечение такой способности. Инци­дент в текущем разделе будет определяться как ситуация, которая мо­жет произойти и привести к нарушению деятельности организации, раз­рушениям, потерям, чрезвычайной ситуации или кризису в бизнесе. Это понятие шире, чем просто инцидент ИБ. Аналогичные соображения бу­дут приниматься во внимание в отношении терминов «угроза» и «риск».
Тогда управление непрерывностью бизнеса (англ, business continuity management) - это полный процесс управления, предусмат- р ив аю щи й идентификацию потенциальных угроз и их воздействие на деятельность организации, который создает основу для повыше­ния устойчивости организации к инцидентам и направлен на реали­зацию эффективных ответных мер против них, что обеспечивает защиту интересов ключевых причастных сторон, репутации орга­низации, ее бренда и деятельности, добавляющей ценность [9-13]. Инциденты могут быть различны по характеру и масштабам последст­вий. Последствия могут привести к потере жизни людей, активов или доходов, либо неспособности поставлять продукцию и оказывать услу­ги, от которых порой зависит выполнение стратегий, сохранение репу­тации или даже само существование организации и потеря ее руковод­ством своего бизнеса.
Заметим, что принятыми синонимами используемого в рамках дан­ного учебного пособия термина УНБ являются «менеджмент непрерыв­ности бизнеса», «управление непрерывностью деятельности» и «управ­ление бесперебойностью работы» [12]. Выбор конкретного термина за­висит от потребностей организации и требований ее причастных сторон.
На самом высоком уровне понимания УНБ организация обеспечива­ет достижение своих целей и задач в условиях возникновения угрозы неожиданного нарушения ее деятельности. Поэтому процесс УНБ как комплексный процесс управления включает в себя управление восста­новлением или продолжением деятельности организации в случае на­рушений в ее работе, а также общей программой УНБ (англ, business continuity management programme) путем обучения, практического при­менения и анализа НБ, разработкой и актуализацией (пересмотром и обновлением) планов ОНБ (англ, business continuity plan). Этот процесс нельзя свести только к готовности к управлению инцидентами, аварий­ному восстановлению, созданию и постоянному обновлению организа­ционных и технических мер, обеспечивающих возможность этого вос­становления, или антикризисному управлению, или управлению риска­ми с целью их уменьшения или устранения, или восстановлению технической архитектуры. К нему нельзя относиться как к области дея­тельности узкой группы специалистов. Напротив, инициатором и дви­жущей силой процесса УНБ должно быть высшее руководство органи­зации. УНБ охватывает все стороны деятельности организации и тесно связано с самым широким кругом всех вопросов управления.
Процесс УНБ обеспечивает основу для поддержания устойчивости организации и возможности для эффективного реагирования на кризис­ные и чрезвычайные сизуации с целью защиты интересов собственни­ков и заинтересованных сторон, репутации и наиболее существенных сфер бизнеса организации. Этот процесс подразумевает и определение потенциальных угроз для организации и проведение анализа их влияния на бизнес в случае реализации. Он также регулирует аспекты аудита и пересмотра мер, процедур и планов ОНБ с целью подтверждения их со­ответствия текущим условиям и потребностям организации.
В общем случае процесс УНБ можно разделить на два направления: I) обеспечение устойчивости бизнес-процессов к инцидентам;

  1. восстановление бизнеса, включая бизнес-процессы, операции и ресурсы, организации после инцидентов.

В первом случае задача УНБ заключается в снижении вероятности наступления рискового события и выражается в разработке и внедрении превентивных антикризисных мероприятий; во втором случае - в мини­мизации и корректировке негативного влияния уже наступившего ин­цидента.
Процесс УНБ сводит воедино следующие ключевые аспекты [23,24]:

  • понимание рисков, с которыми сталкивается организация, с точки зрения вероятности возникновения и проявления последствий с те­чением времени, включая выявление и присваивание приоритетов критическим бизнес-процессам;

  • выявление всех активов, вовлеченных в критические бизнес-процессы;

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

  • рассмотрение возможности страхования как всего процесса ОНБ, так и отдельно управления операционными рисками при обработке ин­формации;

  • выявление и исследование возможности реализации дополнительных предупреждающих и снижающих последствия средств управления;

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

  • обеспечение безопасности персонала, защиты систем обработки ин­формации и всей собственности организации;

  • выработка и написание планов ОНБ, учитывающих требования по ОИБ в соответствии с согласованной стратегией УНБ;

  • регулярное испытание и обновление реализованных планов и про­цессов;

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

Процесс УНБ активизирует работу других процессов, в рамках кото­рых в соответствии с целями организации в области ОНБ устанавлива­ются стратегические цели и структура управления. Эти процессы актив­но способствуют следующему [9, 11]:

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

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

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

Отдельные процессы УНБ зависят от размеров, структуры, сферы и сложности деятельности организации, однако основные принципы ОНБ одинаковы для всех организаций - некоммерческих, частных, государ­ственных.
Высшее руководство организации путем идентификации ключевой продукции и услуг определяет область действия УНБ, что способствует достижению установленных целей и выполнению договорных обяза­тельств и законодательных требований, применимых к данной органи­зации. Область действия УНБ устанавливается совместно с проведени­ем анализа воздействия на бизнес (англ, business impact analysis), подра­зумевающего процесс исследования функционирования бизнеса и последствий от воздействия на него разрушающих факторов, и разра­боткой планов ОНБ.
Любая организация получает следующие возможности от реализа­ции эффективного УНБ [9, 11]:

  • заранее идентифицировать возможные нарушения функционирова­ния бизнес-процессов и их возможные последствия;

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

  • управлять неисследованными рисками (включая те, которые не под­лежат страхованию);

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

  • продемонстрировать работу предусмотренных ответных мер во вре­мя учений по УНБ (посредством их тестирования);

  • повысить свою репутацию;

  • создать конкурентные преимущества путем демонстрации способно­сти организации поддерживать непрерывность поставок и предос­тавления услуг.

Тогда внедрение эффективного УНБ позволяет получить организа­ции следующие результаты [9, 11]:

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

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

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

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

  • понимание и установление требований причастных сторон;

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

  • дополнительная защита цепи поставок организации;

  • дополнительная защита репутации организации;

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

    1. Система управления непрерывностью бизнеса


Download 1.2 Mb.

Do'stlaringiz bilan baham:
1   ...   13   14   15   16   17   18   19   20   ...   43




Ma'lumotlar bazasi mualliflik huquqi bilan himoyalangan ©fayllar.org 2024
ma'muriyatiga murojaat qiling