Моделювання загроз для невеликої платформи

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

Порядок важливіший за повноту

Класична помилка — довгий список усього, що може піти не так, де кожен пункт розглядається як однаково терміновий. Це призводить до паралічу, а потім усе одно до рішення, ухваленого «на відчуття». Впорядкований список із семи пунктів вартий більше, ніж вичерпний список із сорока, бо ви все одно діятимете лише за першими трьома і ніколи не дійдете до решти.

Впорядковуйте за ймовірністю × вартістю для вас, а не за тим, наскільки тривожно звучить сценарій. Державний супротивник — найстрашніший пункт у будь-якому списку і водночас, для майже кожної малої платформи, найменш імовірний — тоді як витік облікових даних від колишнього підрядника непримітний, надзвичайно поширений і зазвичай катастрофічний.

Сім супротивників, впорядкованих за ймовірністю

Супротивники за ймовірністю та засоби їх пом'якшення

Супротивник	Ймовірність	Хостинг допомагає	Що справді допомагає
Ви, у поганий день	Абсолютна	Ні	Резервні копії, з яких ви справді відновлювалися, і процес узгодження змін для всього, що стосується автентифікації чи DNS. Найімовірніша причина вашого найгіршого збою — ви самі.
Автоматизоване сканування	Постійна	Ні	Встановлення патчів, відмова від паролевої автентифікації, відсутність облікових даних за замовчуванням. Це фоновий шум; він спрямований не персонально на вас і ніколи не припиняється.
Компрометація облікових даних	Висока	Ні	Апаратний другий фактор автентифікації, обмежені за обсягом API-токени та відкликання доступу того самого дня, коли хтось звільняється, а не через квартал після цього.
Заявник із формою	Висока	Так	Це єдиний випадок, на який юрисдикція хостингу дійсно впливає: чи може сама лише кореспонденція призвести до зупинення вашого сервісу.
Об'ємна атака	Середня	Частково	Фільтрація на боці транзитного оператора, а точніше провайдер, який фільтрує трафік, а не відключає вас через null-routing заради власного захисту.
Цільовий зловмисник	Низька	Ні	Сегментація, принцип найменших привілеїв, шифровані дані у стані спокою та журнали, розміщені там, де зловмисник не може їх змінити.
Державний суб'єкт	Дуже низька	Частково	Юрисдикція визначає правовий шлях, а не технічний. Якщо це дійсно є частиною вашої моделі загроз, зверніться по правову консультацію, а не по тарифний план хостингу.

На які з них впливає рішення про хостинг

Два із семи, і частково третій. Це співвідношення саме по собі є найкориснішим результатом вправи, і саме тому виконання її до вибору провайдера економить більше коштів, ніж будь-яка порівняльна таблиця.

Годинна версія

1. Складіть перелік того, що ви справді зберігаєте (10 хв). Не системи — дані. Адреси електронної пошти користувачів, платіжні записи, приватні повідомлення, завантажені файли, облікові дані до інших сервісів. Запишіть, що найгірше втратити, а що найгірше злити; це рідко одне й те саме.
2. Складіть перелік того, хто захоче заволодіти кожним із них (10 хв). Будьте конкретними. «Хакери» — це не супротивник; «хтось, хто купує дампи облікових даних, щоб перепродати чужі облікові записи» — так, і це передбачає інший захист.
3. Впорядкуйте за ймовірністю × вартістю (10 хв). Ігноруйте, наскільки драматично щось звучить. Домінують непримітні пункти.
4. Для перших трьох опишіть першу годину (20 хв). Що б ви робили в перші шістдесят хвилин після кожної з подій. Якщо не можете відповісти — це і є висновок, і він цінніший за сам рейтинг.
5. Позначте, на які з них впливають інфраструктурні рішення (10 хв). Зазвичай це два з перших п'яти. Тепер ви знаєте, що насправді дає ваше рішення про хостинг.

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

Три помилки, які роблять усе це марним

Моделювання супротивника, який здається вам цікавим. Про можливості держави-суб'єкта думати цікавіше, ніж про витік API-токена в публічному репозиторії. Одне з двох сталося майже з кожним, кого ви знаєте. Впорядковуйте чесно — і перемагають нудні пункти, у чому й полягає суть.

Плутанина заходу контролю з результатом. «Ми використовуємо шифрування» — це не пом'якшення ризику, доки ви не можете сказати, що саме воно зупиняє, а що ні. Повне шифрування диска на працюючому сервері захищає від випадку, коли диск виносять за межі будівлі; воно нічого не дає проти зловмисника з доступом до оболонки на працюючій машині, бо том уже розблоковано.

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

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

Написано інженерами, які підтримують платформу, і востаннє перевірено 1 місяць тому. Якщо щось тут неправильне або застаріло, повідомте про це через панель клієнта — саме звідти прийшла приблизно половина цих посібників.