Кібербезпека

Модель загроз пишуть першою, і вона обмежує фічі

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

Придатна модель відповідає письмово на чотири питання, і четверте зазвичай пропускають. Що ми захищаємо — не «систему», а конкретні активи: цей ключовий матеріал, цю історію переміщень, цю ідентичність оператора, цю здатність віддавати команди. Хто намагається, з якими ресурсами й з яким терпінням. Що кожен із них здобуває, якщо вдасться. І, критично, від чого ми НЕ захищаємося — сказано явно, бо модель, що заявляє захист від усього, не ухвалила жодного рішення й буде тихо покинута першого ж разу, коли стане незручною.

Припускайте, що пристрій опиниться в чужих руках

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

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

Ланцюг постачання і шлях оновлення як мішень

Фінансований супротивник шукає найдешевший вхід, і найдешевшим входом рідко є сам продукт. Це залежність, яку ніхто не переглядає; машина збірки, яку ніхто не зміцнював; або механізм, який ви побудували саме для того, щоб доставляти код на всі пристрої одразу. Останнє варто прочитати прямо: шлях оновлення є найпривабливішою вашою мішенню, бо це єдиний компонент із владою над усім парком.

• Знайте, що у збірці. Інвентар залежностей, згенерований автоматично під час збірки, — щоб питання «чи нас це зачіпає» мало відповідь за хвилини, а не за тиждень grep.
• Зробіть збірку відтворюваною, щоб артефакт можна було перезібрати з коду й порівняти. Без цього «бінарник відповідає коду» є вірою, а не перевіркою.
• Ставтеся до системи збірки як до продакшну. Вона тримає ключі підпису й виробляє те, чому всі довіряють; агент збірки, куди будь-хто може подати задачу, є сервісом підпису, яким будь-хто може скористатися.
• Підписуйте артефакт і перевіряйте на пристрої, причому перевірка має бути в ланцюзі завантаження, а не в застосунку, який замінюють.
• Викочуйте поетапно з автоматичним відкатом: погане оновлення, що дійшло до всіх пристроїв одночасно, за наслідками не відрізняється від успішної атаки.
• Змусьте пристрій відмовляти в пониженні версії — інакше супротивник просто попросить його встановити торішню збірку з уже виправленою вразливістю.

Що це змінює у звичайній розробці

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

• Ідентичність на пристрій, з першого дня

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

• Логи, що переживають пристрій

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

• Криптографія, яку можна замінити

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

• Спосіб отримати погану новину

  Опублікований контакт і політика для повідомлень ззовні. Дослідники щось знаходять; питання лише в тому, чи можуть вони сказати вам, чи мусять сказати комусь іншому.

Антипатерни, які варто назвати

• Спільний секрет на весь парк: одна втрата пристрою перетворюється на доступ до всього.
• Ключ підпису на ноутбуці чи у змінній CI: скомпрометувати розробника означає скомпрометувати кожен пристрій.
• Шлях оновлення без поетапного викочування, де поганий реліз має той самий обсяг, що й успішна атака.
• Інтерфейс налагодження, лишений увімкненим, бо був зручним на розробці, — саме його шукають першим.
• Модель загроз, що захищає від усього, нічого не називає прийнятим і тому покидається на першому ж дедлайні.

Коли це застосовувати

Пов’язані сторінки

• DeftechОглядПЗ оборонних технологій — це звичайна інженерія за чотирьох обмежень, які решта цього сайту вважає неіснуючими: немає надійної мережі, супротивник фінансований і терплячий, хибний вихід коштує значно більше за поганий квартал, а користувач не сидить за столом і не має часу вчитися. Майже все інше на цьому сайті припускає протилежне всім чотирьом. Приберіть їх — і інженерія не стане екзотичною, вона стане суворою. Ця сторінка називає чотири обмеження, показує, що кожне з них заміщає, і описує ті частини робочого середовища, які дивують людей із продуктової розробки.
• DeftechДата-платформиДата-платформа — це стек, який збирає, зберігає й переміщує записи організації, а та, що збудована під надійну мережу, спершу надсилає, а зберігає як побічний ефект. Переверніть це припущення — і разом із ним перевернеться архітектура: вузол пише локально й завжди, надсилання стає фоновою справою за нагоди, якої сьогодні може не бути, а цікавим проєктним рішенням стає те, які записи підуть першими, коли вікно контакту триває сорок секунд. Тут — про цю чергу, про приймальний бік, що очікує обриву, і про три властивості, які мусить нести кожен запис.
• DeftechПЗ для дронівПЗ для дронів — це польотний код на борту безекіпажного апарата разом із наземною частиною, яка ним командує; а сам апарат — це розподілена система, у якій один із вузлів падає з неба, якщо пропустить дедлайн. Цей єдиний факт організує все: який код де працює, чому можна блокуватися, чому дозволено падати і чому цікава частина специфікації — не місія, а те, що станеться, коли зникне звʼязок, позиція чи заряд. Тут — про стек, драбину відмовостійкості, автономність як набір конкретних рішень і про те, чому симуляція є головним тестовим середовищем, а не приємним доповненням.