Володимир Стиран, ІБ-спеціаліст — про пандемію Petya та шляхи уникнення повторних атак
Володимир Стиран займається кібербезпекою з 2005 року, є одним із засновників компанії Berezha Security. Спеціалізується на Penetration Testing, аудиті безпеки та ІБ-консалтингу, має сертифікати OSCP, CISSP, CISA.
В інтерв’ю для DOU Володимир розповів про нещодавній інцидент з поширенням вірусу Petya.С (саме ця назва вірусу є коректною. Petya.A — це торішній криптолокер, і спочатку АВ помилково детектили С як А, тому що є схожість — прим. ред.), способи протидії таким атакам та готовності української спільноти адекватно реагувати на загрози інформаційної безпеки.
— Володимире, як відбулось зараження і поширення Petya.C?
Було первинне зараження, потім вторинне просування мережею — класична атака компрометації ланцюжка поставок. Крім цього, могли бути випадки фішингу (особисто я підтвердження не маю), а також щонайменше одна атака відбувалася через зараження веб-сайту (т. з. Water-holing).
Ефектне поширення сталося через те, що на уражених машинах сесія користувача відбувалась з правами локального адміністратора — це дає змогу хакеру швидко пересуватись далі мережею. Скоріше за все, це відбулось шляхом запуску від імені адміністратора (через WMI та PsExec). Це тривіальна задача, яка збоку виглядає як цілком «легітимна» активність. В цей момент зупинити поширення в «неідеально» побудованій інфраструктурі вже майже неможливо.
Наразі дуже багато людей погоджуються з думкою, що це не кримінальна активність. Це не криптолокер, який вимагає гроші, адже його фінансова складова була поламана ще з перших годин його роботи. У комбінації із зразковою організацією первинного зараження та подальшого просування мережею, невдала організація логістики коштів виглядає, як на мене, вкрай нереалістично. Агенти загроз такого рівня могли припуститися цієї помилки навмисно, щоб мімікрувати під дії незграбного WannaCry та під маскою імітатора сховати справжню місію: атаку відмови в обслуговуванні в масштабах держави.
— Як можна протидіяти таким атакам?
По-перше, заборонити інтерактивний доступ в систему з правами адміністратора. Клієнтський код не повинен виконуватися з адміністраторськими привілеями — це був найкращий подарунок хакерам. По-друге, зробити повну сегментацію мережі залежно від бізнес-потреб робочих груп з фільтрацією вихідного трафіку навіть в локальній мережі — це дозволить вчасно зупинити та локалізувати поширення. По-третє, винести всі системи загального вжитку в хмари. І надалі — безперервно моніторити поведінку процесів на всіх системах. Додатково можна почати використовувати ЕЦП та шифрування в листуванні, і не лише в межах організації.
Звичайно, розробити стратегію створення резервних копій, робити своєчасні оновлення, застосовувати складні та довгі паролі, додати другий фактор автентифікації. Разом з цим — протидіяти кіберзагрозам з використанням соціальної інженерії. Вектор первинного поширення через електронну пошту — класичний. Грам обережності знижує ризик зараження в десятки разів.
За перші 2 доби з повідомленням про блокування комп’ютерів до кіберполіції звернулись більше 1500 фізичних та юридичних осіб. Загальна кількість заражених ПК в Україні перевищує 12 тисяч
Ті, хто приділяли достатню увагу безпеці, хоча б слідували безкоштовним стандартам та настановам, — або не постраждали взагалі, або постраждали локалізовано та змогли швидко зупинити інфекцію та відновити роботу.
Щодо власної безпеки, ми з колегами склали пам’ятку «Як не стати кібержертвою».
— Чи доцільно державним та комерційним установам переходити з Windows на Linux?
В даному випадку механіка поширення вірусу була розроблена під Windows як під найбільш масову платформу, але це нічого не означає. Можна створити інші інструменти під інші операційні системи, адже Linux та UNIX теж мають свої вразливі місця. Перехід на Linux ускладнить задачу зловмисникам, проте захищає від інфікування не платформа, а додержання настанов з інформаційної безпеки.
— Який урок ІБ-спільнота винесла з інциденту?
Ті люди, хто розуміється на ІБ, але раніше думали, що такого не станеться, тепер побачили, що є, до чого готуватись. Вони отримали нові дані, нові аргументи для того, щоб піти до свого гендиректора і наполягти на змінах в інфраструктурі.
А ті, хто з ІБ не знайомі, будуть і далі кожного разу лягати та в найкращому випадку відновлюватись з резервних копій.
— Чи багато в Україні спеціалістів, які професійно розуміються на інформаційній безпеці?
Спеціалістів достатньо, проблемою є відсутність попиту на їхні послуги. На жаль, в Україні не так багато компаній, які готові заплатити належну ціну за цю експертизу.
Наразі готовим до адекватної реакції на інфекцію не був майже ніхто, окрім деяких екзотичних випадків, на кшталт ПриватБанку, у якого вся продуктивна інфраструктура на Linux.
— Як індустрія розробки ПЗ може вплинути на розгортання ІБ?
Дуже в небагатьох компаніях програмісти та менеджери задумуються про ІБ. Треба навчатись, вивчати рекомендації та настанови, проходити курси, читати книжки. Можна розпочати з «Security Engineering» Росса Андерсона — це фундаментальна книжка про те, як будувати системи, які важко зламати. Також варто прочитати про те, як ламаються веб-додатки у «The Web Application Hacker’s Handbook». Є маса цікавих матеріалів та курсів, наприклад «Software Security» на Coursera від університету штату Меріленд. Всі, хто розробляють веб-додатки, мобільні додатки, веб-сервіси, можуть приєднуватися до OWASP — це глобальна організація, яка допомагає це робити безпечно. Можете перевірити, чи в вашому місті є її відділення, або створіть його самі.
Якщо дбати про безпеку на рівні розробки, не залишати «дірки», то і подальшим користувачам буде менше потенційних загроз. Ця конкретна пандемія могла й не відбутися, якби виконувалися настанови з ІБ.
Перший платіж на гаманець розробника Petya.C — проте, жоден з тих, хто відправив гроші, не отримав очікуваний ключ дешифрування
— Компанії краще мати окремий відділ з ІБ або ж навчати адміністраторів чи розробників?
Інформаційна безпека — це не антивірус і не фаєрвол. Це агрегатний стан: ви або в змозі триматися купи, або розтікаєтеся по підлозі. Щоб не розтектися, треба займатись ІБ. Спеціаліст з ІБ — це окрема професія, це не сисадмін чи програміст.
Так, досвідчені спеціалісти з ІБ коштують дорого. Можна взяти молодого і виростити, але вийде дорожче. Дешевше буде знайти досвідчених, які будуть допомагати розвиватись молодим.
— Що ще можете порадити щодо гарантування безпеки?
Варто розуміти, що ІБ — це відповідальність вищої виконавчої влади в корпорації. Можна делегувати функцію, але не можна делегувати відповідальність. Кіберполіція не прилетить і не врятує вас від хакерів. Сертифікат — це не доказ безпеки, це лише папірець. Безпека — це плюс один бізнес-процес та плюс один параметр кожного бізнес-процесу.
На ІБ треба виділяти бюджет. Не те, що лишилося від бюджету на розробку, а окремий бюджет, який ІБ-спеціалісти в змозі логічно обґрунтувати за допомогою оцінки ризиків та чинних норм законодавства. І не половину, не третину того, що вони обґрунтують, а весь.
Також слід пам’ятати, що ІБ-спеціалісти повинні займатись безпекою, а не лише писати RFP на тендери, щоб найняти інших виконавців. Звичайно, варто бути готовим до інциденту до того, як він настане. Досвідчені ІБ-спеціалісти здатні це забезпечити.
Окрім України, постраждали й інші країни Європи (source)
— Що ви думаєте про законопроект про кібербезпеку? Яке він має значення, чому він завис?
Я вважаю, що будь-яка законодавча ініціатива чи державне регулювання — в цьому випадку не дуже важливо. Воно має вимагати додержання стандартів та настанов і карати за бездіяльність. А щодо гарантування безпеки ПЗ — в нас і так є все необхідне для цього у відкритому доступі, і не треба чекати законів.
— Чи слід очікувати далі повторних атак подібного типу?
Так, я вважаю, що тепер такі загрози виникатимуть регулярно. Ми тепер дорослі, і нас вже б’ють в повну силу. На заході регулярно відбуваються атаки з експлуатацією довіри до третьої сторони, або так звані атаки на ланцюг поставок (Supply Chain Attack). Так були зламані Google та RSA, за мірками цієї галузі — вічність тому. У нас, та ще й в таких масштабах, цього поки що не бувало. Був деякий цільовий фішинг (Spear Phishing), який з натяжкою можна назвати APT (Advanced Persistent Threat).
Але рух ураженою мережею шляхом використання «легітимних» інструментів інфраструктури — це не VBA-форматовані пейлоуди в макросах та не експлуатація відомих вразливостей. Це вже інший рівень, і якби ми встояли, я б сприйняв це як комплімент. Але, на жаль, ми в нокдауні. А отже, треба встати, зціпити зуби та йти відновлюватися перед наступним раундом, який вже незабаром.
Дуже хочеться, щоб з цієї ситуації ми вийшли не на тендери з закупівлі антивірусів та фаєрволів, а на нормальні освітні програми для звичайних айтішників, які вже кілька діб не спали, відновлюючи хто з чого критичні для організацій дані. А мали б ввести кілька команд в консолі хмарного контролера та просто створити нові системи замість уражених, а уражені відправити на аналіз в лабораторію.
Нам потрібні прості та дієві вимоги держави та регуляторів до підприємств критичної інфраструктури, які б унеможливили спекуляції навколо того, хто ж винен в інциденті, дозволяючи всім і кожному ставити під сумнів точку зору та докази всіх. Потрібна масштабна кампанія з навчання нації тим речам, які могли б та мали б зробити досягнення мети інциденту якомога важчою.
