Кібертероризм в сучасному світі: як завадити фішингу, вірусам та іншим загрозам

Усім привіт! Мене звати Олександр Циганов, я працюю на позиції Cyber Defense Engineer в компанії Apriorit впродовж майже трьох років. В цій статті хочу обговорити одну з найчутливіших тем інформаційної безпеки корпоративного і державного рівнів — кібертероризм, що з ним роботи з технологічного боку і як можна йому протидіяти.

Трохи про явище кібертероризму

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

Атаки на засоби масової інформації та системи звʼязку

За ідеальних умов і за ідеальної реалізації подібні атаки повністю паралізують звʼязок в країні (мобільний та інтернет), а також унеможливлюють теле- і радіомовлення, в результаті цивільне населення залишається дезорієнтоване в інформаційному вакуумі.

Атаки на обʼєкти критичної інфраструктури (енергетичні системи, транспорт, комунікації тощо)

Можуть використовуватися у будь-який період — як у мирний час (за відсутності явних бойових дій між сторонами) так і під час війни, і мати політичні, економічні, військові мотиви.

Однією з перших подібних атак, що набула публічного розголосу, була та, про яку знято кілька документальних фільмів, найвідоміші з яких — Cyberwar (2011) та Zero Days (2016). У них йдеться про те, хто і як створював шкідливе програмне забезпечення, як і для чого його використовували та які наслідки це мало для усіх сторін-учасників.

Інструменти кібертероризму

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

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

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

Cyber Kill Chain model

Усі кібератаки (а разом з ними й акти кібертероризму) покриваються ланцюгом гакерського ураження. В деяких випадках його можна скоротити на 1-2 пункти залежно від події, але принцип від того не змінюється. Очевидно, що чим менше стадій вдалося пройти зловмиснику, тим краще для нас.

Способи протидії

Таким чином ми переходимо до відповіді на закономірне питання «Як захистити себе, близьких або компанію від цих загроз». Якщо коротко — ніяк. Але не поспішайте робити передчасні висновки, зараз зі всім розберемося по черзі.

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

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

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

1. Захист зовнішнього периметра

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

До зовнішнього периметра відноситься усе, що стосується вас як компанії (або персонально, якщо у вас, наприклад, з якоїсь причини статична публічна IP-адреса — іншими словами, білий IP), що доступне з мережі інтернет напряму за IP-адресою або доменним імʼям:

1. Сайт.
2. Шлюзи внутрішньої інфраструктури.
3. VPN-сервер.

Цей перелік невичерпний і у кожного може бути свій список таких активів.

Наступним кроком буде встановлення переліку сервісів, які працюють на зовнішньому периметрі.

Для усіх мережевих сервісів я б виділив спільне правило.

В ідеалі необхідно, щоб кожен сервіс використовував конкретний мережевий інтерфейс (або групу інтерфейсів в разі необхідності), але щоб сервіси не використовували таку адресу як 0.0.0.0 або :: (що власне одне й те саме, але для IPv4 та IPv6 відповідно).

Будь-які мережеві сервіси, які очікують запитів і «слухають» певний порт за замовчуванням налаштовані так, що «слухають» вони трафік на усіх мережевих інтерфейсах, тобто їм встановлюється значення 0.0.0.0 та/або :: (що дослівно означає будь-який інтерфейс).

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

Також на мережевому рівні використовується брендмауер або, як його ще називають, файрвол. Якщо коротко, то налаштовується він також за принципом мінімальних привілеїв — забороняємо увесь трафік за замовчуванням і дозволяємо лише той, що буде потрібен для роботи сервісів. Про налаштування файрволів можна розповідати дуже довго і багато, але найпростіший і, як на мене, найефективніший алгоритм дає CIS (center for internet security) у своїх плейбуках для налаштування операційних систем.

Наведу приклад семплу, який я міг би рекомендувати за основу для використання (конфіг буде для iptables, але його можна адаптувати й для інших файрволів):

#!/bin/bash 
# Flush IPtables rules 
iptables -F 
# Ensure default deny firewall policy 
iptables -P INPUT DROP 
iptables -P OUTPUT DROP
iptables -P FORWARD DROP 
# Ensure loopback traffic is configured 
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -s 127.0.0.0/8 -j DROP 
# Ensure outbound and established connections are configured
iptables -A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p udp -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p icmp -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -p udp -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -p icmp -m state --state ESTABLISHED -j ACCEPT

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

Для збереження конфігурацій після перезавантаження сервера є чудове рішення у вигляді netfilter-persistent. Командою netfilter-persistent save можна зберегти поточний конфіг і після ребуту ваш конфіг буде відновлено. Для зручності можна обʼєднувати подібні правила у скрипти й зберігати десь в закритому репо, до якого матимуть доступи ваші системні адміністратори, наприклад.

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

2. Defense in Depth

Першим чи не найпоширенішим сервісом я б виділив віддалений доступ. Це стосується як вінди з її RDP, так і UNIX-подібних систем з SSH та VNC. Ці сервіси за своєю сутністю прості і їх основна функція — надати нам віддалений доступ до віддаленого пристрою. Так, RDP та VNC дозволяють мати доступ до графічного інтерфейсу системи (хоча функціонал SSH дозволяє робити X11 forwarding і це працюватиме приблизно аналогічно VNC), але серед ризиків для безпеки суттєвих відмінностей тут не буде.

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

Щоб вашій інфраструктурі не докучали постійним брут-форсом для unix-подібних систем є прекрасне рішення у вигляді fail2ban. Сервіс зчитує кількість невдалих спроб авторизації й джерело (IP адресу). В разі досягнення певних показників частоти з однієї адреси, вона блокується. Конфіги дозволяють налаштувати як кількість невдалих спроб, так і термін блокування.

Must have, бо якщо хтось захоче цілеспрямовано вас брутити блокуванням двох-трьох IP-шників ви не обмежитесь (proxychains у звʼязці з будь-яким софтом для бруту паролів дозволяє на льоту змінювати джерело запитів). Для windows існують IPbanPro. За альтернативу можна додати Windows-компʼютер(и) або сервери в домен і блокувати користувача на домен-контролері, але тут від трафіку ми все одно нікуди не діваємося, на жаль. Оптимально буде не дозволяти RDP бути доступним ззовні в цілому.

Щодо налаштувань безпосередньо сервісів віддаленого доступу: якщо вам необхідно коректно і безпечно сконфігурувати сервіс для корпоративних потреб, то одразу раджу звернутися до CIS з їх бенчмарками. Вони написані досить лаконічно і відносно просто для сприйняття.

Я, своєю чергою, зазначу лише найважливіші на мою думку пункти, які мають бути налаштовані у кожного (особливо варто звернути увагу читачам, хто користується VPS-ками з віртуалками).

Почнемо з SSH:

1. Заборона на авторизацію від імені привілейованого користувача (root). В разі компрометації пароля (не принципово, в який спосіб) можливість підʼєднатися одразу з максимальними привілеями дає зловмиснику повний контроль над сервером, що може мати найрізноманітніші наслідки (від компрометації даних, які на ньому зберігаються до захоплення повного контролю з подальшим розвитком атаки на інші елементи мережі). Для цього достатньо у файлі конфігурацій /etc/ssh/sshd_config встановити значення параметра PermitRootLogin no. Таким чином навіть за правильної комбінації кредлів авторизація все одно зафейлиться.
2. Зміна стандартного порту ускладнює виявлення сервісу. Встановлюємо будь-який зручний порт після 1024. Для корпоративного сегмента буде оптимальним прописати окремим документом, який сервіс на який кастомний порт було перенесено, щоб за необхідності отримання доступу по тому ж SSH ніхто не ломився на 22-й порт, на якому нічого немає. Для зміни порту в тому ж файлі /etc/ssh/sshd_config є однойменний параметр Port, який приймає числове значення — номер порту, на якому працюватиме сервіс. Через один рядок в цьому ж файлі є параметр ListenAddress, який дозволить ізолювати сервіс, щоб він працював на конкретно обраному мережевому інтерфейсі (їх можна вказувати безмежну кількість — актуально у разі використання кількох сервісних підмереж або ж існує необхідність доступу до ресурсу у кількох окремих команд, у яких окремо виділені підмережі).
3. Тайм-аут сесії. У випадку несанкціонованого доступу до середовища зловмисник може спробувати залишити сесію в активному стані, щоб не компрометувати себе авторизаціями з незвичних джерел. Також це дозволить запобігти зайвим помилкам в самому оточенні. Для налаштування у файлі /etc/ssh/sshd_config за потреби розкоментовуємо параметр LoginGraceTime і встановлюємо значення 60.
4. Авторизація за ключем. Особливо актуально для систем, авторизація на яких з тих чи інших причин виведена на зовні або в потенційно агресивне середовище (на кшталт, того ж DMZ) і ніяк не може бути змінена або прихована. Також доволі зручно для тих, хто використовує VPS або має хмарну інфраструктуру для власних потреб і окрім вас особисто доступ туди нікому не потрібен. Залишу посилання на зручний на мою думку мануал від Digital Ocean.
5. 2FA — досить спірне рішення, оскільки може нести за собою певні незручності при авторизації, якщо у вас, наприклад, до ресурсу доступ має одна-дві команди по три-п’ять людей. Потребу в таких засобах захисту оптимально буде проаналізувати команді з інформаційної безпеки. В разі, якщо ви єдиний власник і єдиний, хто має мати доступ до середовища, то не бачу причин, щоб проігнорувати додатковий фактор захисту вашого середовища. Знову ж таки, посилання на мануал з налаштування.

Наступний на черзі RDP:

1. Вимкнути вбудований обліковий запис адміністратора. Одна з найперших обліковок, яку пробують збрутити. У вас може бути безліч обліковок з правами адміна, але якщо зловмисник не знатиме, які в них імена (а тим паче якщо всі облікові записи у вас ще й доменні), то атака перебором дуже втрачає за своєю ефективністю (помножте кількість можливих логінів в словнику — нехай це буде навіть 100 — на кількість можливих паролів нехай це близько кількох сотень тисяч, кількість спроб вже вимірюється десятками мільйонів, також додамо сюди вимкнену дефолтну обліковку адміна і політику побудови логінів і паролів).
2. Імена облікових записів. Варто уникати таких дефолтних імен, як user, admin, administrator, різні імена в транслітерації та похідних від них. Причини були описані в попередньому пункті.
3. Приховування попередньо авторизованих користувачів. Їх необхідно приховати, щоб в разі необхідності мати RDP в потенційно небезпечному оточенні (або при наявних пробросах портів назовні) зловмисник не зміг сформувати словник з іменами облікових записів під конкретну цільову систему. Про те, як це налаштувати, є інструкція.
4. Обмежити користувачів, кому дозволено використовувати службу віддаленого доступу. Якщо віддалений доступ потрібен локальному обліковому запису для тестів, то це не означає, що він потрібен і обліковому запису з адмінським доступом. Тому варто розмежовувати користувачів за їх призначенням і видавати їм відповідний рівень доступу (це стосується не тільки використання RDP, а й доступу до файлів). Таким чином навіть при вдалому підборі кредлів до привілейованого облікового запису зловмисник не матиме змогу авторизуватися під ними, оскільки це буде заборонено налаштуваннями системи.

VNC сам по собі більш захищений «з коробки», ніж той самий RDP, тому рекомендації стосовно його використання будуть більш поверхневі:

1. Ефективний user-management — аналогічно з RDP та SSH. Доступ має бути в обмеженої групи осіб, а також відповідне розмежування прав для користувачів, від імені яких користувач підʼєднується до сервера.
2. Парольна політика — захист від перебору паролів, про який згадувалося вище.
3. 2FA — з усіма «але і якщо», про які була мова в попередніх пунктах.

Другим досить поширеним сервісом я б хотів відзначити вебсервер. Якщо ви плануєте розгортати у себе якийсь сервіс, який взаємодіятиме з користувачем, с високою долею вірогідності це буде apache або nginx (за виключенням сервісів, які мають кастомні рішення, та й вони, як правило, засновані на чомусь з вищезгаданих зразків).

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

1. Прибрати трансляцію версії вебсервера. За замовчуванням вебсервери транслюють свою версію. Наявність точної версії сервісу дозволяє зловмиснику легше зорієнтуватися, знайти відомі вразливості й підібрати експлойт, якщо він вже є в публічному доступі. Для наочності — контейнери з nginx та apache в стоковій конфігурації для демонстрації того, як просто дізнатися версію сервісу, навіть якщо на дефолтній сторінці ви не бачите номера конкретної версії:

Дефолтна сторінка вебсервера nginx

Результат простого скану вебсервера на його версію

Дефолтна сторінка вебсервера apache

Результат простого скану вебсервера на його версію

2. Автоматичний редирект HTTP -> HTTPS. І не важливо, чи це прод, який доступний для усіх ззовні, або це якийсь ваш внутрішній сервіс. Близько 80% трафіку всієї мережі інтернет передається у зашифрованому вигляді (за HTTPS) і вже існують технології для його дослідження. Джерела чутливих даних в разі їх передачі у відкритому вигляді як взагалі це прямо найпростіший спосіб, як втратити обліковий запис.

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

3. WAF хоча б для ресурсів, які використовуються в публічному доступі. За коректної конфігурації він здатний закрити досить багато питань безпеки вебресурсу. Від DoS/DDoS-атак до різного роду інʼєкцій. Найпопулярнішим рішенням наразі є Cloudflare WAF, але не Cloudflare-ом єдиним. Якщо у вас є вендор, який пропонує аналогічне рішення і ви йому довіряєте — welcome, як то кажуть.

Оскільки у багатьох компаній, держустанов є власні інтернет-ресурси, вони цілком можуть стати цілями для завдання як репутаційних, так і фінансових втрат.

Безпеку вебзастосунка на мережевому рівні та рівні вебсервера ми розглянули на попередніх етапах, тому на останок розглянемо менш очевидну складову майже будь-якого вебдодатка — систему управління контентом (CMS) і розглянемо їх безпеку на прикладі WordPress (як би хто скептично до нього не ставився).

Серцем будь-якої CMS є її адмінпанель. Тому насамперед, щоб трохи ускладнити життя зловмисникам варто змінити стандартний шлях до цієї панелі. WordPress для цього має спеціальні плагіни на кшталт WPS Hide login.

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

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

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

Певно, ви помітили, що я досить велику увагу приділив саме конфігурації сервісів та розмежуванням доступів. Це дійсно вагомі фактори безпеки як вашого власного, так і корпоративного інформаційного середовища, оскільки «поламані» доступи займають перше місце в рейтингу OWASP TOP 10 серед ризиків для вебдодатків, помилки в конфігураціях своєю чергою займають п’яте місце у цьому рейтингу.

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

1. Перевіряємо усі сервіси, які працюють на сервері.
2. По кожному шукаємо рекомендації по налаштуваннях від CIS або найпопулярніші вразливості та як їм запобігти.
3. Налаштовуємо згідно з мануалами та з поправками на ваші власні або корпоративні потреби.

3. Vulnerability assessment

Коли вже згадали про OWASP top 10, хотів би звернути увагу на шосту позицію цього топу, а саме — Vulnerable and Outdated components. Це усім нам відомі твердження про постійні оновлення системи та ПЗ, яке використовується на ваших серверах або віртуальному оточенні.

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

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

Windows-системи дозволяють досить тонко налаштувати параметри оновлення системи включно з часом для перезавантаження з допомогою локальних або групових політик:

Локальна політика з автооновлень Windows

З Linux-системами може бути трохи складніше, оскільки централізовані інструменти для автоматичного оновлення систем не настільки зручні як політики на Windows. На допомогу може прийти хіба що Ansible. Для автоматичного оновлення Debian-based-дистрибутивів на допомогу приходить unattended-upgrades. Цей пакет дозволяє тонко налаштувати, які оновлення будуть встановлюватися на ОС і з якою регулярністю. Посилання на документацію з налаштування для Debian. І аналогічно для rpm-based.

4. Моніторинг

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

Можна вважати, що є необхідність в трьох окремих технологіях. Моніторинг стану інфраструктури покриває Zabbix:

Zabbix Archtecture

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

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

Технічних рішень для подібних цілей на ринку достатньо, однак більшість з них буде платною. Загальна архітектура подібних рішень виглядає наступним чином:

Network Analysis Architecture

І на останок — збір та аналіз логів. Як на мене, для подібних цілей більш оптимально використовувати SIEM (security information and events management) або SOAR (security orchestration, automation and response) системи (рішення для останніх загалом платні).

SIEM-рішення дозволяють окрім збору усіх логів з усього заліза та віртуального оточення, яке у вас може бути у використанні (в тому числі й хмарні рішення), також аналізувати їх на предмет підозрілої або шкідливої активності на базі правил та алертингу.

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

До недоліків я б відніс трудомісткість процесів розгортання, налаштування та підтримки подібних систем. Це пов’язано з тим, що той самий Zabbix або SIEM/SOAR-рішення працюють за agent-based-архітектурою (за поодиноким виключенням для SIEM, коли SIEM-сервер виступає як віддалений лог-колектор).

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

Також до складнощів я б відніс сам процес моніторингу. Постійно 24/7 спостерігати за графіками у більшості не буде можливості (тільки якщо у вас немає dedicated SOC-команди). Тут виникає закономірне рішення про миттєві сповіщення в корпоративний месенджер в разі підозрілої активності, що знову ж таки нас повертає до питання конфігурації моніторингу. Цей процес не дивлячись на свою трудомісткість є неодмінною частиною забезпечення безпеки будь-якої інфраструктури та обійтись без нього, на жаль, не вийде.

5. Протидія атакам, повʼязаним з нетехнічними факторами

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

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

Наочним прикладом буде завантаження і відкриття зараженого додатка або перехід за злоякісним посиланням (воно може не обов’язково вести на фішинговий сайт, це може бути посилання на цілком легітимний сайт, який до цього був модифікований таким чином, щоб вкрасти дані у користувача).

Іншим прикладом може бути підкинута флешка зі злоякісним наповненням. Такі флешки можуть як мати на борту злоякісне ПЗ, яке встановлюватиметься в автоматичному режимі одразу при підключенні флешки до ПК, або це може бути банальний USB-killer (трохи не вписується в контекст кібертероризму, але завдати шкоди компанії на рівні хуліганства цілком можливо). Це та сама флешка, але замість блоків памʼяті на ній напаяні конденсатори, які заряджаються від USB-порту, після чого миттєво віддають накопичений заряд, чим часто завдають фатальної шкоди материнській платі або іншим компонентам пристрою.

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

Тут рекомендації прості та всім давно знайомі.

1. Ні в якому разі не відкривати невідомі посилання, отримання яких ви не очікували, а особливо які ніяк не пов’язані з вашою діяльністю.
2. Не завантажувати документи, картинки або якісь інші вкладення до листів, а особливо яких ви не чекали і які не в’яжуться з вашою професійною активністю.
3. Не підбирати невідомі флешки та блоки живлення (якими ми зазвичай заряджаємо свої девайси) і тим паче не використовувати їх ні з власними, ні з корпоративними девайсами.
4. Будьте вкрай обережні з позичанням своєї електроніки (флешки, блоки живлення) іншим людям. Ризики того не вартують.

Висновок

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

Рядову атаку в ранг теракту переводять лише масштабність наслідків, збитки, які вдалося нанести, й суспільний резонанс (теракти як такі на нього і розраховані).

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті