Кібербезпека держави в смартфоні питання заполітизоване та наелектризоване. Щоб зорієнтуватися у фактах, я присвятив кілька тижнів вивченню інформації про безпеку Дії як програмного продукту. Навіть на їхню Bug Bounty програму підписався і вже поскаржився на її недоліки в підтримку BugCrowd, така вже я людина. В цьому пості я ділюся своїми висновками про безпеку Дії.
Щоб увійти в курс справ, вам слід прочитати останні 100 постів Костянтина Корсуна, Андрія Барановича та Артема Карпінського, а також опанувати два цікаві матеріали в онлайн-ЗМІ. Перший це колонка міністра цифровізації на Лізі, другий це інтерв’ю заступника міністра цифровізації у НВ. Усі згадані джерела маніпулятивні поза рамками пристойності, проте за лаштунками дотичних наративів очевидний головний меседж Мінцифри: ми піклуємось про безпеку Дії як головної (наразі) маніфестації концепції “держави в смартфоні”. Ми здійснюємо для її захисту потрібні та ефективні заходи. Зокрема це КСЗІ навколо інфраструктури додатку Дія та Bug Bounty її програмної частини. З боку критиків лунають закиди, які підлаштовуються під контекст та тон контраргументів. Але якщо коротко, то на думку опонентів Мінцифра некомпетентна виконувати взяті на себе зобов’язання.
Як професіонал з кібербезпеки, який спеціалізується на захисті програмного забезпечення на рівні стратегічного управління однією з найкращих компаній на цьому ринку, мушу зазначити, що твердження з обох боків позбавлені об’єктивної ваги й НЕ Є аргументами – ані на захист тези про безпеку Дії від актуальних загроз, ані проти неї. Знову ж таки, я не хочу ставати учасником політичних баталій між Мінцифрою та її противниками. Мій погляд на ситуацію суто професійний. Сьогодні я спрямую увагу на аргументи Мінцифри, бо її опонентам від мене вже дісталося. Отже, розпочнімо.
Навіщо Дії безпека?
Дія це софт. Бізнес-кейс її досить тривіальний. По суті, це API шлюз між багатьма вже наявними порталами, реєстрами та іншими системами, що приховує безлад державного ІТ за зручним інтерфейсом користувача. Це як платіжний шлюз між сотнями банків та сотнями тисяч онлайн-крамниць. Це таке собі відображення “багато в дуже багато”, маршрутизація запитів між суб’єктами обробки даних. Дверний глазок, який робить госушний технохаос більш-менш юзабельним.
Як будь-який софт, Дію пишуть люди. Люди роблять помилки. Помилки призводять до вразливостей та інших вад безпеки. Зараз, поки Дія ще проста як прямий кут, це не так помітно, бо її майже немає. Складність продукту зараз на рівні додатку з планування візиту до лікаря або переводу коштів в мобільному банкінгу. Тобто, це дуже просто, тут ще складно натупити. Тому й Bug Bounty Дії така в’яла: наразі всього 4 вразливості, 0 критичних. Тому й скандали навколо безпеки Дії мають ситуативний характер і спираються на “випадки з життя”, а не статистику. Тому й робити більше за вже зроблене Мінцифра не хоче. Ось це статус кво, він цілком природний з бізнесової точки зору, але він може зрушити з місця в будь-який момент через одну з двох причин.
Що треба зробити для безпеки Дії?
Причина перша: зміняться зовнішні вимоги. Зараз вони дуже прості: зробити все легально (звідси КСЗІ) та яскраво відзвітувати широкій публіці (звідси Bug Bounty). Причина друга: відбудеться інцидент кібербезпеки, який поставить ефективність безпеки Дії під питання. (Теоретичний третій варіант реакції Мінцифри на критику суспільно-активних практиків кібербезпеки я оцінюю як неперспективний, зокрема через його скомпрометованість емоційними та популістськими методами з боку критиків. Відповіддю на популізм не повинен бути популізм, інакше це замкнуте коло. І учасники конфлікту вже давно в ньому.)
Я залишу багатостраждальну КСЗІ поза дужками, бо вона слабко стосується безпеки рівня додатку. Проте на Bug Bounty зупинюся докладніше. Як я вже сказав, баг-баунті не є релевантним контролем безпеки на рівні додатку. Це скоріше додатковий захід, до якого вдаються компанії, в яких з безпекою вже і так усе непогано, тому вони готові відкритися світу та зустрітися з будь-яким супротивником. Баг-баунті це хороший понт, а не центральна практика Application Security. Центральними ж практиками аппсеку є наступні:
- Застосування принципів побудови захищених систем (Security Engineering) під час планування та реалізації додатку.
- Формальне моделювання загроз (Threat Modeling) для формування вимог безпеки.
- Безпечне кодування додатку та регулярні ревю безпеки коду (Security Code Review).
- Регулярне внутрішнє та зовнішнє тестування безпеки додатку (Security Testing; Third-party Application Penetration Testing).
- Навчання команди розробки цим та іншим практикам Application Security з OWASP SAMM, BSIMM або інших методологій.
Ось це необхідний мінімум, який треба виконувати будь-якій команді розробки для того, щоб розпочати програму Application Security та показати реальні докази уваги до безпеки продукту. Серед них немає Bug Bounty, тому що вона наступає значно пізніше – буквально в фіналі AppSec-програми, коли ці та десятки інших практик вже впроваджено та виведено на гідний рівень зрілості.
Як засвідчити безпеку Дії?
Основна (обґрунтована) претензія спеціалістів з кібербезпеки до Мінцифри полягає в непрозорості прийнятих рішень. Питання “де практики апсеку, чумба?” не знаходить адекватної відповіді. Повторюю, Bug Bounty, аудити, КСЗІ, пентести – це не відповіді, адже на старті програми баг-баунті це нерелевантна практика, а артефакти від решти заходів або таємні, або нерепрезентативні. В цьому я цілком погоджуюся з критиками: прозорість тут не завадила б, і публічне розкриття артефактів це не єдина форма такої прозорості.
Одна можлива форма, простіша та дорожча, але одразу закриває рота усім критикам, це замовити у Synopsys аудит по BSIMM. Це так ніби сказати одним з найкращих аудиторів безпеки програмної розробки: прийдіть до нас, проведіть оцінку, та порівняйте нас із понад сотнею інших організацій, серед яких найвідоміші та найбільші софтверні фірми у світі. Продакт-менеджери називають це ”liability shift”. Такий звіт, у разі позитивного висновку, автоматично припинить лайношторм навколо безпеки Дії, тому що сперечатися з ним безглуздо. Проте, я впевнений, що до вигідних позицій у BSIMM команді Дії ще дуже далеко.
Друга можлива форма, складніша та дешевша. Мінцифра могла б, наприклад, зібрати визнаних експертів з аппсеку на закритий брифінг, продемонструвати їм стан справ, отримати об’єктивну рецензію та дієві рекомендації. Це нормальна практика у цивілізованих країнах, і такий хід зміг би ураз зупинити тертя з опонентами в кіберспільноті. Аудитори називають це “закриття планом”. Проте в мене сумніви, що Мінцифра до цього готова: адекватні експерти в Україні в хронічному дефіциті, а у пролобійованих з Держдепу та грантодавців компаніях їх просто немає.
Висновки
Підсумуємо. Мінцифра помиляється: Bug Bounty програма, навіть дуже класна й успішна (а у них вона на трійку) – це НЕ ДОКАЗ достатньої уваги до безпеки додатку рівня “держави в смартфоні”. Правильний підхід: впровадити базові практики Application Security та продемонструвати артефакти їхнього виконання команді експертів з безпеки програмного забезпечення. Це закрило б тему безпеки Дії надовго або назавжди й змогло б примирити критиків та популяризаторів Дії й перевести їхній діалог в конструктивне річище. Я скептично ставлюся до можливості такого сценарію, адже це вимагає політичної волі поза рамками забаганок того, хто платить за музику. Проте, усе можливо, якщо така воля раптом з’явиться.
З вами був Кіт Леопольд української кібербезпеки Володимир Стиран. До наступного разу, залишайтесь в безпеці.