Наскільки важливою є безпека проекту?

Безпека на проекті

Безпека не є частиною стандартного процесу запуску проекту. Проте безпека проекту — це те, про що мають дбати його керівники. Ігнорування інформаційної безпеки та конфіденційності часто призводить до затримок з виведенням та введенням в експлуатацію або, що ще гірше, до запуску нової інформаційної системи у виробництво без достатнього контролю безпеки та конфіденційності. Це означає схильність до таких ризиків, як:

  • розкриття інформації;
  • несанкціонований доступ до систем та інформації; 
  • порушення вимог законодавства, наприклад, Закону про конфіденційність.

У цій статті ми розглянемо, що таке безпека проекту, та як ви можете забезпечити її на своєму власному проекті.

Що таке безпека проекту?

Безпека проекту включає перевірку того, що всі артефакти проекту мають правильні протоколи доступу. Протокол доступу — це спосіб, яким користувач отримує доступ до чогось. Процес безпеки проекту гарантує, що члени проектної групи отримують доступ до потрібної інформації.

Безпека проекту є важливою, перш за все, для захисту конфіденційності вашого проекту. Вона також допомагає проектувати артефакти та корпоративні дані. У даній статті ми розглянемо тільки інформаційну безпеку. 

Діяльність з інформаційної безпеки та конфіденційності має бути інтегрована у методологію управління проектами організації. Це гарантує, що ризики інформаційної безпеки та конфіденційності виявляються, оцінюються, усуваються та керуються в рамках проекту. Цей підхід може застосовуватися до будь-якого проекту, незалежно від його характеру, наприклад, проекту основного бізнес-процесу, ІТ, управління обладнанням та іншим допоміжним процесам.

Двома основними підходами до управління проектами є:

  • водоспадний підхід (постачання здійснюється за один раз, наприклад Prince 2 та PMP); 
  • ітеративний підхід, що базується на випуску (доставка відбувається у вигляді сплесків функціональності, розподілених у часі, наприклад, методологія Agile Scrum/Sprint).

Усі методології управління проектами слідують аналогічному високорівневому процесу з 4 або 5 кроків, в абзацах нижче кроки методології Agile вказані у дужках. Кожен з цих кроків має власну мету/завдання та набір результатів для цього кроку.

Масштаб/Ініціація/виявлення (етап 1 Бачення)

  • Чи бере участь особиста інформація в цьому проекті, чи обробляється поставленою інформаційною системою? 
  • Яка класифікація або конфіденційність інформації, що обробляється?
  • Переконайтеся, що співробітник з інформаційної безпеки (або еквівалентна роль, така як безпека ІКТ, директор з інформаційної безпеки, ITSM) бере участь у обговоренні вимог безпеки, вони повинні бути невід’ємною частиною бізнес-вимог.
  • Чи є потреба у дотриманні законодавчих або нормативних вимог, національних або міжнародних стандартів (NZISM, ISO27001) або договірних зобов’язань щодо забезпечення безпеки та конфіденційності?

Економічне обґрунтування/планування (етап 2 «Дорожня карта продукту» та етап 3 «Планування випуску»)

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

Розробка/Виконання (етап 4 «Планування спринту» та етап 5 «Щоденний скрам»)

  • Чи реалізовані в проекті певні елементи керування безпекою та конфіденційністю? 
  • Розгляньте можливість сканування вразливостей (внутрішнього) та перевірки стану виправлення.
  • Залучайте зовнішніх експертів з безпеки, таких як тестувальники на проникнення, рецензенти коду та аудитори.
  • Зв’яжіться з групою експлуатації, яка керуватиме рішенням з точки зору безпеки після його введення в експлуатацію.

Тестування та оцінка/контроль та перевірка (етап 6 Огляд спринту)

  • Виконання всіх тестів безпеки: тестування на проникнення, перевірка коду та/або аудит ISO.
  • Залучайте експертів у галузі безпеки та конфіденційності, щоб допомогти в інтерпретації підсумкових (тестових) звітів.
  • Перегляньте реєстр ризиків і повторно оцініть всі ризики на основі рішення у тому вигляді, в якому воно було створено.

Запуск/закриття (етап 7)

  • Передача невиконаних планів забезпечення безпеки та конфіденційності, які були погоджені та прийняті власником бізнесу.
  • Початок роботи у звичайному режимі: операції з безпеки, моніторинг ризиків та відповідність вимогам.

Як бачите, є багато сфер інформаційної безпеки, які слід враховувати. 

Безпека – це не те, про що ви можете подумати, коли вперше запускаєте проект, але як менеджер проекту ви виявите, що насправді багато інформації проходить через вашу поштову скриньку. Тому для того, щоб успішно керувати інформаційною безпекою проекту, необхідно розставляти процеси по місцях та ставити правильні питання щодо безпечного управління активами проекту. Більше про управління командою та проектом можна дізнатися на online-курсі DevOps Junior.

Знайшли цю статтю корисною для себе? Шерте її у своїх соціальних мережах!

Интересная статья. Поделись с друзьями!

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *