Перша частина. Ця стаття є вільним перекладом роботи Фотіс Кіціос, Ельпініки Хацидімітріу та Марії Камаріоту.

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, Н4, Н3, Н2, Н1)     Середній (М5, М4, М3, М2, М1)     Низький (L5, Н4, L3, L2, L1)

Втрата доступності, конфіденційності або цілісності надає значний, критичний та/або миттєвий вплив на фінансові потоки компанії, операції, функціональність, юридичні, договорні зобов’язання та/або репутацію компанії.   Втрата конфіденційності, доступності або цілісності може призвести до втрат та надати середній або незначний вплив юридичні, договорні зобов’язання та/або репутацію компанії.   Втрата конфіденційності, доступності або цілісності не впливає на фінансові потоки компанії, юридичні, договорні зобов’язання та/або репутацію компанії.

Для вимірювання визнаного ризику компанія розробила шкалу ризику та матрицю рівня ризику. Остаточний вимір ризику виходить шляхом множення рейтингу, наданого ймовірності загрози та ефекту загрози. Повні рейтинги ризику можуть бути встановлені на основі вхідних даних від груп ймовірності загрози та впливу загрози. Матриця рівня ризику (таблиця 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 – ймовірність, 100 – майже напевно. Ліміт ризику встановлено на рівні 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 можуть бути відсутніми в цій статті. Опис ризиків може допомогти компаніям у розробці оцінки ймовірності та впливу ризиків на СУІБ. Крім того, можна використовувати інші інструменти для розширення загроз та вразливостей компанії з урахуванням умов, що існують у СУІБ. Однак цей документ можна розглядати як відправну точку для людей, які беруть участь у процесі оцінки ЗМІБ та прийняття рішень в організації.

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