У сфері ІТ-безпеки ми повинні дбати про все. Будь-яка проблема, якою б малою вона не була, може стати засобом для дистанційного виконання коду або, принаймні, точкою приземлення для загрозливих акторів, які живуть за рахунок землі та обертають наші власні інструменти проти нас. Не дивно, що працівники ІТ-безпеки стикаються з виснаженням і стресом. Відповідно до дослідження Enterprise Strategy Group і ISSA, близько половини фахівців з ІТ-безпеки вважають, що залишать поточну роботу в найближчі 12 місяців.

Команди безпеки несуть професійну відповідальність — і тепер для керівників інформаційної безпеки (CISO), особиста відповідальність — для безпеки своїх організацій. Проте в інших галузях ІТ і технологій існує зовсім інше мислення. З мантри Марка Цукерберга «швидко рухатись і ламати речі” до Еріка Райса Lean Startup і модель мінімально життєздатного продукту (MVP), ідея в цих сферах полягає в тому, щоб рухатися швидко, але також забезпечити достатньо, щоб організація могла рухатися вперед і вдосконалюватися.

Зараз групи ІТ-безпеки не можуть прийняти цю модель. Надто багато правил, які потрібно враховувати. Але чого ми можемо навчитися з розумової вправи щодо мінімальної життєздатної відповідності (MVC) і як ми можемо використати цю інформацію, щоб допомогти нам у нашому підході?

Що включатиме MVC?

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

Для управління активами в ідеалі ви повинні знати всі активи, які ви встановили. Без такого рівня нагляду, як ви можете вважати себе безпечним? Для підходу MVC вам знадобиться 100% розуміння того, що ви маєте?

Насправді проекти управління активами, такі як бази даних керування конфігурацією (CMDB), мають на меті забезпечити повна видимість ІТ-активів, але вони ніколи не бувають точними на 100%. У минулому точність активів коливалася в межах від 70% до 80%, і навіть найкращі сьогоднішні розгортання не можуть досягти повної видимості та зберегти її там. Отже, чи варто витрачати наш бюджет MVC на цю сферу? Так, але не зовсім так, як ми могли б традиційно думати.

Один заступник CISO сказав мені, що він розуміє ідеал повного покриття, але це неможливо; натомість він піклується про повну та постійну видимість критичної інфраструктури організації — близько 2.5% від загальних активів — тоді як інші робочі навантаження відстежуються якомога частіше. Таким чином, незважаючи на те, що видимість все ще є необхідним елементом для програм ІТ-безпеки, зусилля повинні бути спрямовані на захист активів із найвищим ризиком. Однак це короткострокова мета, оскільки лише одне розкриття вразливості дозволить активу з низьким рівнем ризику перетворитися на актив із високим ризиком. Проходячи цей процес, не плутайте відповідність із безпекою — це не одне й те саме. Сумісний бізнес може бути небезпечним.

Планування регулювання

Як частина MVC, ми маємо думати про правила та як їх дотримуватися. Завдання для команд безпеки полягає в тому, як продумати ці правила наперед. Типовий підхід полягає в тому, щоб отримати законодавство, потім побачити, де воно стосується наших програм, а потім внести зміни в системи за потреби. Однак це може бути підхід, який передбачає зміни — і, отже, витрати — кожного разу, коли вводиться нове регулювання або відбуваються значні зміни.

Як ми можемо полегшити цей процес для наших команд? Замість того, щоб розглядати кожну постанову окремо, чи можемо ми поглянути на те, що є спільним для відповідних норм, а потім використати це для зменшення обсягу роботи, необхідної для дотримання їх усіх? Замість того, щоб змушувати команду виконувати величезні вправи, щоб привести системи у відповідність, що ми можемо вилучити зі сфери діяльності або натомість використовувати як послугу для безпечного забезпечення інфраструктури? Подібним чином, чи можемо ми використовувати загальні найкращі практики, як-от хмарні засоби керування, щоб усунути цілі набори проблем, а не розглядати кожну проблему окремо?

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

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

• Розповсюдження контенту та PR на основі SEO. Отримайте посилення сьогодні.
• PlatoData.Network Vertical Generative Ai. Додайте собі сили. Доступ тут.
• PlatoAiStream. Web3 Intelligence. Розширення знань. Доступ тут.
• ПлатонЕСГ. вуглець, CleanTech, Енергія, Навколишнє середовище, Сонячна, Поводження з відходами. Доступ тут.
• PlatoHealth. Розвідка про біотехнології та клінічні випробування. Доступ тут.
• джерело: https://www.darkreading.com/cyber-risk/minimum-viable-compliance-what-you-should-care-about-and-why