Первая часть. Данная статья является вольным переводом работы Фотиса Кициос, Эльпиники Хацидимитриу и Марии Камариоту.

4. Методология

Была разработана стратегическая структура для поддержки Венеры в разработке СМИБ. Рисунок 1 представляет процесс, используемый Венерой для внедрения и оценки СМИБ. На первом этапе компания установила правило безопасности и соответствующие меры и средства контроля. Затем он составил заявление о сфере его использования, объяснив, почему авторитеты были предпочтительнее других. Компания определила активы и требования, оценила риски и выбрала метод оценки. На втором этапе компания внедрила политику безопасности и соответствующие процедуры, внедрила средства контроля и управляла операциями. В ходе реализации третьего этапа этого процесса компания оценивала и измеряла эффективность и сообщала о результатах руководству. На последнем этапе компания предприняла соответствующие профилактические, прогнозирующие и улучшающие действия для поддержания и улучшения СМИБ.

Риск — это негативное влияние любой уязвимости и угрозы, которые могут возникнуть в информационных системах и активах Венеры. Управление рисками — это систематическая идентификация, оценка и реализация шагов и действий по снижению рисков до приемлемого уровня. В следующих нескольких параграфах мы определяем и оцениваем методологию оценки и обработки информационных рисков для определения адекватного уровня риска в соответствии с соответствующими стандартами безопасности (ISO/IEC 27001: 2013), а также предоставляем рекомендации по разработке эффективного управления рисками. программа в рамках инфраструктуры Венеры.

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

Управление рисками — это процесс в структуре СМИБ компании, предназначенный для систематической идентификации, оценки и обработки рисков, а также для обеспечения приемлемого уровня информационной безопасности в рамках СМИБ. Целями оценки рисков и обработки рисков в контексте информационной безопасности являются следующие: разработка четкого распределения обязанностей, разработка последовательных методов выявления рисков, идентификация рисков, четкое документирование рисков с их оценкой, внедрение более эффективных мер безопасности в информационные системы Венеры; лучшие решения по оценке рисков; предоставление информации для экономичных мер безопасности; разработка физических, процедурных и технических правил, согласованных с владельцами информационных активов; и эффективное управление рисками.

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

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

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

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

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

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

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

5. Результаты

5.1. Процесс оценки рисков

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

Риски, связанные с информационными системами, информацией и операциями Венеры, можно разделить на следующие категории; любой пользователь может определить угрозы, относящиеся к исследуемым активам. Был задокументирован исчерпывающий список событий, которые могут помешать или задержать достижение бизнес-целей Венеры. Риск, не включенный в этот список, может не быть оценен и уменьшен. Угрозы из существующих репозиториев могут быть добавлены после соответствующих поисков. Для рассмотрения и оценки было реализовано четкое описание рисков. Наконец, идентификация рисков включала потенциальное воздействие на информационные системы и активы. Любой потенциальный риск, который мог повлиять на конфиденциальность, целостность и доступность информационных систем, информации, операций и активов, документировался в процессе оценки рисков. Критерии оценки риска были установлены, чтобы обеспечить общее понимание этих мер безопасности, которые минимизировали потенциальное воздействие до приемлемого уровня. Уровень ущерба и стоимость, вызванная угрозой, определяли критерии воздействия. В таблице 2 представлены критерии воздействия, которые были определены.

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

Шаги, которые привели к реализации оценки риска, включали следующие действия: идентификация угрозы, идентификация уязвимости, контрольный анализ, определение вероятности, анализ воздействия, определение риска, рекомендации по контролю и результаты из документации. В первом упражнении оценивалась вероятность возникновения потенциальной угрозы. Вероятность угрозы (уровень угрозы) описывалась как вероятное появление события. При установлении вероятности угрозы Венера должна была учитывать причины угрозы, возможную восприимчивость и существующие средства контроля. Во втором упражнении анализ угрозы информационной системе включал анализ уязвимостей, связанных с окружением Венеры, — оценку уровней уязвимости для сценария угрозы. Прикладные элементы управления были протестированы. Следующий, были рассмотрены реализованные средства управления, и они попытались свести к минимуму или исключить вероятность угрозы, которая может возникнуть из-за уязвимости системы. Во время четвертого действия Венера учитывала следующие существенные факторы: воздействие (природного) источника угрозы, наличие и эффективность текущих средств контроля. Вводилась вероятность возникновения угрозы, а выходными данными вероятности события для конкретной угрозы были уровень угрозы и уровень восприимчивости. В пятом упражнении влияние события безопасности было описано с точки зрения потери конфиденциальности, целостности и доступности. Затем вероятность возникновения и значения воздействия были объединены для оценки уровня риска каждого актива для выявленной угрозы. Адекватность запланированных и существующих мер безопасности компании также была включена для оценки уровня риска. Во время седьмого действия меры безопасности, которые могли смягчить и устранить выявленные риски, были согласованы с операциями. Рекомендуемые средства контроля должны были обеспечивать поддержание уровня риска на управляемом уровне. Наконец, после того, как оценка риска была завершена, результаты были задокументированы в официальном отчете. Уровни риска были оценены по установленным критериям, и были приняты соответствующие меры. результаты были задокументированы в официальном отчете. Уровни риска были оценены по установленным критериям, и были приняты соответствующие меры. результаты были задокументированы в официальном отчете. Уровни риска были оценены по установленным критериям, и были приняты соответствующие меры. На рисунке 2 представлена ​​блок-схема действий, выполняемых в процессе оценки риска.

В случае риска необходимо было оценить соответствующие последствия для каждой уязвимости и угрозы отдельно для отдельного актива. Вероятность такого риска необходимо было оценить для каждого из активов Венеры. Серьезность риска представляла собой общую оценку как того, насколько вероятно, что это произойдет (вероятность), так и того воздействия, которое оно окажет, если оно произойдет (воздействие). Потенциальная уязвимость и/или угроза была описана как (почти определенная, вероятная, возможная, маловероятная, редкая). Последствия инцидента безопасности определялись с точки зрения потери конфиденциальности, целостности и доступности. Количественная оценка воздействия была основана на NIST SP 800-30, редакция 1. Уровень риска был основан на NIST SP 800-30, редакция 1. В таблице 3 представлены уровни вероятности и частоты, а также в таблице 4 показаны уровни воздействия.

Для измерения признанного риска компания разработала шкалу риска и матрицу уровня риска. Окончательное измерение риска получается путем умножения рейтинга, присвоенного вероятности угрозы и эффекта угрозы. Полные рейтинги риска могут быть установлены на основе входных данных от групп вероятности угрозы и воздействия угрозы. Матрица уровня риска (таблица 5) представляет собой матрицу 5 × 15 вероятности угрозы (почти определенная, вероятная, возможная, маловероятная, редкая) и воздействия угрозы (высокая 1–5, средняя 1–5, низкая 1–5) и показывает, как определяются общие уровни риска. Определение этих уровней риска или оценок может быть субъективным. Основа для этого объяснения может быть выражена в терминах вероятности, присвоенной каждому уровню вероятности угрозы, и значения, присвоенного каждому уровню воздействия. Для каждого актива Венеры были назначены все возможные угрозы.

Шкала оценки уровней воздействия (с точки зрения конфиденциальности, целостности и доступности) была установлена ​​в виде 15-балльной оценочной шкалы от L1 до H5: L1, L2, L3, L4, L5, M1, M2, M3, M4, M5., Н1, Н2, Н3, Н4, Н5. Эти критерии основаны на ISO 27005. Шкала оценок для уровней вероятности установлена ​​в виде 5-балльной шкалы оценок: 0,20 — редкость, 0,40 — маловероятность, 0,60 — возможность, 0,80 — вероятность, 1,00 — почти наверняка. Лимит риска установлен на уровне 2,9.В таблице 5 представлена ​​матрица уровней риска. Матрица уровней риска с ее рейтингами представляет собой уровень риска, которому может подвергаться информационная система, актив и/или процесс Венеры при наличии известной восприимчивости и угрозы. В Таблице 6 показаны последствия, а в Таблице 7 представлены уровни последствий.

5.2. План обработки рисков

Ответ должен быть определен для каждого выявленного риска. Вероятность и воздействие риска являются основанием для рекомендаций о том, какие действия следует предпринять для снижения риска. Вариант обработки (меры безопасности) должен быть определен в соответствии с анализом затрат и результатов и соответствующими критериями воздействия. Обработка риска состояла из следующих четырех уровней: принятие, уменьшение, передача и удаление. На первом уровне принятие риска было зарезервировано для низкоприоритетных рисков, когда другие варианты обработки будут стоить больше, чем потенциальное воздействие. Чтобы снизить выявленный риск, все риски должны включать рекомендацию по средствам контроля и альтернативным решениям. Венера примет выявленный риск. На втором уровне смягчение рисков предполагало минимизацию вероятности и/или последствий риск-угроз и уязвимостей. Упреждающие меры против риска всегда более эффективны, чем восстановление ущерба, причиненного выявленным риском. Компания будет планировать и разрабатывать будущие средства контроля для устранения выявленного риска. На третьем уровне перенос риска влечет за собой перенос негативного эффекта угрозы или уязвимости. Передача риска третьей стороне (поставщикам) не устраняет угрозу или уязвимость. Другая сторона будет нести ответственность за обработку соответствующего риска. Венера перечислит все варианты передачи выявленных рисков другим организациям (например, страховым). На последнем уровне предотвращение риска включало в себя изменение аспектов общих бизнес-процессов или системной архитектуры для устранения угрозы — предотвращение риска путем прекращения связанной с ним деловой активности. Венера будет планировать и разрабатывать будущие средства контроля для устранения выявленного риска.

Были выбраны соответствующие цели контроля, чтобы снизить выявленные риски и свести к минимуму потенциальное воздействие на информационные системы Венеры. Средства управления безопасностью были выбраны и/или разработаны в соответствии с правилами из Приложения к ISO/IEC 27001:2013, чтобы гарантировать, что ни одно из них не будет упущено. Правила, выбранные для соответствующих угроз, были задокументированы.

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

6. Обсуждение

После проведения оценки рисков было выявлено 309 уникальных угроз. В конце оценки рисков было задействовано в общей сложности 309 наборов средств контроля (по одному набору для каждой угрозы: для снижения выявленных рисков и сведения к минимуму потенциального воздействия на информационные системы Венеры угрозе может потребоваться более одного средства контроля). В общей сложности 269 рисков были снижены до приемлемого уровня путем применения набора средств контроля к каждой угрозе. В общей сложности 198 угроз были снижены до приемлемого уровня с помощью уже имеющихся средств контроля до оценки риска, а 71 угроза нуждалась в дальнейшем лечении путем применения новых средств контроля или обновления уже существующих. Для 45 из 71 нам пришлось провести третий раунд внедрения контроля, так как второго оказалось недостаточно. Генеральный директор принял 32 риска, т.к. мы не смогли подать заявку, было передано 5 рисков,

При реализации возникали различные препятствия. Компании пришлось возложить задачу внедрения СМИБ на свои ресурсы. Ресурсы должны были заниматься управлением и внедрением СМИБ, и они должны были быть квалифицированными сотрудниками с глубоким знанием структуры и операций компании. Роль директора по информационной безопасности (CISO) возложили на директора по развитию, а роль ISM – на операционного менеджера. Проблема заключалась в том, что у этих двух ресурсов уже были назначены задачи, поэтому пришлось провести совершенно новую реструктуризацию, наняв новых сотрудников для поддержки оставшихся функций. Это добавило компании дополнительные расходы.

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

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

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

Как упоминалось выше, круг внедрения ИСО не замкнулся, так как внутренний аудит еще не состоялся. Мы твердо верим, что было бы интересно получить обновленную информацию о том, как заканчивается этот путь к ISO 27001. Каковы будут результаты проверки? Будут ли несоответствия? Несоответствиями считаются несоблюдение конкретных требований, неспособность предотвратить потери, несоблюдение процесса и неспособность успешно противостоять инциденту безопасности. Какова будет реакция компании?

Оценка рисков и обработка рисков заняли более 11 месяцев и должны были быть завершены 16 версий. Это добавило сложности и задержки в процессы компании, и аудит был отложен. Кроме того, указывая на соответствие ISO 27001, процесс является постоянным источником изменений внутри организации; таким образом, это влияет на управление изменениями в компании. Будущие исследования могут столкнуться со всеми трудностями и сложностями этого отдельного отрезка жизни компании.

7. Выводы

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

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

Кроме того, быстрый рост компании показал, что стандартизированная модель информационной безопасности может сделать некоторые аспекты бизнеса более функциональными. Более того, стало ясно, что быстрый рост сделает компанию мишенью для киберугроз. Это стало целью для компании приступить к более подробной и расширенной политике информационной безопасности. Традиционный способ обеспечения информационной безопасности не был устойчивым в быстрорастущей компании. Риски, связанные с человеческими ошибками, увеличиваются по мере роста штата сотрудников компании. Наконец, компания продолжала получать один и тот же вопрос от многочисленных клиентов: «Почему мы должны доверять нашу информацию с вами?» С годами становилось все труднее возвращаться к клиентам с хорошо документированными доказательствами. Более того, клиенты стали менее терпимы к неопределенности информационной безопасности, и группа информационной безопасности больше не могла реагировать на потребности клиентов. Таким образом, эта статья стала итогом долгого пути внедрения ISO 27001 в компании. Однако процесс оценки рисков не является статичным, и его необходимо будет повторять.

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

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

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

Кроме того, будущие исследователи могут собрать больше информационных объектов для рисунка 2, проведя обзоры литературы и обсудив их со специалистами по рискам информационной безопасности. Некоторые информационные объекты, основанные на ISO 27005, могут отсутствовать в этой статье. Описание рисков может помочь компаниям в разработке оценки вероятности и влияния рисков на СМИБ. Кроме того, можно использовать другие инструменты для расширения угроз и уязвимостей компании с учетом условий, существующих в СМИБ. Однако этот документ можно рассматривать как отправную точку для людей, которые участвуют в процессе оценки СМИБ и принятии решений в организации.

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