Гарантія якості — ITIL, Agile, NIST, ISO/IEC 27035. Управління інцидентами безпеки
Процеси управління інцидентами стосуються структурованого та організованого підходу, який застосовують організації для реагування та вирішення інцидентів, які впливають на нормальну роботу систем.
Гнучке управління інцидентами (Agile incident management) ще не готове до широкого впровадження, оскільки організації все ще не впевнені у використанні гнучких методологій для керування сценаріями в ІТ-організаціях. Більшість організацій зосереджуються на загальному підході під назвою «Управління ІТ-послугами» (ITSM), стандартах COBIT та ISO.
Якщо методологія Agile включена в процес управління інцидентом, він не тільки автоматизує прогрес життєвого циклу, а також зменшує швидкість ескалації інцидентів в організації. Гнучке керування інцидентами складається з таких кроків: Управління життєвим циклом, Збір даних, Асоціація, Опис і можливість адаптації.
З іншого боку, процес управління інцидентами ITIL складається з таких кроків, як Введення, Ідентифікація, Реєстрація,
Класифікація, Визначення пріоритетів, Первинна діагностика, Ескалація, Дослідження та Діагностика, Вирішення та Закриття.
ITIL відомий як найпоширеніший фреймворк у світі, який можна об’єднати з Agile-методологією, щоб отримати сучасну тактику управління інцидентами. Після застосування набору принципів Agile для виконання процесу «Планування» з Agile маніфестом Agile-менеджмент інцидентів може дати якісні результати.
Інцедент менеджмент у розробці
Це процес виявлення, аналізу та виправлення інцидентів, які виникають під час розробки програмного забезпечення відомі як дефекти або проблеми. Ви повинні це ідентифікувати, проаналізувати та виправити. Проблеми це дефекти функціональності програмного забезпечення. Зазвичай дефект, який ідентифікується під час тестування та валідації, коли фактичний результат тесту відрізняється. В результаті управління інцидентами можна застосовувати на всіх етапах життєвого циклу програмного забезпечення. Методологія Agile зосереджуємося на управлінні інцидентами у тестуванні програмного забезпечення.
Справа в тому, що програміст, під час проектування та створення програмного забезпечення може припуститися помилок.
Якщо фактичний результат відрізняється від очікуваного, тестування програмного забезпечення або продукту це призводить до дефекту.
Будь-яке відхилення від специфікації, зазначеної в документі з вимогами є дефект. Коли результат застосування програмного забезпечення або продукту не відповідає очікуванням кінцевого користувача або вимоги до програмного забезпечення, то це призводить до помилки або дефекту, ці дефекти чи помилки виникають через помилки в логіці або кодуванні, що призводить до збою, непередбачуваного або неочікуваного результату.
Ідея управління інцидентами полягає в тому, щоб забезпечити відстеження інцидентів під час процесу вирішення щоб отримати кінцевий результат, слід розподілити вільні ролі та обов’язки для моніторингу всього процесу управління інцидентами.
Давайте подивимося на деякі визначення проблем.
Помилка — це дія, яку виконує людина, що призводить до певного аспекту поведінки системи. Це неправильний синтаксис, неправильне обчислення значень або його розуміння програмних вимог і так далі.
Дефект — термін, який зазвичай використовують тестувальники. Коли тестер виявляє помилку чи проблему, це вважається дефектом.
Баг — дефект, виявлений тестером та прийнятий розробником. Процес виправлення усіх багів у системі називається фіксацією.
Інцидент — незапланована перерва. Це випадок, коли робочий стан діяльності перетворюється з робочого на несправний, система веде себе незаплановано. Проблема може спричинити більше одного інциденту. Інциденти потрібно вирішувати якомога швидше.
Звіт про інцедент
Звіт про інцидент повинен містити наступну інформацію для кожного інциденту:
Ід дефекту — кожна помилка чи дефект має свій унікальний ідентифікаційний номер
Опис дефекту — включає анотацію випуску. Опис інциденту за допомогою логів, скріншотів тощо
Версія продукта — включає версію програми, у якій виявлено дефект
Деталі кроків — cюди входять детальні кроки проблеми з доданими знімками екрана, щоб розробники могли її відтворити
Дата відкриття— інформація про дату повідомлення про помилку
Повідомив — включає інформацію про тестувальника, який повідомив про помилку, наприклад ім’я та ідентифікатор
Статус — поточний стан обробки інциденту, це поле містить статус дефекту, як-от Новий, Призначений, Відкритий, Повторний тест,
Перевірка, Закрито, Не вдалося, Відкладено тощо.
Виправлено - це поле містить відомості про розробника, який це виправив, наприклад ім’я та ідентифікатор
Дата закриття — це інформація про дату, коли помилку було виправлено
Серйозність — потенційний вплив інциденту, визначить його серйозність. На основі серйозності (фатальна, критична, серйозна або незначна) він повідомляє нам про вплив дефекту або помилки в програмному забезпеченні
Пріоритет — встановлений відповідно до серйозності та впливу на робочий стан системи. Значення можуть бути високим, середнім, низьким, дуже високим або терміновим/негайним. Порядок усунення дефекту залежить від пріоритету
Процес управління інцидентом
Управління інцидентами — це загальний процес, починаючи від реєстрації інцидентів до їх вирішення. Це дуже важливий процес, оскільки він має забезпечити належне виявлення та моніторинг інцидентів. Ефективне та належне впровадження цього процесу гарантує вирішення проблем у розумні терміни. Типовий процес управління інцидентами виглядає наступним чином
Управління інцидентами інформаційної безпеки є важливим процесом, який забезпечує організацію можливістю своєчасного виявлення інциденту та якомога швидшого реагування на нього за допомогою коректно обраних засобів підтримки.
Управління інцидентами відповідно до ITIL — один з процесів, який відповідає за управління життєвим циклом усіх інцидентів. Підхід ITIL визначає, що основна мета управління інцидентами — якнайшвидше відновлення послуги для користувачів. Управління інцидентами призначено для максимально швидкого відновлення нормальної експлуатації послуг та мінімізації несприятливого впливу на бізнес у разі виникнення інциденту.
Управління інцидентами цілком можна виконувати вручну або за допомогою статичних засобів таблиці, але це набагато ефективніше, динамічніше та систематичніше, коли виконується за допомогою інструменту. Система керування інцидентами використовується багатьма кол-центрами служби підтримки клієнтів для оновлення та вирішення інцидентів. Вони також використовуються на етапах тестування в процесі розробки програмного забезпечення інженерами-тестувальниками, розробниками та клієнтами.
Jira — популярний запатентований інструмент керування інцидентами, розроблений компанією Atlassian використовується для відстеження помилок, дефектів або інцидентів. Існують кілька аналогів Jira, які також надають схожі можливості:
- Asana: Це інструмент управління завданнями та проектами, який дозволяє створювати списки завдань, спільно працювати над проектами, призначати завдання тощо.
- Trello: Це інструмент управління завданнями, який використовує дошки та картки для організації завдань та проектів. Він дозволяє створювати списки, призначати завдання та контролювати їхній статус.
- Microsoft Planner: Це частина пакету Office 365, яка надає можливості для створення завдань, організації їх у списки та спільної роботи над ними.
- Monday.com: Ця платформа дозволяє створювати та керувати проектами, використовуючи дошки та різноманітні інструменти для спільної роботи.
Кожен з цих інструментів має свої унікальні особливості та можливості, але вони усі спрямовані на управління проектами та завданнями, що робить їх аналогами Jira у певних аспектах управління проектами.
Також існує кілька опенсорс аналогів Jira, які можуть бути використані для управління проектами та завданнями:
- Redmine: Це платформа управління проектами з відкритим кодом, яка дозволяє створювати завдання, ведення списків задач, керування версіями, та має широкий спектр плагінів.
- Trac: Це система управління проектами та bug-трекер з підтримкою Wiki. Вона надає можливості керування завданнями, відстеження помилок та інші корисні інструменти.
- GitLab: Відомий як система керування версіями, GitLab також має функціонал для управління проектами, відстеження задач та створення дошок для роботи над завданнями.
- OpenProject: Це опенсорсна система управління проектами, яка має можливості створення завдань, спільної роботи над проектами, планування, відстеження часу та інші функції управління проектами.
Ці опенсорсні альтернативи мають свої особливості та можливості. Вони можуть бути встановлені на власних серверах та модифіковані відповідно до потреб користувачів.
Кібербезпека — це складна сфера. Загрози кібербезпеки впливають на усі аспекти організації, що спонукає клієнтів до пошуку всеосяжного підходу до цієї проблеми. Тут на допомогу приходять стандарти, наприклад, NIST Cybersecurity Framework (CSF).
NIST CSF був створений з метою допомогти організаціям визначити їхній поточний рівень кібербезпеки, встановити бажаний стан, знайти області для покращень та інформувати всіх внутрішніх і зовнішніх учасників про ризики.
У цілому, структура складається з 5 функцій для управління загальними ризиками кібербезпеки для бізнесу:
- Ідентифікація: Які процеси та активи потребують захисту?
- Захист: Які заходи доступні для забезпечення безпеки?
- Виявлення: Які методи можуть ідентифікувати можливі інциденти?
- Реагування: Які методи можуть стримувати наслідки інцидентів?
- Відновлення: Які методи можуть відновити можливості після інциденту?
ITIL фокусується переважно на управлінні ІТ-послугами та покращенні загальної ефективності та результативності ІТ-сервісів. З іншого боку, NIST, зокрема його структура кібербезпеки, зосереджується на наданні директив та оптимальних практик для управління та підвищення кібербезпеки організації. Обидва ці підходи є цінними у своїх відповідних сферах, і організації часто використовують їх разом або спільно з іншими рамками для досягнення своїх цілей у галузі ІТ та кібербезпеки.
Приклад інтеграції двох підходів ITIL (GLPI) та NIST (Wazuh)
Інтеграція зі сканером уразливостей з відкритим вихідним кодом, може перетворити GLPI на інтегровану консоль для перевірки безпеки активу: тепер ви отримуєте всю інвентарну інформацію для активу, історичну інформацію та інформацію про вразливості. Ви також можете отримувати в режимі реального часу інформацію про стан антивірусу тощо.
Антивірус із відкритим вихідним кодом може надсилати сповіщення Wazuh SIEM, який зможе агрегувати дані та відкривати заявки у GLPI про інцидент безпеки.
Деякі зі стандартів ISO, які зосереджені на обробці інцидентів, включають ISO/IEC 27001, ISO/IEC 27002 та ISO/IEC 27035. ISO/IEC 27001 — це стандарт для систем управління інформаційною безпекою (ISMS), що встановлює вимоги та найкращі практики для розробки, впровадження, підтримки та удосконалення СУІБ. ISO/IEC 27002 — це стандарт контролю інформаційної безпеки, який містить рекомендації та вказівки з вибору та застосування заходів безпеки для різних сценаріїв та ризиків. ISO/IEC 27035 — це стандарт управління інцидентами безпеки інформації, що описує принципи, процеси та методи управління та вирішення інцидентів безпеки. Складається він з п’яти етапів: планування та підготовка, виявлення та звітування, оцінка та прийняття рішень, реагування, а також навчання та постійне вдосконалення.
Незважаючи на назву, стандарт ISO/IEC 27035 зосереджений на інцидентах, що стосуються ІТ-систем і мереж, тоді як основні принципи також застосовуються до інших типів інформації, таких як документація, знання, інтелектуальна власність, комерційні таємниці та особиста інформація.
Оскільки неможливо врахувати кожен окремий випадок і відповісти на нього, деякі ризики можна прийняти, інші можна поділити з третіми сторонами або уникнути. Крім того, реагування на значний інцидент може потребувати використання планів безперервності бізнесу. Отже, варто інтегрувати цей стандарт з ISO 22301 та іншими відповідними стандартами.
Якщо вам сподобалася стаття, внизу можна підтримати автора плесканням 👏🏻 Дякую за прочитання!
