Урядовою командою реагування на комп'ютерні надзвичайні події України CERT-UA, на виконання Закону України "Про основні засади забезпечення кібербезпеки України" серед іншого проводяться заходи, спрямовані на виявлення та протидію кіберзагрозам, a також надання практичної допомоги з питань усунення наслідків кіберінцидентів.
Зазначене передбачає безпосередню взаємодію фахівців CERT-UA з представниками державних органів, органів місцевого самоврядування, військових формувань, утворених відповідно до закону, підприємств, установ та організацій незалежно від форми власності.
Зазвичай така взаємодія полягає у дослідженні журнальних файлів, зразків шкідливих програм, інформаційних систем, електронно-обчислювальних машин з метою встановлення первинного вектору компрометації та прийняття відповідних рішень, спрямованих на недопущення реалізації зловмисного задуму та підвищення рівня інформаційної безпеки IKC.
За період з 01.01.2022 по 31.07.2023 CERT-UA вжито заходів з реагування більше ніж на 150 цільових кібератак деструктивного характеру. Здебільшого за умови сприяння суб’єкту координації та виконання наданих рекомендацій, реалізації зловмисного задуму вдалося запобігти. Разом з тим, не менше ніж на 35 об'єктах зловмисникам вдалося досягти поставленої мети.
Результати дослідження згаданих інцидентів дозволяють дійти висновку про те, що успішній реалізації зловмисного задуму сприяє не виконання типових вимог, що є актуальними для ландшафту кіберзагроз протягом останніх 7 років. Так, найбільш розповсюдженими векторами первинної компрометації є:
1. Відомі вразливості ("PHP", MS Exchange, FortiGate, Zimbra)
2. Скомпрометовані облікові записи (-> VPN -> LAN)
3. Спір-фішинг
4. Самоінфікування (операційні системи, пакети програм, завантажені з трекерів)
З метою вжиття релевантних заходів кіберзахисту CERT-UA підготовлено відповідну інфографіку. Зауважимо, що наведений перелік рекомендацій не є вичерпним і може оновлюватись. Крім того, в статті немає базових норм, таких як парольна політика, обмеження прав облікових записів користувачів, своєчасне оновлення програмного забезпечення, уникнення використання застарілих операційних систем тощо, що в свою чергу не виключає необхідності їх дотримання.
Незважаючи на категорію обʼєкта, відповідальність за забезпечення захисту інформації в системі покладається на власника системи.
У зв'язку з викладеним вкотре наголошуємо на персональній відповідальності керівників, системних адміністраторів, адміністраторів інформаційної безпеки, а також осіб, які обіймають посади, пов'язані з безпосереднім виконанням завдань із забезпечення кібербезпеки та кіберзахисту, та закликаємо невідкладно врахувати в роботі надані рекомендації.
Наскільки велика "поверхня атаки" (attack surface) у вашій організації?
Зменшення кількості інформаційних систем та сервісів ("відкритих мережевих портів"), що доступні з мережі Інтернет підвищує захищеність периметра. Скористайтеся інструментами: censys.io, shodan.io, Nmap та перевірте свою поверхню атаки або зверніться за допомогою [1].
Чи використовуєте ви багатофакторну автентифікацію (2FA)?
Доступ до корпоративних ресурсів, особливо VPN та MAIL, повинен передбачати використання двофакторної автентифікації за одноразовим (OTP) кодом. В іншому випадку, викрадення логіна/пароля/сертифіката гарантуватиме отримання несанкціонованого доступу до пошти і/або локальної мережі.
"Демілітаризована" зона (DMZ)
Інформаційні системи, які передбачають доступ з мережі Інтернет та розгорнуті в межах периметру ІКС організації (WEB, MAIL, etc) повинні знаходитись в DMZ. При цьому умовна компрометація будь-якого з елементів такої системи не повинна створити передумов для розвитку атаки вглиб локальної мережі і/або у відношенні інших активів.
Чи обмежено віддалений/адміністративний доступ?
Віддалений доступ (наприклад, RDP) і особливо доступ до інтерфейсів адміністрування серверного та мережевого обладнання має бути дозволений для конкретних користувачів з визначених робочих місць (IP-адрес). Фільтрація інформаційних потоків здійснюється засобами штатних (хостових) і окремих міжмережевих екранів, а також інших механізмів (наприклад, TCP Wrappers).
Фільтрація вихідних ("egress") інформаційних потоків?
Доступ користувачів до ресурсів мережі Інтернет має бути реалізовано через міжмережевий екран (проксі-сервер) з підтримкою автентифікації та з обмеженням за типовими портами. Можливість встановлення вихідних мережевих з'єднань із серверного обладнання (в т.ч. DMZ) має бути відсутня або обмежена за принципом "заборонено все, що явно не дозволено" з урахуванням мінімальної необхідності.
Функціонуючі програмні засоби захисту: на ПК та серверах
Чи знаєте Ви, що означають події з ідентифікаторами 1116, 1117 в журналі Windows Defender? Чи налаштовано "антивіруси" на серверах? Чи маєте змогу централізованого моніторингу та керування засобами захисту?
Чи знаєте, що для засобів захисту ESET розроблено дієві правила HIPS [2]?
Імплементація рекомендованої політики, що складається з 7 правил, дозволяє радикально зменшити вірогідність успішної реалізації найбільш поширених методів первинної компрометації. Дізнайтеся у вашого вендора про наявність аналогічних політик для відповідного засобу захисту.
Контроль програм, у т.ч. легітимних утиліт
Для здійснення кібератак дедалі частіше використовуються штатні компоненти операційної системи. Можливість запуску звичайними користувачами таких утиліт повинна бути обмежена: wscript.exe, cscript.exe, mshta.exe, powershell.exe. Кращою практикою є використанням AppLocker на основі білого списку.
Невже розмір журналів на ваших Windows-серверах складає 21МБ?
За замовчуванням розмір основних журналів Windows (Security, System, Application) обмежено 21МБ, чого вистачає для реєстрації подій протягом декількох останніх годин. Типовий розмір журналів рекомендовано підвищити до 2ГБ. Крім того, використання інструменту Sysmon надасть значних переваг [3].
Уявна кібератака: чи є "логи" для дослідження?
Одна з проблем під час реагування - відсутність і/або недостатня повнота і часова ємність журнальних файлів. Рекомендовано зберігати журнали подій протягом 180 - 360 діб, для чого доцільно розгорнути окремий syslog-сервер; налаштувати формат часу згідно RFC3339. Звертаємо увагу, що на pfSense/Mikrotik за замовчуванням розмір логів значно обмежено.
Будьте готові до "ізоляції"
Якщо завтра ви отримуєте нотифікацію щодо присутності зловмисників у мережі - чи готові до заборони вхідних та вихідних інформаційних потоків за умови забезпечення контрольованого функціонування критичних підсистем? Чи передбачена, при цьому, можливість виконання технічних робіт, у т.ч., в режимі віддаленого доступу?
Маєте можливість оперативного обміну інформацією із CERT-UA?
Під час реагування на інцидент значна кількість часу витрачається на пошук контактів та організацію взаємодії. Зв'яжіться із CERT-UA заздалегідь, організуйте канали зв'язку, надайте ідентифікатори вашої ІКС та активів для додаткового моніторингу та своєчасного інформування.
Щодо інцидентів у відповідних секторах також можуть допомогти:
ЗСУ:
СБУ:
НБУ:
За інформацією CERT-UA