Система защиты от утечек информации основывается в том числе на выявлении, предотвращении, регистрации и устранении последствий инцидентов информационной безопасности или событий, нарушающих регламентированные процедуры защиты ИБ. Существует ряд методик, определяющих основные параметры управления ими. Эти методики внедряются на уровне международных стандартов, устанавливающих критерии оценки качества менеджмента в компании. События или инциденты ИБ в рамках этих регламентов выявляются и регистрируются, их последствия устраняются, а на основании анализа причин их возникновения положения и методики дорабатываются.
Понятие инцидента
Международные регламенты, действующие в сфере сертификации менеджмента информационных систем, дают свое определение этому явлению. Согласно им инцидентом информационной безопасности является единичное событие нежелательного и непредсказуемого характера, которое способно повлиять на бизнес-процессы компании, скомпрометировать их или нарушить степень защиты информационной безопасности. На практике к этому понятию относятся разноплановые события, происходящие в процессе работы с информацией, существующей в электронной форме или на материальных носителях. К ним может относиться и оставление документов на рабочем столе в свободном доступе для другого персонала, и хакерская атака – оба инцидента в равной мере могут нанести ущерб интересам компании.
Среди основных типов событий присутствуют:
- нарушение порядка взаимодействия с Интернет-провайдерами, хостингами, почтовыми сервисами, облачными сервисами и другими поставщиками телекоммуникационных услуг;
- отказ оборудования по любым причинам, как технического, так и программного характера;
- нарушение работы программного обеспечения;
- нарушение любых правил обработки, хранения, передачи информации, как электронной, так и документов;
- неавторизированный или несанкционированный доступ третьих лиц к информационным ресурсам;
- выявление внешнего мониторинга ресурсов;
- выявление вирусов или других вредоносных программ;
- любая компрометация системы, например, попадание пароля от учетной записи в открытый доступ.
Все эти события должны быть классифицированы, описаны и внесены во внутренние документы компании, регламентирующие порядок обеспечения информационной безопасности. Кроме того, в регламентирующих документах необходимо установить иерархию событий, разделить их на более или менее значимые. Следует учитывать, что существенная часть инцидентов малозаметны, они происходят вне периметра внимания должностных лиц. Такие события должны быть описаны особо, и определены меры для их выявления в режиме постфактум.
При описании мер реакции следует учитывать, что изменение частоты появления и общего количества инцидентов информационной безопасности является одним из показателей качества работы систем, обеспечивающих ИБ, и само по себе классифицируется в качестве существенного события. Учащение событий может говорить о намеренной атаке на информационные системы компании, поэтому оно должно стать основанием для анализа и дальнейшего повышения уровня защиты.
Место управления инцидентами в общей системе информационной безопасности
Регламенты, определяющие порядок управления инцидентами информационной безопасности, должны стать составной частью бизнес-процессов и их регламентации. Предполагая, что инцидентом является недозволенное, несанкционированное событие, в работе нужно опираться на механизм, разделяющий события и действия на разрешенные и запрещенные, определяющий органы, имеющие права на разработку таких норм. Кроме того, регламент определяет методы и способы классификаций событий, прямо не обозначенных в документах в качестве значимых, и механизм выявления таких событий, их описания и последующего внесения в регламентирующие документы.
Например, в регламенте может быть запрещено размещение конфиденциальной информации на портативных носителях без ее кодировки или шифрования, при этом не будет прямо установлен запрет на вынос таких устройств за пределы компании. Случайная утрата компьютера в результате криминального посягательства станет инцидентом, но он не будет прямо запрещен. Соответственно, в документах должен быть установлен механизм дополнения норм и правил безопасности в ситуативном порядке без излишней бюрократии. Это позволит оперативно реагировать на новые вызовы и дорабатывать меры защиты своевременно, а не со значительным запозданием.
Система сертификации ISO 27001 в качестве одного из элементов ИБ предполагает необходимость создания отдельной процедуры управления инцидентами информационной безопасности в рамках общей системы стандартизации бизнес-процессов.
Особенности управления событиями безопасности
Несмотря на то, что стандарты прямо рекомендуют внедрять методики управления инцидентами информационной безопасности, на практике внедрение и реализация этих практик встречают множество сложностей. Отдельные процедуры управления инцидентами не внедряются. Этот показатель не говорит о том, что системы менеджмента инцидентов работают хорошо или плохо, это свидетельствует только о том, что существует определенная брешь в системе безопасности.
Управление инцидентами информационной безопасности основано на следующих действиях:
- определение. В организации отсутствует методика выявления и классификации инцидентов, описание их основных параметров, поэтому сотрудники встают перед необходимостью или самостоятельно определять критерии события, или игнорировать его. Вход в сеть под аккаунтом другого сотрудника, согласно стандартам, является инцидентом информационной безопасности, но он не будет зафиксирован в журнале, так как сотрудники считают такое поведение стандартным и дозволенным, особенно в условиях дефицита кадровых ресурсов;
- оповещение о возникновении. Даже если какое-либо событие может быть определено согласно принятым в организации методикам или личному мнению сотрудника как инцидент, чаще всего в организации не разработаны стандарты и маршруты оповещения о таких событиях. Даже если кем-то будет выявлен факт копирования документов, относящихся к коммерческой тайне, сотрудник встанет в тупик перед вопросом, кто именно и в какой форме должен быть оповещен об этом инциденте: его руководитель, служба безопасности или иное лицо;
- регистрация. Эта часть стандартов является наиболее невыполнимой для российских компаний, инциденты не идентифицируются, соответственно, не фиксируются. Отсутствует практика заведения регистров учета, в которых бы фиксировались значимые события, что впоследствии давало бы материал для их анализа и прогноза возможных атак;
- устранение причин и последствий. Любой инцидент вызывает определенные следы и последствия, которые, с одной стороны, могут мешать деятельности компании, с другой – служат материалом для проведения расследования причин его возникновения. Отсутствие регламентов устранения последствий может привести как к накоплению ошибок, так и к полному уничтожению доказательственной базы, позволяющей выявить виновника произошедшей ситуации. Любые срочные меры, предпринимаемые для восстановления стабильности, могут случайно или намеренно уничтожить следы проникновения в базу данных;
- меры реагирования на инциденты. В ряде случаев возникновение инцидента может потребовать срочных мер реагирования, например, отключения компьютера от сети, приостановки передачи информации, установки контакта с провайдером. Должны быть определены органы и должностные лица, ответственные за разработку механизма реагирования и его оперативную реализацию;
- расследование. Полномочия по расследованию должны быть переданы из ведения IT-службы в компетенцию служб безопасности. В рамках расследования должны быть изучены журналы учета, проанализированы действия всех пользователей и администраторов, которые имели доступ к системам в период возникновения чрезвычайной ситуации. Расследование должно стать одним из основных элементов управления инцидентами. На практике в российских компаниях от реализации этого этапа отказываются, ограничиваясь устранениями последствий произошедшего события. При необходимости расследование должно производиться с привлечением оперативно-следственных органов;
- реализация превентивных мер. В большинстве случаев инциденты не являются единичными, их возникновение свидетельствует о том, что в системе ИБ возникла брешь и аналогичные случаи будут повторяться. Во избежание этих рисков необходимо по результатам расследования подготовить протокол или акт комиссии, в котором определить, какие именно меры должны быть применены для предотвращения аналогичных ситуаций. Кроме того, применяются определенные меры дисциплинарной ответственности, предусмотренные Трудовым кодексом и внутренними регламентами;
- аналитика. Все события, нарушающие регламентированные процессы и могущие быть квалифицированы в качестве инцидентов информационной безопасности, должны стать основой для анализа, который поможет определить их характер, проявить системность и выработать рекомендации для совершенствования системы ИБ, действующей в компании.
Управление инцидентами в безопасности с помощью «СёрчИнформ КИБ» упрощает работу ИБ-службы компании: система экстренно реагирует на нарушения политик безопасности и снабжает ИБ-специалиста большой доказательной базой.
Основные проблемы, связанные с нарушением процедур, обусловлены неготовностью персонала в полной мере воспринимать, адаптировать и выполнять рекомендации. Касательно инцидентов информационной безопасности, сложности в восприятии и реакции вызывают моменты, связанные с совершением действий, которые прямо не регламентированы инструкциями или стандартами или вызывают ощущение излишних или избыточных.
Процедура управления
Как любая корпоративная процедура, организация управления инцидентами информационной безопасности должна пройти несколько этапов: от принятия решения о его необходимости до внедрения и аудита. На практике менеджмент большинства предприятий не осознает необходимости применения этой практики защиты информационного периметра, поэтому для возникновения инициативы о ее внедрении часто требуется аудит систем ИБ внешними консультантами, выработка ими рекомендаций, которые затем будут реализованы руководством предприятия. Таким образом, начальной точкой для реализации процедур управления инцидентами ИБ становится решение исполнительных органов или иногда более высоких звеньев системы управления компании, например, Совета директоров.
Общее решение обычно принимается в русле модернизации существующей системы ИБ. Система управления инцидентами является ее основной частью. На уровне принятия решения необходима его локализация в общей парадигме целей компании. Оптимально, если функционирование системы ИБ становится одной из бизнес-целей организации, а качество ее работы подкрепляется установлением ключевых показателей эффективности для ответственных сотрудников компании. После определения статуса функционирования системы необходимо перейти к разработке внутренней документации, опосредующей связанные с ней отношения в компании.
Для придания значимости методикам управления информационной безопасностью они должны быть утверждены на уровне исполнительного органа (генерального директора, правления или совета директоров). С данными документа необходимо ознакомить всех сотрудников, имеющих отношение к работе с информацией, существующей в электронных формах или на материальных носителях.
В структуре документа, оформляемого в виде положения или регламента, должны выделяться следующие подразделы:
- определение событий, признаваемых инцидентами применительно к системе безопасности конкретной компании. Так, пользование внешней электронной почтой может быть нарушением ИБ для государственной компании и рядовым событием для частной;
- порядок оповещения о событии. Должны быть определены формат уведомления (устный, докладная записка, электронное сообщение), перечень лиц, которые должны быть оповещены, и дублирующие их должности в случае их отсутствия, перечень лиц, до которых также доносится информация о событии (руководство компании), срок уведомления после получения информации об инциденте;
- перечень мероприятий по устранению последствий инцидента и порядок их реализации;
- порядок расследования, в котором определяются ответственные за него должностные лица, механизм сбора и фиксации доказательств, возможные действия по выявлению виновника;
- порядок привлечения виновных лиц к дисциплинарной ответственности;
- меры усиления безопасности, которые должны быть применены по итогам расследования инцидента;
- порядок минимизации вреда и устранения последствий инцидентов.
При разработке регламентов, опосредующих систему управления событиями ИБ, желательно опираться на уже созданные и показавшие свою эффективность методики и документы, включая формы отчетов, журналы регистрации, уведомления о событии.
Устранение причин и последствий события, его расследование
Непосредственно после уведомления соответствующих должностных лиц о произошедшем инциденте и его фиксации необходимо совершить действия реагирования, а именно устранения причин и последствий события. Все этапы этих процессов должны найти свое отражение в регламентах. Там описываются перечни общих действий для отдельных наиболее значимых событий, конкретные шаги и сроки применения мер. Необходимо также предусмотреть ответственность за неприменение установленных мер или недостаточно эффективное их применение.
На этапе расследования от должностных лиц организации требуется:
- определить причины возникновения инцидента и недостатки регламентирующих документов и методик, сделавших возможным его возникновение;
- установить ответственных и виновных лиц;
- собрать и зафиксировать доказательства;
- установить мотивы совершения инцидента и круг лиц, причастных к нему помимо персонала компании, выявить заказчика.
Если предполагается в дальнейшем возбуждение судебного преследования по факту инцидента на основании совершения преступления в сфере информационной безопасности или нарушения режима коммерческой тайны, к расследованию уже на начальном этапе необходимо привлечь оперативно-следственные органы. Собранные самостоятельно факты без соблюдения процессуальных мер не будут признаны надлежащими доказательствами и приобщены к делу.
Как расследовать утечки информации с помощью DLP-системы? Читать.
Превентивные меры, изменения стандартов и ликвидация последствий
Непосредственно после выявления инцидента предпринимаются оперативные меры по устранению его последствий. На следующем этапе необходим анализ причин его возникновения и совершение комплекса действий, направленных на предотвращение возможного повторения аналогичного события. Сегодня основным регламентирующим документом, предлагающим стандарты реакции на инциденты, стал ISO/IEC 27000:2016, это последняя версия совместной разработки ISO и Энергетической комиссии. В России на основе более ранних версий ISO/IEC разработаны ГОСТы. В рамках ISO/IEC 27000:2016 предлагается создать специальную службу поддержки, Service Desk, на которую должны быть возложены функции управления инцидентами.
Аудит соблюдения стандартов
При получении сертификата соответствия по стандарту ISO 27001, а также при проверке соблюдений требований стандарта проводится аудит выполнения методик управления инцидентами информационной безопасности. При проведении аудита часто выясняется, что даже при внедрении стандартов возникает существенное количество проблем и недопониманий, связанных с регистрацией инцидентов и расследованием событий, послуживших причиной для их возникновения. Расследования осложняются тем, что под одной учетной записью могут входить несколько операторов или администраторов, что затрудняет их аутентификацию. На контроллере серверов в большинстве случаев не заводятся и не ведутся журналы учета событий. Отсутствие контролируемой системы идентификации пользователей, характерное для большинства российских компаний, позволяет в произвольном режиме менять информацию, останавливать серверы или модифицировать их работу. ИБ, внедренные в большинстве российских компаний, не позволяют контролировать действия администраторов.
Рекомендуется проведение аудита не реже чем раз в полгода. Его результатами должны стать обновление перечня событий, признаваемых инцидентами, доработка перечня необходимых действий по их устранению, изменение программных средств, обеспечивающих защиту информационного периметра. Если в компании установлены DLP-системы и SIEM-системы, то с учетом проведенного анализа инцидентов, произошедших за определенный период, и результатов аудита они могут быть доработаны.
Аудит не должен быть единственным фактором, выявляющим недостатки работы системы. Еще на этапе ее внедрения должны быть разработаны системы контроля качества процессов, результаты работы которых должны обрабатываться в регулярном режиме.
ПОПРОБУЙТЕ «СЁРЧИНФОРМ КИБ»!
Полнофункциональное ПО без ограничений по пользователям и функциональности.
Жизненный цикл процесса управления непрерывностью бизнеса
Управление непрерывностью бизнеса компании является циклическим процессом, который должен учитывать возможные изменения в бизнесе, сфере IT, законодательстве и других областях, влияющих на деятельность организации, а также помогать ей адаптироваться к этим изменениям. Другими словами, управление непрерывностью бизнеса является процессом его постоянного совершенствования, что, в свою очередь, повышает уверенность компании в надежности планов обеспечения непрерывности бизнеса.
Жизненный цикл процесса управления непрерывностью бизнеса включает 7 этапов, на каждом из которых определены последовательность шагов и результат (перечень этапов был построен на основе цикла BCM Institute[8]).
Инициация проекта
Проект – это деятельность, направленная на создание уникального продукта, услуги или результата.
План управления проектом / Project Management Plan – документ, описывающий, как проект будет исполняться, как будет происходить его мониторинг и контроль.
Руководство PMBOK – Пятое издание
На данном этапе определяется содержание проекта обеспечения непрерывности бизнеса и разрабатывается его пошаговый план. В нем определяется, как будет исполняться проект, как будет проводиться его мониторинг, контроль и закрытие, а также определяются границы проекта, роли членов проектной команды и цели проекта.
Помимо вышеперечисленных действий, необходимо определить потребность в проекте. Для некоторых компаний непрерывность бизнеса – это обеспечение эффективности критически важных бизнес-функций, а также демонстрация устойчивости бизнеса клиентам. Но нельзя забывать, что существуют требования нормативно-правовых актов и регулирующих органов к непрерывности бизнеса. Далее в таблице перечислены и описаны стандарты / нормативно-правовые акты (НПА), широко использующиеся на территории Российской Федерации, а также ряд требований, которые предъявляют данные стандарты / НПА к системе непрерывности бизнеса.
| Стандарт / НПА | Требование | Описание | Статус |
|---|---|---|---|
| ISO/IEC 27001:2013 «Information technology – Security techniques – Information security management systems – Requirements» (Информационная технология. Методы обеспечения безопасности. Системы менеджмента информационной безопасности) | A.17 Information security aspects of business continuity management (Аспекты информационной безопасности в управлении непрерывностью бизнеса) |
Непрерывность информационной безопасности должна быть встроена в систему непрерывности бизнеса компании. Для этого необходимо: – спланировать непрерывность информационной безопасности; |
Непрерывность информационной безопасности является одним из требований в том случае, если компания стремится получить сертификат соответствия требованиям ISO/IEC 27001:2013 «Information technology – Security techniques – Information security management systems – Requirements». |
| ISO 22301:2012 «Societal security – Business continuity management systems – Requirements» (Социальная безопасность. Системы менеджмента непрерывности бизнеса) | Данный стандарт посвящен непрерывности бизнеса. | В стандарте прописаны: – требования, необходимые для установления системы менеджмента непрерывности бизнеса в компании; – требования к функциям высшего руководства в системе менеджмента непрерывности бизнеса; – требования к установлению стратегических целей и руководящих принципов системы менеджмента непрерывности бизнеса; – требования к обеспечению непрерывности бизнеса, порядок разработки процедур управления в условиях инцидента. |
Наличие планов BCP/DRP (данные планы рассмотрены в разделе «Разработка и внедрение планов») является обязательным условием в том случае, если компания стремится получить сертификат соответствия требованиям ISO 22301:2012 «Societal security – Business continuity management systems – Requirements». |
| ГОСТ Р 53647 «Менеджмент непрерывности бизнеса» | Данный стандарт посвящен непрерывности бизнеса. | Настоящий стандарт устанавливает требования к планированию, созданию, функционированию, мониторингу, анализу, проведению учений, поддержке и улучшению документированной системы менеджмента непрерывности бизнеса. | Носит рекомендательный характер. |
| СТО БР ИББС-1.0-2014 «Обеспечение информационной безопасности организаций банковской системы Российской Федерации» | 8.11. Требования к организации обеспечения непрерывности бизнеса и его восстановления после прерываний |
В организации банковской системы должен быть определен план обеспечения непрерывности бизнеса и его восстановления после возможного прерывания. План должен содержать инструкции и порядок действий работников организации банковской системы по восстановлению бизнеса. В частности, в состав плана должны быть включены: – условия активации плана; – действия, которые должны быть предприняты после инцидента ИБ; – процедуры восстановления; – процедуры тестирования и проверки плана; – план обучения и повышения осведомленности сотрудников; – обязанности сотрудников с указанием ответственных за выполнение каждого из положений плана. Также должны быть установлены требования по обеспечению ИБ, регламентирующие вопросы обеспечения непрерывности бизнеса и его восстановление после прерывания, в том числе требования к мероприятиям по восстановлению необходимой информации, программного обеспечения, технических средств, а также каналов связи. |
Носит рекомендательный характер. |
| Приказ ФСТЭК России от 11.02.2013 г. № 17 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» | X. Обеспечение доступности информации (ОДТ) | В соответствии с Приказом ФСТЭК России от 11.02.2013 г. № 17 «Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах» необходимо: – использовать отказоустойчивые технические средства; – резервировать технические средства, программное обеспечение, каналы передачи информации, средства обеспечения функционирования информационной системы; – контролировать безотказное функционирование технических средств; – обеспечить обнаружение и локализацию отказов функционирования технических средств; – принимать меры по восстановлению отказавших средств; – тестировать технические средства; – осуществлять периодическое резервное копирование информации на резервные машинные носители; – обеспечить возможность восстановления информации с резервных машинных носителей информации (резервных копий) в течение установленного временного интервала; – контролировать состояние и качество предоставления уполномоченным лицом вычислительных ресурсов (мощностей), в том числе по передаче информации. |
В случае если система классифицирована по 1 или 2 классу защищенности, описанные в приказе требования носят обязательный характер. |
| Приказ ФСТЭК России от 18.02.2013 г. № 21 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных» |
X. Обеспечение доступности персональных данных (ОДТ) | В соответствии с Приказом ФСТЭК России от 18.02.2013 г. № 21 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных» необходимо обеспечить: – контроль безотказного функционирования технических средств; – обнаружение и локализацию отказов функционирования; – принятие мер по восстановлению отказавших средств и их тестирование; – резервное копирование персональных данных на резервные машинные носители персональных данных; – возможность восстановления персональных данных с резервных машинных носителей персональных данных (резервных копий) в течение установленного временного интервала. |
В том случае, если для информационной системы персональных данных определен 1 или 2 уровень защищенности, описанные в приказе требования носят обязательный характер. |
После того как план проекта окончательно сформирован и разработан, его необходимо направить руководству компании для утверждения. Работа по плану должна начинаться только после согласования с руководством.
Обратите внимание! В некоторых компаниях спонсор проекта не уделяет ему должного внимания, и ответственность возлагается на менеджера среднего звена. Это может привести к проблемам в коммуникации заинтересованных сторон и снижению поддержки высшего руководства компании. Данную проблему можно решить путем создания проектного комитета, куда войдут представители всех заинтересованных сторон. Комитет должен периодически проводить встречи, решать проблемы и обсуждать ход проекта.
Анализ воздействия на бизнес
Анализ воздействия на бизнес – метод, позволяющий исследовать воздействие инцидентов на ключевые виды деятельности и процессы компании.
На данном этапе предусмотрено детальное изучение процессов компании. Для этого консультант проводит интервью с руководством отделов, входящих в область проекта. В ходе беседы запрашивается информация о деятельности отдела и составляется перечень процессов / функций, которые он осуществляет. Далее для детального изучения процессов / функций интервьюируются владельцы процессов и определяется тип воздействия на бизнес (материальный, репутационный) и степень зависимости процесса от IT и внешних сервисов. А затем определяется максимально допустимое время простоя (Maximum Allowable Outage).
Maximum Allowable Outage – период времени, по истечении которого существует угроза окончательной утраты жизнеспособности организации, в том случае, если поставка продукции и/или предоставление услуг не будут возобновлены.
ГОСТ Р ИСО/МЭК 31010-2011 «Менеджмент риска. Методы оценки риска»
После того как владельцем процесса / функции был определен MAO, IT-департаментом (на основе MAO) определяются показатели RTO, RPO, SDO.
— Recovery Time Objective (RTO). Время, в течение которого должно происходить восстановление бизнес-функции или ресурса при наступлении нештатных ситуаций.
— Recovery Point Objective (RPO). Целевая точка восстановления определяет объем допустимых потерь данных в случае прерывания операций. Например, если RPO равен 15 минутам – допускается потеря данных за последние 15 минут.
— Service Delivery Objective (SDO). Уровень доступности сервиса в определенный момент времени.
На рисунке изображено, как определяются вышеперечисленные метрики:
Результатом проведения анализа воздействия на бизнес являются:
— перечень ранжированных по приоритетам критических процессов и соответствующих взаимозависимостей;
— зарегистрированные экономические и производственные воздействия, вызванные нарушением критических процессов;
— вспомогательные ресурсы, необходимые для идентифицированных критических процессов;
— возможные сроки простоя и восстановления критических процессов и взаимосвязанных информационных технологий.
Обратите внимание! Зачастую владельцы бизнес-процессов намеренно или неосознанно завышают целевые значения нормативов восстановления, что способствует искажению анализа и влечет за собой необоснованные расходы. Чтобы избежать этой проблемы, необходимо вместе с проектной группой, а также с заинтересованными сторонами рассмотреть ценность бизнес-функции в контексте происшествия, которое затронуло всю компанию. Этот подход позволит объективно определить нормативы восстановления.
Оценка рисков
Риск – влияние неопределенности на цели.
Отступление: в данной статье не рассматриваются детали оценки рисков.
Оценка риска / risk assessment – процесс, охватывающий идентификацию риска, анализ риска и оценку риска.
ISO 73:2009 «Менеджмент рисков. Словарь»
Целью оценки рисков в рамках управления непрерывностью бизнеса является определение событий, которые могут привести к нарушению деятельности компании, а также их последствий (ущерб).
Оценка риска обеспечивает:
— понимание потенциальных опасностей и воздействия их последствий на достижение установленных целей компании;
— понимание угроз и их источников;
— идентификацию ключевых факторов, формирующих риск; уязвимых мест компании и ее систем;
— выбор способов обработки риска;
— соответствие требованиям стандартов.
Процесс оценки рисков состоит из:
— Идентификации риска – процесс определения элементов риска, описания каждого из них, составления их перечня. Целью идентификации риска является составление перечня источников риска и угроз, которые могут повлиять на достижение каждой из установленных целей компании;
— Анализ риска – процесс исследования информации о риске. Анализ риска обеспечивает входные данные процесса общей оценки риска, помогает в принятии решений относительно необходимости обработки риска, а также в выборе соответствующей стратегии и методов обработки;
— Сравнительная оценка риска – сопоставление его уровня с критериями, установленными при определении области применения менеджмента риска, для определения типа риска и его значимости.
Оценка рисков в дальнейшем позволит обоснованно выработать стратегию непрерывности бизнеса, а также поможет определить оптимальный сценарий ее реализации.
Разработка стратегии непрерывности бизнеса
После того как были проанализировали требования к непрерывности, необходимо выбрать и обосновать возможные технические и организационные решения. В процессе выбора решения необходимо детально рассмотреть возможные действия в отношении помещений, технологий, информационных активов, контрагентов, а также партнеров. Данные решения, как правило, выбираются с целью:
— защиты приоритетных видов деятельности компании;
— их эффективного восстановления;
— смягчения последствий инцидентов, разработки ответных и превентивных мер.
Примечание: выбор решения должен основываться на стоимости восстановления и стоимости простоя.
Данные решения могут включать в себя:
— «зеркальные» площадки;
— «горячие» площадки;
— «теплые» площадки;
— «холодные» площадки;
— площадки динамического распределения нагрузки;
— аутсорсинг / соглашение;
— мобильные площадки.
Основными отличиями вышеперечисленных решений являются стоимость и время восстановления деятельности компании.
Обратите внимание! Решения помогают в реализации эффективной стратегии непрерывности бизнеса. Но для того, чтобы определить оптимальный вариант, необходимо выбирать стратегические решения, исходя из результатов анализа воздействий на бизнес и оценки рисков (этот подход поможет обосновать руководству необходимость инвестиций в проект управления непрерывностью бизнеса).
Разработка и внедрение планов непрерывности бизнеса
План – это заранее намеченная система мероприятий, предусматривающая порядок, последовательность и сроки выполнения работ.
В соответствии с лучшими практиками [1, 2, 4], планы управления непрерывностью должны состоять из трех компонентов:
1. Реагирование на чрезвычайные ситуации – определяет последовательность действий, которые необходимо осуществить при обнаружении инцидента.
2. Управление инцидентами – определяет методы, необходимые для смягчения или уменьшения размера происшествия.
3. Восстановление деятельности – определяет последовательность действий, которые необходимо осуществить для того, чтобы восстановить сервис на заданном уровне.
Примечание: для наглядности используйте блок-схемы и другие графические способы представления информации.
Примерная структура плана обеспечения непрерывности бизнеса:
1. Введение
1.1. Исходная информация
1.2. Границы действия плана
1.3. Предпосылки создания плана
2. Концепция
2.1. Описание системы обеспечения непрерывности
2.2. Описание этапов восстановления непрерывности
2.3. Роли и их обязанности
3. Активация плана
3.1. Критерии и порядок активации
3.2. Порядок уведомления заинтересованных лиц
3.3. Порядок оценки происшествия
4. Контроль
5. Восстановление
5.1. Последовательность восстановления непрерывности
Специалистами NIST было разработано руководство [1], которое достаточно подробно описывает необходимые планы обеспечения непрерывности бизнеса. Далее приведена таблица, где описан каждый из планов (указанных в руководстве NIST), а также даны ссылки на стандарты / НПА, которые предписывают разработку таких планов.
| Наименование плана | Описание плана | Стандарт / НПА |
|---|---|---|
| Business Continuity Plan (BCP) – План обеспечения непрерывности бизнеса | Набор задокументированных процедур, которые разработаны, обобщены и актуализированы с целью их использования в случае возникновения инцидента, и направлены на обеспечение возможности продолжения выполнения компанией критических важных видов деятельности на установленном приемлемом уровне. | ISO 22301 «Социальная безопасность. Системы менеджмента непрерывности бизнеса»: 8.4.4 Планы непрерывности бизнеса (Business continuity plans) |
| Continuity of Operations Plan (COOP) – План непрерывности операций | Фокусируется на восстановлении критически важных функций компании на альтернативной площадке и на их выполнении в течение 30 дней. |
– |
| Crisis Communication Plan – План антикризисных коммуникаций | В данном плане задокументированы процедуры и правила внешних и внутренних коммуникаций в случае чрезвычайных ситуаций. | Федеральный закон от 21.12.1994 № 68 «О защите населения и территорий от чрезвычайных ситуаций природного и техногенного характера»: Статья 14. Обязанности организаций в области защиты населения и территорий от чрезвычайных ситуаций («Организации обязаны предоставлять в установленном порядке информацию в области защиты населения и территорий от чрезвычайных ситуаций, а также оповещать работников организаций об угрозе возникновения или о возникновении чрезвычайных ситуаций»). |
| Critical Infrastructure Protection Plan (CIP) – План защиты критических инфраструктур | План направлен на защиту ключевых ресурсов и компонентов национальной инфраструктуры. | Указ Президента Российской Федерации от 15 января 2013 г. N 31с «О создании государственной системы обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации». |
| Cyber Incident Response Plan – План реагирования на киберинциденты | План, описывающий процедуры реакции на инциденты, связанные с атаками хакеров, вторжения в информационную систему и другие проблемы безопасности. | ГОСТ Р ИСО/МЭК ТО 18044-2007 «Информационная технология. Методы и средства обеспечения безопасности. Менеджмент инцидентов информационной безопасности»; NIST 800-61 «Computer Security. Incident Handling Guide». |
| Disaster Recovery Plan (DRP) – План восстановления после сбоя | План восстановления инфраструктуры компании после возникновения аварии. | ISO 22301 «Социальная безопасность. Системы менеджмента непрерывности бизнеса»: 8.4.5 Восстановление (Recovery). |
| Information System Contingency Plan (ISCP) – План на случай непредвиденных ситуаций в информационных системах | План восстановления системы, сетей и основных приложений после аварии. Данный план необходимо разработать для каждой критической системы и/или приложения. |
– |
| Occupant Emergency Plan (OEP) – План действия персонала в случае чрезвычайной ситуации | В данном плане определяется порядок обеспечения безопасности персонала и процедуры эвакуации в случае чрезвычайных ситуаций. | Федеральный закон от 21.12.1994 г. № 68 «О защите населения и территории от чрезвычайных ситуаций природного и техногенного характера»; Федеральный закон от 21.12.1994 № 69 «О пожарной безопасности». |
Вышеперечисленные документы составляются исходя из потребностей компании, но на практике чаще всего применяются следующие виды планов:
— План реагирования на инциденты – данный вид плана может включать в себя план реагирования на киберинциденты, план на случай непредвиденных ситуаций в информационных системах. Данный план поможет уменьшить масштабы катастрофы и смягчить ее последствия, что даст возможность сэкономить время и дополнительное преимущество при активации остальных типов планов.
— План действия персонала в чрезвычайных ситуациях – в соответствии с требованиями Федерального закона от 21.12.1994 г. №68 68 «О защите населения и территории от чрезвычайных ситуаций природного и техногенного характера» и Федерального закона от 21.12.1994 г. №69 «О пожарной безопасности» этот план является обязательным для всех компаний.
— План восстановления после сбоя – сфокусирован на восстановлении критически важных информационных систем. Данный вид плана осуществляет поддержу плана обеспечения непрерывности бизнеса и направлен на восстановление работоспособности отдельных систем и приложений.
— План обеспечения непрерывности бизнеса – сфокусирован на поддержке бизнес-процессов компании во время и после чрезвычайной ситуации; направлен на обеспечение возможности продолжения выполнения компанией критических важных для нее видов деятельности на установленном приемлемом уровне.
— План антикризисных коммуникаций – данный план поможет сохранить репутацию компании в кризисной ситуации. В нем документируется порядок взаимодействия со СМИ, правоохранительными органами, МЧС и т.д.
Обратите внимание! На этапе составления планов непрерывности бизнеса некоторые компании сосредоточиваются на технических решениях и не придают значения организационным мерам. В связи с этим необходимо указать на важность применения организационных мер наравне с техническими. Для этого проводятся обучающие семинары, тестирование планов, выпускаются учебные материалы.
Тестирование и пересмотр планов
Тестирование осуществляется для проверки работоспособности планов при возникновении определенного набора обстоятельств, влияющих на деятельность компании. План тестирования выбирается с учетом типа компании и ее целей.
Тесты – инструменты оценки, которые используют количественные метрики для проверки работоспособности IT-системы или ее компонента.
NIST Special Publication 800-84 «Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities»
К целям тестирования можно отнести:
— получение подтверждений работоспособности планов;
— проверку достаточности методического и технического обеспечения;
— получение необходимых навыков и знаний.
После того как была определена цель тестирования, разрабатывается сценарий, определяется метод тестирования и согласовывается с руководством. Чаще всего применяются следующие методы [2]:
— настольная проверка (Tabletop);
— имитация (Imitation);
— полное тестирование (Full business continuity testing).
После проведения тестирования составляются отчеты, в которых указываются сценарии и результаты тестирования, а также предложения по улучшению планов непрерывности деятельности.
Обратите внимание! Компании должны выбирать способ тестирования исходя из своих целей и финансовых возможностей.
Важно! Полное тестирование является самым эффективным, так как оно позволяет выявить множество недостатков, но из-за высоких рисков почти не используется на практике. Если компания решила использовать данный вид тестирования, необходимо заручиться поддержкой партнеров или воспользоваться услугами подрядчиков, чтобы минимизировать риски и предупредить значительные простои.
Обслуживание и обновление планов
Как уже отмечалось выше, управление непрерывностью бизнеса компании является циклическим процессом. А это значит, что нельзя ограничиваться одним только формированием планов, необходимо сопровождать, обновлять и совершенствовать их ежегодно, а иногда и чаще, например, в следующих случаях:
1. Изменение IT-инфраструктуры.
2. Изменение организационной структуры компании.
3. Изменения в законодательстве.
4. Обнаружение недостатков в планах при их тестировании.
Чтобы сохранить актуальность планов, необходимо выполнять следующие действия:
— проводить внутренние аудиты, включающие проверку восстановления после аварий, документации по обеспечению непрерывности и соответствующих процедур;
— проводить регулярные практические тренинги по выполнению плана;
— интегрировать вопросы непрерывности бизнеса в процесс управления изменениями компании.
Заключение
Управление непрерывностью бизнеса обеспечивает объединение всех применяемых на предприятии мер в целостный, адекватный реальным угрозам и управляемый комплекс, позволяющий компании непрерывно предоставлять услуги, избегать влияния чрезвычайных ситуаций на деятельность и минимизировать возможный ущерб.
Этот комплекс состоит из семи этапов, которые должны быть реализованы в компании для обеспечения непрерывности предоставления услуг и производства продуктов.
В данной статье описан каждый этап с привязкой к российским реалиям, а также указаны моменты, на которые стоит обратить внимание при реализации данного проекта.
Литература
1. ISO 22301 Societal security – Business continuity management systems – Requirements.
2. ГОСТ Р 53647 «Менеджмент непрерывности бизнеса».
3. ГОСТ Р ИСО/МЭК 31010 – 2011. «Менеджмент риска. Методы оценки риска».
4. NIST Special Publication 800-34 Rev. 1 «Contingency Planning Guide for Federal Information Systems».
5. NIST Special Publication 800-84 «Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities».
6. The Definitive Handbook of Business Continuity Management Second Edition Copyright © 2007 John Wiley & Sons Ltd.
7. Business Continuity Management How to protect your company from danger MICHAEL GALLAGHER Pearson Education Limited 2003.
8. www.bcmpedia.org/wiki/BCM_Body_of_Knowledge (BCMBoK).
Информация о проекте на сайте Softline: services.softline.ru/security/upravleniya-ib
Аннотация: Процессы и деятельности в рамках этапа Проектирования услуг: Управление непрерывностью услуг и информационной безопасностью в рамках этапа Проектирования. Управление поставщиками. Для каждого процесса рассматривается цель, входы и выходы, основные деятельности и ключевые показатели эффективности.
6.1. Управление непрерывностью услуг
Управление непрерывностью услуг (IT Service Continuity Management или ITSCM) — процесс, ответственный за управление рисками, которые влияют на услуги. ITSCM обеспечивает возможность поставщику услуг постоянно предоставлять минимально согласованный Уровень услуг, через снижение рисков до приемлемого уровня и Планирование восстановления услуг[1].
Основная цель Управления непрерывностью услуг (далее просто Управление непрерывностью) — поддерживать процесс Управления непрерывностью бизнеса. Управление непрерывностью бизнеса (Business Continuity Management или BCM) — бизнес-процесс, отвечающий за управление рисками, которые могут серьезно повлиять на бизнес. BCM защищает интересы ключевых заинтересованных сторон, репутацию, бренд и деятельность по созданию ценности. Процесс BCM включает в себя снижение рисков до приемлемого уровня и планирование способов восстановления бизнес-процессов в случае нарушения бизнеса. BCM устанавливает цели, охват и требования по отношению к Управлению непрерывности ИТ-услуг[1].
В настоящее время технологии являются основным компонентом многих бизнес процессов, поэтому обеспечение их непрерывности и доступности является необходимым для существования бизнеса в целом. ITSCM управляет способностью услуг и их компонентов к восстановлению.
Промежуточные цели ITSCM:
- управление набором Планов обеспечения непрерывности услуг и Планов восстановления услуг, которые являются частью Планов обеспечения непрерывности бизнеса. План обеспечения непрерывности услуг (IT Service Continuity Plan) — план, определяющий шаги, необходимые для восстановления одной или нескольких услуг. План также должен определять события, которые являются основанием для его инициации, людей, которые должны быть задействованы, средства коммуникаций и т.п.
План обеспечения непрерывности бизнеса (Business Continuity Plan или BCP) — план определяет шаги, необходимые для восстановления бизнес-процессов в случае нарушения их функционирования. План также должен содержать информацию о событиях, которые являются основанием для его инициирования; людях, которые должны быть задействованы в реализации плана; средствах коммуникаций и т.п.[1]
- завершение Анализа влияния на бизнес в части гарантии управления планами обеспечения непрерывности в соответствии с изменяющимися требованиями и потребностями бизнеса;
- сопровождение Анализа рисков и менеджмента, в частности при взаимодействии с бизнесом и процессами Управления доступностью и Управления безопасностью, которые управляют услугами в соответствии с согласованным Уровнем услуг;
- предоставление рекомендаций и руководств другим областям IT в вопросах, связанных с непрерывностью и восстановлением услуг;
- обеспечение механизмов непрерывности и восстановления, которые позволят достигнуть целевых показателей, установленных бизнесом;
- оценка влияния изменений на Планы обеспечения непрерывности услуг и Планы восстановления услуг;
- проактивное улучшение непрерывности услуг там, где это экономически эффективно;
- ведение переговоров и заключение контрактов с поставщиками об обеспечении необходимой способности к восстановлению в целях поддержки непрерывности (с участием процесса Управления поставщиками)[10].
Управление непрерывностью фокусируется на значимых негативных событиях, которые ITIL называет «катастрофами» для бизнеса. Менее значимые события рассматриваются в рамках процесса Управления инцидентами. То, является ли какое-то конкретное событие катастрофой, зависит от организации, в которой оно произошло. Размер и значимость негативного влияния события на бизнес, например, финансовые потери или потеря репутации, измеряется в рамках Анализа влияния на бизнес. Анализ влияния на бизнес определяет минимальные требования к критичности, конкретные требования к технологиям и услугам определяются в рамках Управления непрерывностью.
ITSCM главным образом рассматривает активы IT и конфигурации, которые поддерживают бизнес-процессы. В случае катастрофы бизнесу необходимо перестроиться на альтернативную рабочую локацию. При этом необходимо предоставить такие элементы как удобство офиса для персонала, копии критических бумажных отчетов, услуги курьеров и телефонную связь для связи с клиентами и партнерами. В этой связи Управление непрерывностью должно учитывать количество и месторасположение офисов организации, а также услуги, предоставляемые в каждом из них.
В рамках Управления непрерывностью должны выполняться следующие деятельности:
- Согласование границ ITSCM и применяемых политик;
- Анализ влияния на бизнес для количественной оценки влияния потери услуги на бизнес;
- Анализ рисков — идентификация и оценка рисков с целью определения потенциальных угроз непрерывности и оценки вероятности их осуществления. Сюда также входит применение механизмов управления угрозами там, где это экономически эффективно;
- формирование стратегии ITSCM, интегрированной в стратегию BCM.
- формирование Планов обеспечения непрерывности, интегрированных в планы BCM.
- Тестирование планов обеспечения непрерывности;
- Непрерывное осуществление планов и управление ими.
На рис. 6.1 показан жизненный цикл ITSCM.
Рис.
6.1.
Жизненный цикл ITSCM
ITSCM циклически повторяется на всем жизненном цикле услуги и гарантирует то, что однажды разработанные планы по восстановлению и обеспечению непрерывности услуг будут соответствовать в дальнейшем приоритетам бизнеса и Планам обеспечения непрерывности бизнеса. На рис. 6.1 также показана роль BCM в ITSCM.
Стадии инициализации и формирования требований относятся к BCM. ITSCM должен только участвовать в этих стадиях, чтобы поддержать BCM и понять связи между бизнес-процессами и влияние потери услуг на них. В результате этих начальных стадий BCM формирует Стратегию обеспечения непрерывности бизнеса. Для ITSCM первой серьезной задачей становится сформировать свою стратегию, которая сделает возможной и поддержит Стратегию непрерывности бизнеса. Рассмотрим стадии жизненного цикла ITSCM.
Стадия 1 — Запуск
Эта стадия ITSCM состоит из следующих действий:
- формирование политики обеспечения непрерывности — должно быть осуществлено как можно быстрее. Политика, как минимум, должна определять цели и моменты и вопросы, на которые менеджмент должен обратить внимание;
- определение терминов охвата и компетенции — определение границ ITSCM и распределение ответственности для всего персонала в организации;
- распределение ресурсов — формирование окружения для обеспечения непрерывности бизнеса, требующего значительных ресурсов как денежных, так и людских.
- определение проекта для организации процесса ITSCM и структуры его контроля — ITSCM и BCM являются сложными процессами, требующими тщательной организации и контроля.
- согласование проекта и планов качества — планы обеспечивают контроль проекта и его применимость для различных ситуаций.
Стадия 2 — Требования и стратегия
Установление требований бизнеса к непрерывности услуг является критически важным, так как именно от этого этапа зависит устойчивость организации к катастрофам и соответствующие затраты. Если требования некорректны или пропущена какая-то важная информация, все механизмы ITSCM будут неэффективны. Эта стадия разделяется на две подстадии:
- требования — Анализ влияния на бизнес и оценка рисков
- стратегия — стратегия формулирует меры уменьшения риска и опции восстановления.
Анализ влияния на бизнес (Business Impact Analysis или BIA) — деятельность в рамках процесса Управления непрерывностью бизнеса, которая определяет критичные бизнес-функции и их зависимость от факторов окружения. Этими факторами могут быть поставщики, люди, другие бизнес-процессы, услуги и т.д[1]. BIA определяет последствия потери услуг для бизнеса. Потери могут быть значительными, например, крупные финансовые потери, и «мягкими» — моральные потери, потеря репутации, конкурентного преимущества и т.п.
Анализ влияния на бизнес определяет:
- форму, которую может приобретать разрушение или потеря, например:
- потерянный доход;
- дополнительные затраты;
- вред репутации;
- потеря благосклонности клиентов;
- потеря конкурентного преимущества;
- повреждение и нарушение здоровья, законности и безопасности;
- риск безопасности персонала;
- потеря рынка сбыта в краткосрочном и долгосрочном периодах;
- потеря операционных возможностей, например, контроля.
- как будут увеличиваться негативные последствия разрушения или потери после неблагоприятного события, а также время суток, недели, месяца, когда они будут наиболее серьезными;
- кадровое обеспечение, навыки, аппаратура и услуги, которые необходимы для поддержки минимальных уровней непрерывности критичных бизнес-процессов;
- временные рамки, в пределах которых необходимо обеспечить минимальный уровень восстановления кадрового обеспечения, аппаратуры, услуг и других возможностей;
- временные рамки, в пределах которых необходимо полностью восстановить критичные бизнес-процессы и поддерживающие их кадровое обеспечение, аппаратуру, услуги и другие возможности;
- приоритеты восстановления для услуг.
Одним из основных выходов BIA является построение диаграммы оценки влияния потери услуги или бизнес-процесса на бизнес в целом (рис. 6.2).
Анализ влияния на бизнес предоставляет базис для осуществления ITSCM. На основе анализа формируется перечень услуг, приложений и других компонентов, которые станут предметами рассмотрения ITSCM.
Второй этап определения требований для ITSCM заключается в оценке вероятности возникновения неприятных событий.
Оценка рисков (Risk Assessment) — начальные шаги Управления рисками. Анализируется ценность активов для бизнеса, идентифицируются угрозы по отношению к этим активам, и оценивается уязвимость активов по отношению к этим угрозам[1].
Для оценки рисков и управления ими применяется стандартная методология M_o_R (Management of Risks), которая состоит из следующего:
- принципы M_o_R — базируются на принципах управления организацией и являются необходимыми для эффективного управления рисками;
- подход M_o_R — подход организации к указанным выше принципам должен быть отображен в ряде документов, в частности, в Политике управления рисками.
- процессы M_o_R. Выделяют четыре процесса в рамках M_o_R:
- Определение — определение угроз для деятельности, которые могут повлиять на достижение ею намеченного результата;
- Оценка — оценка суммарного влияния всех определенных угроз;
- Планирование — определение набора управленческих действий, которые уменьшат риски;
- Реализация — осуществление запланированных управленческих действий, их контроль, определение эффективности и корректирование в случае необходимости.
- пересмотр и внедрение M_o_R — внедрение процессов, политик и подхода M_o_R так, чтобы они непрерывно контролировались и оставались эффективными;
- взаимодействие — обеспечение взаимодействия всех действий в рамках M_o_R с целью поддержки актуальности информации об угрозах, возможностях и других аспектах Управления рисками.
Об услуге
Качественный мониторинг событий и расследование инцидентов ИБ является неотъемлемой частью киберзащиты любой инфраструктуры. Эксперты Angara Technologies Group предлагают полный набор услуг по созданию и развитию систем управления инцидентами ИБ.
Тимур Зиннятуллин
Директор Центра киберустойчивости
Актуально, если
1
В компании отсутствует организация процесса качественного и оперативного выявления угроз и управления инцидентами информационной безопасности, которые фундаментально повышают уровень защищенности бизнеса
2
Процесс реагирования на инциденты в построенном SOC не происходит в соответствии с лучшими мировыми практиками
3
Необходимо контролировать эффективность функционирования средств и механизмов защиты
Какие задачи решаем
Разрабатываем и автоматизируем метрики эффективности ИБ-процессов и СЗИ
Решаем проблемы, связанные с автоматизацией выявления угроз, обогащением данных в SIEM-системах для расследования, тюнингом существующих систем мониторинга
Осуществляем методологическое сопровождение центра мониторинга
Проводим безопасное тестирование существующей системы защиты методом контролируемого взлома
Создание и развитие центров мониторинга и реагирования на инциденты ИБ
Подробнее
Обогащение процессов ИБ сторонней аналитикой
Подробнее
Разработка сценариев выявления и реагирования на угрозы
Подробнее
Security Intelligence как визуализация и контроль метрик эффективности
Подробнее
Методологическое сопровождение SOC
Подробнее
Получить консультацию
Другие услуги
Актуальное
Управление инцидентами информационной безопасности и непрерывностью бизнеса, учебное пособие для вузов, Милославская Н.Г., Сенаторов М.Ю., Толстой А.И., 2014.
В учебном пособии изучается процесс управления инцидентами информационной безопасности (ИБ), для чего вводятся понятия события и инцидента ИБ и выделяются цели и задачи управления инцидентами ИБ. Описывается система управления инцидентами ИБ. Анализируются этапы процесса управления инцидентами ИБ. Исследуются подпроцессы обнаружения событий и инцидентов ИБ и оповещения о них; обработка событий и инцидентов ИБ, включая первую оценку и предварительное решение по событию ИБ и вторую оценку и подтверждение инцидента ИБ; реагирования на инциденты ИБ. Описывается документация системы управления инцидентами ИБ, включая политику и программу. Анализируется деятельность группы реагирования на инциденты ИБ. Значительное внимание уделяется сохранению доказательств инцидента ИБ. Далее вводятся определения непрерывности бизнеса, управления ею и системы управления непрерывностью бизнеса (УНБ). Рассматривается применение цикла PDCA к этой системе управления. Детально описывается жизненный цикл УНБ. Определяется состав документации в области непрерывности бизнеса, в частности, политика УНБ и планы управления инцидентом, обеспечения непрерывности и восстановления бизнеса. Анализируются готовность информационных и телекоммуникационных технологий (ИТТ) к обеспечению непрерывности бизнеса (ОНБ) и интеграция процессов готовности ИТТ и ОНБ в рамках цикла PDCA.
Для студентов высших учебных заведений, обучающихся по программам магистратуры направления 090900 — «Информационная безопасность», будет полезно слушателям курсов переподготовки и повышения квалификации и специалистам.
1. НОРМАТИВНАЯ БАЗА УПРАВЛЕНИЯ ИНЦИДЕНТАМИ ИБ И ОБЕСПЕЧЕНИЕ НЕПРЕРЫВНОСТИ БИЗНЕСА.
Для наиболее эффективной разработки процессов управления инцидентами ИБ и ОНБ необходимо руководствоваться требованиями международных и российских стандартов.
К настоящему времени разработано достаточное количество нормативных документов, регламентирующих вопросы управления инцидентами ИБ и ОНБ как в рамках обеспечения ИБ (ОИБ), так и при управлении ИТ-сервисами в целом. К ним можно отнести следующие документы.
1. Международный и национальный стандарты ISO/IEC 27001:2005 и ГОСТ Р ИСО/МЭК 27001:2005 устанавливают требования к СУИБ в целом, а также отдельно к процессу управления инцидентами ИБ [1, 2]. Данные стандарты обращают особое внимание на необходимость создания процесса управления инцидентами ИБ и поддерживающей его работу документации, необходимой для регулирования и управления работой в рамках разработанного процесса и определения обязанностей и необходимых действий сотрудников.
2. Национальный стандарт ГОСТ Р ИСО/МЭК 18044-2007 [3], идентичный отмененному в настоящее время международному стандарту ISO/IEC TR 18044:2004 [4] в связи с его заменой стандартом 1SO/IEC 27035:2011 [5], описывает инфраструктуру управления инцидентами ИБ в рамках циклической модели PDCA, дает подробные спецификации для стадий планирования, эксплуатации, анализа и улучшения процесса и рассматривает вопросы обеспечения нормативно-распорядительной документацией и ресурсами и рекомендации по необходимым процедурам.
ОГЛАВЛЕНИЕ.
Предисловие.
Введение.
1. Нормативная база управления инцидентами ИБ и обеспечение непрерывности бизнеса.
2. Управление инцидентами ИБ.
3. Управление непрерывностью бизнеса организации.
Заключение.
Приложения.
Список литературы.
Бесплатно скачать электронную книгу в удобном формате, смотреть и читать:
Скачать книгу Управление инцидентами информационной безопасности и непрерывностью бизнеса, учебное пособие для вузов, Милославская Н.Г., Сенаторов М.Ю., Толстой А.И., 2014 — fileskachat.com, быстрое и бесплатное скачивание.
Скачать djvu
Ниже можно купить эту книгу по лучшей цене со скидкой с доставкой по всей России.Купить эту книгу
Скачать
— djvu — Яндекс.Диск.
Дата публикации: 19.03.2020 18:03 UTC
Теги:
информация :: безопасность :: бизнес :: Милославская :: Сенаторов :: Толстой :: 2014
Следующие учебники и книги:
- Искренний сервис, Недякин М., 2014
- Из офисной мышки-в миллионерши, Как зарабатывать, не выходя из дома, Реальный опыт, Пряхина Ю., 2016
- Управление мировоззрением, развитый социализм, зрелый капитализм и грядущая глобализация глазами русского инженера, Белок В., 2009
- Управление качеством, Шевчук Д.А.
Предыдущие статьи:
- Управление гостиничным предприятием, Вакуленко Р., Кочкурова Е.А., 2008
- Деньговодство, Руководство по выращиванию ваших денег, Смирнова Н.Ю., 2020
- Управление в эпоху кризиса, как сохранить ключевых людей и компанию, Адизес И., 2015
- Суперпотребители, кто это и почему они так важны для вашего бизнеса, Юн Э., 2017
Зачем нужно управлять безопасностью?
Организации создают, собирают и хранят огромные объемы информации от клиентов и партнеров: поведенческую аналитику, личную информацию, данные о кредитных картах и платежах и другое. Увеличение объема корпоративных данных приводит к росту кибератак и количеству утечек. В качестве контрмеры стремительно развивается область управления информационной безопасностью.
Каждый бизнес-процесс, основанный на технологиях, подвержен угрозам безопасности. Сложные решения для кибербезопасности способны противостоять атакам, угрозам и новым методам хакеров, но этого недостаточно. Организации должны гарантировать, что процессы, политики и сотрудники минимизируют риски.
Здесь на помощь приходят системы управления информационной безопасностью. Независимо от метода хранения данных (в цифровом или физическом формате), управление информационной безопасностью имеет решающее значение для защиты данных от несанкционированного доступа и кражи. Оно:
- описывает набор политик и процедурных средств контроля, которые внедряются для защиты корпоративных активов от рисков и угроз;
- включает изучение рисков, обеспечение соответствия, консультационные услуги по безопасности и управлению.
Система управления информационной безопасностью
Система управления информационной безопасностью – это структура политик и средств контроля, которые систематически управляют безопасностью и рисками в масштабах предприятия. Меры безопасности могут соответствовать общим стандартам безопасности или быть более ориентированными на конкретную отрасль. Организациям из строго регулируемых отраслях (как здравоохранение или финансы) может потребоваться широкий спектр действий по обеспечению безопасности и стратегий снижения рисков.
Компаниям нужно иметь четкую структуру обеспечения кибербезопасности для интеграции в нее управления безопасностью. Используя структуру в качестве ориентира, организации получат полное представление о рисках для безопасности. Может адаптировать существующую структуру информационной безопасности в соответствии с потребностями или разработать ее внутри компании.
Система управления кибербезопасностью содержит набор инструментов, комплексный подход к управлению рисками и программу повышения осведомленности сотрудников. Эта структура должна быть полностью интегрирована в ключевые системы и процессы организации и включать:
- аварийное восстановление, планирование, оценку рисков и отслеживание непрерывности бизнес-процессов;
- выявление, оценку, снижение и мониторинг рисков поставщиков с отчетами и аналитикой;
- оптимизированный подход к управлению рисками и их снижению;
- отслеживание ряда норм и стандартов для соответствия нормативным требованиям.
Средства контроля и оценки рисков
Управление рисками решающее значение для обнаружения и предотвращения угроз на начальном этапе, чтобы не устранять причиненный ими ущерб. Система управления кибербезопасностью обязательна в цифровую эпоху. Средства управления информационной безопасностью используют следующие компоненты:
Безопасность человеческих ресурсов. Политики и средства контроля, относящиеся к сотрудникам, деятельности и человеческим ошибкам, включая меры по снижению риска от внутренних угроз и обучение работников для уменьшения непреднамеренных нарушений в безопасности.
Информационная безопасность и управление инцидентами. Выявление и решение ИТ-проблем с минимизацией воздействия на конечных пользователей. Передовые технологические решения предоставляют точные показатели инцидентов и смягчают потенциальные проблемы.
Коммуникации и управление операциями. Системы должны эксплуатироваться с соблюдением и поддержанием политик безопасности и контроля.
Контроль доступа. Ограничение доступа авторизованного персонала и мониторинг сетевого трафика на предмет аномального поведения. Роли и обязанности отдельных лиц четко определяются, а доступ к деловой информации предоставляется только в случае необходимости.
Криптография. Системы управления информационной безопасности регулируют порядок применения и управления криптографическими средствами контроля.
Организация информационной безопасности. Устраняет угрозы и риски в корпоративной сети, включая кибератаки со стороны внешних объектов, внутренние угрозы, сбои в работе системы и потерю данных.
Отношения с поставщиками. Сторонним поставщикам и деловым партнерам может потребоваться доступ к сети и конфиденциальным данным клиентов. Следует принять адекватные меры контроля для снижения потенциальных рисков с помощью политик безопасности ИТ и договорных обязательств.
Политики информационной безопасности. Общее руководство и поддержка помогают установить соответствующие политики безопасности. Политика безопасности уникальна для вашей компании и разработана в контексте меняющихся потребностей.
Приобретение, разработка и обслуживание информационных систем. Передовые методы безопасности следует поддерживать на протяжении всего жизненного цикла ИТ-системы, включая этапы приобретения, разработки и обслуживания.
Согласие. Требования безопасности должны соблюдаться регулирующими органами.
Управление активами. Охватывает активы организации внутри и за пределами корпоративной ИТ-сети, что может включать обмен конфиденциальной информацией.
Управление непрерывностью бизнеса. Процессы по восстановлению систем и процедуры по минимизации ущерба.
Физическая и экологическая безопасность. Меры безопасности для защиты физического ИТ-оборудования от повреждения, потери или несанкционированного доступа.
Перечисленные компоненты предлагают общие передовые практики для надежной информационной безопасности. Решения для управления и соблюдения нормативных требований помогут предприятиям достичь высокого уровня защиты.
Способы защиты от киберугроз
Информационные активы, требующие защиты, включают стратегическую документацию, информацию о продуктах и услугах, интеллектуальную собственность, коммерческую тайну, проектную документацию, данные о сотрудниках. Неспособность же защитить данные клиентов приведет к недоверию и даже судебным разбирательствам.
Для обеспечения конфиденциальности, целостности и доступности бизнес-данных разработаны средства управления информационной безопасностью.
Физические и программные средства препятствуют проникновению злоумышленников в корпоративную сеть. Методы защиты от рисков и киберугроз включают мониторинг защищаемой системы, маскирование данных с использованием криптографии, регулирование комплекса мер по работе с данными, обеспечение соблюдения. Организационно-технические средства – основные способы реализации методов.
Организационные средства защиты:
- Интеграция программных продуктов для защиты данных от копирования или уничтожения любым пользователем.
- Проведение инструктажа и периодических проверок персонала.
- Разграничение обязанностей и проверку доступов.
- Разработка планов восстановления системы в случае сбоя.
- Разработка внутренней документации по работе с компьютерной техникой и конфиденциальной информацией.
Технические средства защиты:
- Обеспечение безопасности от пожара или повреждения водой.
- Обеспечение систем резервного электроснабжения.
- Обеспечение удаленного хранения важных файлов компьютерной системы.
- Оснащение помещений камерами видеонаблюдения и сигнализацией.
- Перераспределение сетевых ресурсов при выходе из строя отдельных элементов.
- Регулярное резервное копирование всех сетевых подсистем.
Установка передовых продуктов для защиты данных от несанкционированного доступа.
Решения для мониторинга и управления ИБ
Специализированные решения позволят организациям предвидеть и минимизировать киберриски, угрозы, уязвимости и многочисленные требования соответствия. Решения оптимизируют усилия по кибербезопасности для достижения киберустойчивости, позволяя компаниям обеспечивать непрерывность бизнеса и аварийное восстановление.
Компания CloudNetworks занимается реализацией технических средств, которые позволяют повысить качество процессов управления информационной безопасности через контроль всех процессов внутренних сетей. Ознакомиться подробнее можно на страницах решений:
- EDR — обнаружение и реагирование на угрозы конечной точки
Endpoint Detection and Response (EDR) относительно новая технология, решающая проблему постоянного мониторинга и реагирования на сложные угрозы. С ее помощью осуществляется мониторинг событий конечной точки и сети. Информация записывается в центральную базу данных, где происходит дальнейший анализ и составление отчетности.
- PIM/PAM/PUM — контроль привилегированных пользователей
PAM-система – самая быстрорастущая область кибербезопасности и решений по управлению рисками. Она предоставляет строгую аутентификацию пользователей, то есть контроль доступа к паролям, службам и учетным записям.
- SIEM — управление событиями и инцидентами ИБ
SIEM автоматически находит корреляции между данными и помогает защитить систему от киберугроз. Включите исторический анализ в вашу стратегию безопасности. Решение SIEM даст аналитикам свободу и возможность сосредоточиться на более насущных проблемах.
- SOC, CERT — решения для построения центров управления безопасностью
Центр безопасности операций (SOC) отвечает за постоянный, оперативный компонент информационной безопасности предприятия. Группа реагирования на компьютерные инциденты (CERT) работает для обнаружения, анализа, реагирования, составления отчетов и предотвращения инцидентов кибербезопасности.
- Security Awareness — программы повышения осведомленности
Создайте крепкий барьер от хакеров с помощью осведомленных сотрудников. Сегодня ни один поставщик услуг не может гарантировать 100% полную киберзащиту. Пройдя программы повышения осведомленности, ваши сотрудники станут надежной защитой компании. Программы обучения сотрудников позволят привить индивидуальную ответственность за политику безопасности компании, а также доработать меры по аудиту этих усилий.
- Threat Intelligence — киберразведка
Получайте информацию об угрозах, включая контекст, механизмы, индикаторы, последствия и ориентированные на действия рекомендации относительно существующей или возникающей угрозы, или опасности для активов. Этот интеллект может использоваться для принятия решений относительно реакции субъекта на эту угрозу или опасность. Киберразведка повысит ценность функций безопасности для организаций всех размеров.
- UAM — мониторинг действия пользователей
Цель мониторинга активности пользователей – это защита информации при обеспечении доступности и соблюдения требований конфиденциальности и безопасности данных. Решение для мониторинга активности пользователей позволит отслеживать рабочее поведение сотрудников и предупреждать администратора при обнаружении любых угроз безопасности.
- Vulnerability Scanners — аудит и анализ защищенности
Сканеры уязвимостей – это инструменты, которые постоянно отслеживают приложения и сети для выявления уязвимостей безопасности. С помощью систем анализа можно просканировать всю корпоративную сеть для выявления уязвимостей, ошибок конфигурирования, ухода от корпоративных и мировых стандартов и практик.
- UEBA, User and Entity Behavior Analytics — системы поведенческого анализа
Система поведенческого анализа даст вам более комплексную и первоклассную ИТ-безопасность, а также поможет выявить пользователей и организации, которые могут поставить под угрозу всю вашу систему. UEBA представляет собой тип процесса кибербезопасности, который учитывает нормальное поведение пользователей.
Оставьте заявку на получение консультации
Истории успеха
Задача:
Требовались технические сервисы для поддержки и защиты конечных точек компании.
Продукт:
Check Point.
Результаты:
Поставлены устройства на все субъекты, а также предоставлены сервис и техническая поддержка по межсетевым экранам на все представительства компании, включая предприятия в Сибири
и Харабовском крае.
Задача:
Требовалась платформа для администрирования приложений на разных устройствах.
Продукт:
VMware Workspace ONE.
Результаты:
Была установлена аналитическая платформа VMware Workspace ONE на 500 устройствах заказчика для контроля приложений и удобного, безопасного предоставления приложений на любом устройстве.
Задача:
Требовалась защита периметра ИТ-инфраструктуры.
Продукт:
Cisco Firepower.
Результаты:
Был реализован проект в крупнейшем российском энергетическом холдинге по защите периметра сети на основе решений Cisco Firepower. Защищен периметра от сетевых атак, проведена проверка трафика на наличие вредоносного кода
и установлено межсетевое экранирование.
Дополнительные материалы
6 лет на рынке ИБ
Более 100 проектов
65 + партнеров
Cloud Networks – это компания, предоставляющая услуги в области системной интеграции, облачном консалтинге, автоматизации процессов и бизнес-аналитике.
Основной деятельностью компании является обеспечение информационной безопасности и защита данных, а также внедрение информационных технологий для эффективной работы бизнеса.