Побудова програми безпеки з нуля

Отримати посаду першої людини з безпеки в компанії — це особливий вид хаосу. Немає черги квитків, немає встановленого інструментарію і зазвичай немає розпорядженого для вас бюджетного рядка. Далі йде приблизна карта того, як зазвичай проходять перші 90–180 днів, і що насправді рухає стрілку вперед, а що просто дає відчуття продуктивності.

Що «нічого» зазвичай означає

Коли люди кажуть, що компанія не має функції безпеки, вони рідко означають нульові контролі. Вони означають, що немає спеціального відповідального. У підрозділі розробки ймовірно включено деякі базові політики AWS IAM, в IT розгорнуто якусь антивірусну програму через MDM-інструмент, і хтось у фінансах має думку про SOC 2, тому що це запитав клієнт. Ваша перша робота — опис, не впровадження. Перш ніж писати хоч одну політику, з'ясуйте, що вже працює: облікові записи в хмарі (і скільки їх ніхто не пам'ятає, що створював), SaaS-інструменти з правами адміністратора до вихідного коду та чи є один джерело істини для звільнення працівників. Таблиця для цього підходить. Платформа GRC поки не є пріоритетом.

Перші 30 днів: видимість замість контролю

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

• Ідентичність: витягніть повний список користувачів з вашого постачальника ідентичності (Okta, Google Workspace, Azure AD) і звіртесь зі списком активних працівників HR. Ви знайдете привидьські облікові записи.
• Хмарний слід: запустіть щось на кшталт aws organizations list-accounts, якщо ви на AWS, або перевірте Asset Inventory GCP, щоб бачити, скільки середовищ існує порівняно з тим, скільки хтось може назвати по пам'яті.
• Видимість коду та таємниць: запустіть gitleaks detect або trufflehog filesystem . щодо ваших основних репозиторіїв. Знайти закодований ключ API в історії комітів від два роки тому майже гарантовано і це швидкий спосіб продемонструвати цінність.

Захопіть результати, але не перетворюйте це на 40-сторінковий звіт, який ніхто не відкриває. Односторінкове резюме ризиків з п'ятьма пунктами читає CTO. Довгий PDF — ні.

Вибір перших трьох контролів

Без чисельності персоналу та бюджету на інструменти ви не можете робити все одночасно. Послідовність операцій, яка зазвичай працює:

1. MFA повсюди, де його немає, починаючи з постачальника ідентичності, потім GitHub/GitLab, потім хмарні консолі. Це саме по собі перекриває найпоширеніший шлях захоплення облікового запису.
2. Централізоване логування для подій хмари та автентифікації. Навіть вільна версія SIEM-подібного інструменту або просто відправлення CloudTrail/GCP audit logs у сховище з утриманням краще, ніж не мати нічого, коли стається інцидент.
3. Письмовий, короткий план реагування на інцидент, навіть якщо це дві сторінки: кого викликати, хто говорить з клієнтами, хто має владу щось вимкнути. Ніхто не пам'ятає про це, доки не потрібно, а тоді вже занадто пізно.

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

Отримання підтримки без окремого рядка бюджету для безпеки

Найшвидший спосіб втратити авторитет як перший найманий працівник з безпеки — показатися зі списком побажань інструментів перед тим, як показати будь-які результати. Натомість прив'яжіть кожне прохання до чогось конкретного: «ми знайшли трьох користувачів IAM з неповертаними ключами доступу від 2021» звучить краще, ніж «нам потрібен CSPM-інструмент.» Формулюйте запити в категоріях, якими вже цікавляться розробники та фінансисти: зменшений радіус розповсюдження, швидші аудити, менше звінків на 2 ночі. Якщо компанія переслідує SOC 2 або ISO 27001, той крайній термін дотримання зазвичай ваша найкраща точка важелю для отримання ресурсів, навіть якщо дотримання саме по собі не є метою.

Поширені помилки протягом першого року

Покупка дорогої платформи (SIEM, EDR, CSPM) перед тим, як у вас буде процес або персонал для її фактичної експлуатації — найбільш поширена витрата раннього бюджету. Інструмент за $50k, який ніхто не налаштовує, породжує шум, а не виявлення. Аналогічно, написання політик, скопійованих із шаблону без адаптації до того, як компанія насправді працює, гарантує, що їх ігнорують першого разу, коли комусь потрібен виняток. І прагнення володіти всім самостійно після перших шести місяців — шлях до вигорання; в момент, коли з'являється розвиток, наступного найманого зазвичай повинна бути людина, яка може володіти виявленням та реагуванням, так ви можете продовжувати будувати структуру програми.

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

Якщо вас цікавить такий проект программ з основ, Korra Studio має відповідні сегменти щодо основ реагування на інциденти та безпеки хмарної позиції, які добре поєднуються з цим.