Моделювання загроз є дуже ефективним засобом захисту програмного забезпечення та додатків, але дуже мало організацій насправді цим займаються. Однак у сучасному комп’ютерному середовищі та середовищі безпеки моделювання загроз є більш необхідним, ніж будь-коли.
Хмарні розподілені системи та багатофункціональні, гнучкі команди розробки програмного забезпечення замінили монолітні системи, створені та керовані ізольованими командами. Попутно програмне забезпечення стало набагато складнішим, а також загрози. Зловмисники змінили тактику, щоб обійти традиційні засоби виявлення. Багато атак більше не створюють зловмисне програмне забезпечення, наприклад, натомість зосереджуються на компрометації облікових даних. А зловмисники можуть місяцями сидіти в мережах компанії, перш ніж діяти. IBM "Вартість звіту про порушення даних” виявили, що організаціям потрібно в середньому 287 днів, щоб виявити та локалізувати порушення.
Компанії визнають потребу. А Дослідження Компас безпеки 2021 виявили, що 79% середніх і великих підприємств вважають моделювання загроз пріоритетом, але лише 25% проводять моделювання на ранніх етапах проектування. І лише 10% виконують моделювання загроз для 90% програм, які вони розробляють.
Як індустрія, ми повинні зробити моделювання загроз стандартною практикою в розробці програмного забезпечення, запроваджену таким чином, щоб команди розробників і безпеки могли працювати з нею, і реалізовано таким чином, щоб показувати позитивні результати та покращення з часом. І все починається зі слова, яке ви, можливо, не часто чуєте в колах ІТ-спеціалістів і безпеки: співпереживання.
Культурна зміна
Існує низка причин розриву між баченням цінності моделювання загроз і їх фактичним виконанням, зокрема відсутність зв’язку між командами безпеки та розробниками, а також схильність відмовлятися від моделювання загроз, якщо початкові зусилля стають плутаними і не дають бажані результати.
Занадто часто групи безпеки можуть розглядати застосування засобів контролю безпеки як вулицю з одностороннім рухом між ними та командами розробників, просто як на те, щоб вказувати розробникам, що робити. Але це починається не з тієї ноги. Організації повинні визнати, що кожна команда має навички, яким інша може навчитися. Зрештою, якщо ви помістите професіонала безпеки в простір розробників, вони будуть втрачені.
Зміна цього мислення потребує культурних змін, і це починається з розгляду емпатії як ціннісної пропозиції. Людська сторона цього має вийти на перший план, залучаючи більше людей до збагачення наших знань. Команди безпеки повинні цінувати середовище, в якому працюють розробники, під тиском швидкої розробки та доставки програмного забезпечення. Команди розробників можуть допомогти групам безпеки зрозуміти такі структури, як контейнери, і як контролювати доступ, знання, які можна застосувати до політик безпеки.
Коли команди співпрацюють туди й назад, вони вчаться одна в одної. Щоб досягти цього, потрібен час. Це може початися з зустрічей або інтеграції процесу, можливо, трохи пропрацювавши методом проб і помилок, і зрештою перейти до інтеграції інструментів. Коли вони досягнуть рівня зрілості, коли кожен має базове розуміння доменів один одного, вони зможуть перейти до більш просунутих рівнів моделювання загроз, таких як моделювання баз знань і створення графіків концепцій, які відображаються разом.
Але для цього потрібен стабільний процес, інакше він стане дорогим і хаотичним, що призведе до проблем з людьми.
3 кроки до кращого моделювання загроз
Для створення атмосфери співпраці є три ключові елементи.
Тренування: Це допомагає розробникам зрозуміти важливість моделювання загроз. Це може початися з адаптації нових співробітників. Незалежно від їх досвіду та сертифікатів, не припускайте, що вони знають, як забезпечується безпека у вашій компанії. Переконайтеся, що вони розуміють культуру.
Співпраця: Культура співробітництва та взаємодії починається з керівництва компанії, коли CISO має позицію бажання служити командам. Це може зайняти час, але це має моделюватися на рівні керівництва.
інтеграцією: Елементи співпраці об’єднуються, працюючи над інтеграцією, яка є постійним процесом. Мета полягає не в досконалості, а в удосконаленні та розвитку з часом.
Ключ до того, щоб цей підхід спрацював застосовуючи показники, зокрема, дивлячись на результати, як-от «зменшення вразливості» — на відміну від спроб оцінити деталі того, як працюють люди. Результати – це не питання розробника чи безпеки, це справа кожного.
На своєму досвіді я переконався, що корисно мати чіткі 30-, 60- та 90-денні плани з описом очікуваного результату на кожному етапі. Плани мають демонструвати поступове зростання та виконуватися спільно. Якщо ці результати слід вимірювати, інакше ви безцільно дрейфуєте.
Співпереживання — це ключ
Як спільнота безпеки, це наша відповідальність допомогти розробникам застосувати моделювання загроз. Це не ми проти них. Нам потрібно змусити їх думати про безпеку та моделювання загроз як частину комплексного підходу, який розвивається з часом.
Емпатія як техніка управління може допомогти створити таке середовище. Деякі люди можуть думати, що емпатія означає відсутність відповідальності — що розуміння чиєїсь позиції та думок якось м’яке, — але насправді це дає протилежний результат. Це розвиває співпрацю, яка нам так потрібна.
