Чому CERT – це дійсно важливо?
Спочатку, трохи пояснень – що це таке і чому про ті «Сьорти/Серти» усі говорять. А вже потім про те, як не можна їх будувати.
Зараз часто можна почути з високих кабінетів, з Концепцій-Стратегій та навіть Законів України про важливість створення в Україні «мережі галузевих CERTів» чи інші поминання всує не усім відомого поняття CERT.
Якщо на двох пальцях, то це – просто професійна команда фахівців з кібербезпеки, яка обробляє та реагує (на) інциденти (кібер)безпеки.
Дослівно так і назиається: Computer Emergency Response Team (CERT) – Команда Реагування на Комп’ютерні надзвичайні події або більш просунута назва CSIRT: Команда Реагування на Інциденти Комп’ютерної Безпеки. Існують і ще більш професійні назви, але найпопулярніші у Світі саме ці дві.
Так історично склалося.
Чому CERT – це дійсно важливо?
Інциденти безпеки трапляються у кожній мережі й навіть окремому комп’ютері майже кожного дня.
Про більшість інцидентів користувач чи адмін мережі навіть не здогадується.
Багато з виявленних інцидентів адміни просто не афішуть, бо у більшості випадків є винними у їх виникненні: не налаштував міжмережевий екран, не розподілив доступ користувачам, не оновив софт, не встановив патчі, не цікавився безпекою власної мережі, не знав, що взагалі має цим опікуватися, тощо.
Перелік може бути довгий. Але деякі інциденти все ж стають відомими, а окремі з них – дуже відомими.
Останніх в Україні чи не найбільше у світі (пропорційно до рівня комп’ютеризації та кількості користувачів Інтернет). Бо Україна фактично знаходиться у епіцентрі найбільшої за всю історію людства кібервійни.
CERTи більш актуальні для великих мереж із великою кількістю користвачів, тому обговорюватимемо саме цей варіант.
Збирати до купи усю можливу інформацію про виявлені інциденти в мережі, грамотно аналізувати, виявляти закономірності та загальні риси, індикатори, джерела загроз, прояви, тенденції – ось перше з головних завдань CERTу.
Друге важливе завдання: ділитися здобутою інформацією.
Зазвичай більшість зловмисних атакувальників не відрізняються особливою креативністю підходів: більш-менш стандартні методики проникнення, відомі сігнатури ШПЗ, схожі моделі поведінки у мережі, експлуатація відомих вразливостей, типова соцінженерія.
Тому зібрана командою інформація про інциденти, якщо вона направлена іншим CERTам, може унеможливити аналогічну атаку на інші мережі.
Може, це сусідній офіс скаже вам «дякую», а може – якийсь банк у Намібії.
Збір та аналіз інформації без його шарингу з іншими користувачами чи командами – це шлях у тупик. Пів- чи чверть CERTа.
Тобто реагування на внутрішні інциденти та їх аналіз відбуватиметься, але взаємодії з Великим Світом не буде, оскільки зазвичай атака відбувається з дуже далекого сервера десь у Бразилії чи Таїланді.
А щоб отримувати знання та допомогу від інших – треба самому робити внесок у спільну справу.
З огляду на глобальність та транснаціональність Мережі, ізоляція інформації всередині команди – самогубство CERT як проекту.
І третє важливе завдання: робити висновки.
Це те, заради чого взагалі існують CERTи.
Для чого то всьо замишлялося.
Висновки можуть бути у вигляді рекомендацій користувачам («алярм, не ведіться на лист із темою «Термінове розпорядження керівництва про зарплату»), алерти та оповіщення («робіть ось це, і не робіть того»), настанови для адмінів («терміново пропатчити сервер та програми, оновити PHP, перевірити вразливості CVE-…., закрити порти і протоколи…», «терміново сегментувати локалку»), пропозиції про проведення тренінгів для працівників та керівництва та багато-багато іншого.
Є ще купа інших завдань для CERTу: проведення розслідувань інцидентів, взаємодія з підрозділами компанії (зокрема, з ІТ-Департаментом та Безпекою), іншими командами країни та Світу, з правоохоронними органами, регулярні навчання себе та колег по фірмі, звіти керівництву і т.ін.
Але оті три завдання – то Суть і Сенс CERTу.
SOCу, SCIRTу, CC-CERTу – називайте як хочете, але зміст один.
Історично CERTи виникли зі студентських кампусів, коли кампуси атакували мережі один одного, потім мирилися, об’єднувалися, стоврювали CERT і вже захищалися від інших університетів, потім об’єднувалися університетами, створювали університетський CERT і вже захищалися від транснаціональних загроз.
Потім CERTи ставали між-університетськими, науковими, регіональними, галузевими, національними, континентальними.
Тобто ініцатива створення CERTів ішла «знизу» і була заснована на довірі між партнерами всередині CERT.
І цей історичний екскурс – вельми показовий, далі ще повернемося до важливого нюансу «довіра».
Але про ці прості базові принципи побудови будь-якого CERTу чомусь не знають державні кібер-реформатори та лицарі бюджетного фінансування.
Та і звідки ж їм знати, якщо не маєш уявлення про реальний світ кіберіндустрії? Для цього ж треба вийти з кабінету.
Навіть якщо створити «згори» якусь команду реагування (скажімо, у рамках одного міністерства), де працює жорстка вертикаль «або ти виконуєш мої команди – або з речами на вихід» – все одно без знання базових принципів побудови та функціонування CERT працювати як слід воно не буде.
Не злетить. Як не буцай. Як не засипай грошима.
Хоча наразі, на жаль, завдання – «щоб злетіло» – особливо і не ставиться.
Зараз чиновники тільки починають доганяти, що під модне слово «кібербезпека» можна намутити кількадесят мільйонів бюджетних чи то грантових гривень, а потім сказати звичайне «ну, не шмогла я, не шмогла».
Тому навіщо напружуватися, якщо успіх і не закладався в план розпилу?
Серед гучно анонсованих останнім часом CERTів реальну перспективу має лише НБУ-шний.
І не тільки тому, що над проектом працюють люди з практичним досвідом, є (сподіваюся) бюджети (НБУ, скоріш за все, просто нагне банки – та й усі справи, «чай не впєрвой») та вимальовується бажання – «щоб злетіло».
А, головним чином, тому, що у форму CERTа трансформується вже фактично існуюча структура з налагодженими механізмами взаємодії та певним рівнем довіри між учасниками-контриб’юторами.
Тепер детальніше про те, чому всі інші бадьорі ініціативи бюджетних організацій мають сумнівні перспективи.
Перш за все, через неправильний стартовий вектор.
Має бути «знизу вгору», а не «згори вниз».
Починати побудову CERTу потрібно з питаннь «а яка практична користь нашій мережі та користувачам від CERT?» та «хто саме є споживачем послуг, які надаватиме CERT?»
Якщо є чіткі й позитивні відповіді на ці два питання, можна переходити до обрання типу команди, моделі її фінансування, підпорядкування, шляхів комунікацій та ін. Просто для довідки – які можуть бути типи CERT/CSIRT:
- Academic Sector CSIRT;
- Сommercial CSIRT;
- CIP/CIIP Sector CSIRT;
- Governmental Sector CSIRT;
- Internal CSIRT;
- Military Sector CSIRT;
- National CSIRT;
- Small & Medium Enterprises (SME);
- Sector CSIRT;
- Vendor CSIRT…
І лише після з’ясування усіх вищезазначених аспектів слід починати шукати відповідних фахівців, керівників, допоміжний персонал, рахувати скільки необхідно заліза, софта, де це все розмістити, як сек’юрно зберігати, обробляти та розповсюджувати дані, кому який надавати доступ до якої інформації, думати про захист власного периметра, фізичний доступ, і купу інших організаційних, технічних та адміністративних питань.
І найважливіше: ключовим питанням у прийнятті рішення про створення будь-якого типу CERT є питання довіри.
Без довіри не буде вхідного потоку інформації про інциденти.
А без інформації про інциденти не буде що обробляти, про що повідомляти, взагалі не буде сенсу створювати CERT. Звичайно, має також бути жорсткий контроль за обігом інформації.
Але без початкової довіри не буде що контролювати.
Довіру не купиш і не намайниш. Її можна тільки заробити, роками чесної праці.
Навіть якщо у якомусь умовному Міністерстві у наказовому порядку зобов’язати звітувати про інциденти підлеглих або залежні установи та організації – теж не злетить. Буде як у Совку, коли усіх заганяли на партійні збори та на демострації.
Формально виконувати будуть, але неякісно і суто формально.
І тому абсолютно неефективно.
А "на кухнях" ще плюватимуться та матюкатимуть.
І ледь не забув: CERT має бути публічним. Тобто не тільки публікувати регулярні звіти, попередження, інструкції користувачам, гайди та корисні статті, але й оприлюднювати факти витоків інформації, вдалих атак, дефейсів, компрометації.
Визнавати косяки.
Не заперечувати та погрожувати кримінальним переслідуванням, а визнавати.
Дякуювати активістам за вказані помилки. Закликати «жги есчо». Оголошувати Bug Bounty, для початку можна не за гроші, а за публічну подяку.
Бо так набагато вигідніше для іміджу, а значить – для ступеня довіри. Про довіру написав вище.
Маю ще багато що розказати, але вже поки досить.
Яка з усього цього moral?
Є старий і вульгарний анекдот про автомобіль, вікно, лисицю, зайця та вовка. Там у кінці ключовий меседж: «Мдаа, не знаю як машину, а дверку точно куплю».
Так от, пафосно анонсуючи створення чергового міжгалактичного CERT, який враз вирішить усі проблеми кібербезпеки галузі, України, Землі та Галактики («а ось ми швиденько купимо дверку»), чиновники або нахабно брешуть, або легковажно помиляються.
Підзріло легковажно.
Сміливо пірнають у складний проект, не маючи уявлення – як і з чого то робиться.
За наші гроші, практично нічим не ризикуючи.
А якщо «не злетить», то нічого – ніхто відповідальності не нестиме.
То чому б не витратити (чи вкрасти?) 50-60 мільйонів гривень на халяву?
Створення розгалудженої мережі CERTів – це гарно і правильно, це еволюція, розвиток, підвищення рівня кібербезпеки кожного користувача, мережі, організації, кожного планшета.
Але робити це треба грунтовно, професійно та відповідально.
Не закидувати шапками, не поспішати, але й не гальмувати.
За міжнародними практиками, процес створення CERT «з нуля» у середньому займає біля 2 років.
На жаль, поки що цього не спостерігається. Спостерігаються лише спроби отримати гроші під модні ідеї.
Закінчити хотілося б цитатою з Закону України «Про основні засади забезпечення кібербезпеки України»:
"...Стаття 8. Національна система кібербезпеки
3. Функціонування національної системи кібербезпеки забезпечується шляхом:…
8) розвитку мережі команд реагування на комп’ютерні надзвичайні події; …"
Бережімося.
Костянтин Корсун
FB
реклама