В одному з попередніх постів я писав про топ-5 способів зламу, які користувалися надзвичайною популярністю в минулому році. В цьому дописі мова піде про топ-5 способів захистити себе та своїх клієнтів, якими компанії могли б скористатися, але вперто не цього роблять.
1. Двохфакторна автентифікація.
Цей найпростіший спосіб радикально підвищити безпеку вперто ігнорують більшість компаній. “Фактор” автентифікації в перекладі з англійської означає “множник”. Тобто, додаючи до паролю другий фактор (скажімо, одноразовий код, який генерується мобільним додатком), можна умовно збільшити складність зламу системи удвічі.
Навіть сумнозвісні одноразові паролі з доставкою по SMS, якщо використовувати їх разом з звичайними паролями, а не замість них, — це просто колосальний приріст безпеки за доволі помірні гроші. А переважна більшість додатків та сервісів, особливо корпоративних, вже давно надає можливість увімкнути так звану двохетапну перевірку.
Та де там — такі вправи не для пересічних користувачів, а про клієнтів й мови немає — вони одразу ж від нас повтікають до конкурента, який не обтяжує їх введенням ще одного значення в веб-форму. Я вам більше скажу: у списку розсилки OWASP Leaders, в якій тусять керівники відділень та проектів OWASP, пару тижнів тому розгорілася дискусія про те, чи доцільно ввімкнути нарешті примусовий другий фактор у домені Google Apps цієї організації. Якщо серед лідерів OWASP знаходяться люди, які ставлять під питання необхідність цього заходу, то що вже казати про нормальних людей?
2. Вставка з буферу обміну в поле паролю.
Ось як буває, коли рішення щодо заходів безпеки приймають не менеджери, а програмісти. Соромно сказати, але в 2019 році на веб-сайтах деяких банківських установ користувачам все ще доводиться вводити пароль ручками. Парольні менеджери? Ні, не чули.
Замість того, щоб згенерувати собі складний та унікальний пароль з 20 символів та автоматично вставляти його у форму під час входу в систему, клієнт повинен страждати. Він повинен вигадувати пароль самостійно, зберігати його в голові, та вводити пальцями кожен раз, коли відвідує веб-сайт. При цьому, клієнт помилиться мовою вводу або натисне неправильні клавіші, заблокує свій обліковий запис, та піде із паспортом на уклін до відділення банку, щоб його розблокувати. Тому що таке вже в програміста було уявлення про безпеку.
3. Захист від фішингу.
Два прості кроки з захисту працівників від фішингу: ввімкнути анти-спуфінг електронної пошти (декілька заголовків DNS) та відмічати усі вхідні повідомлення, скажімо, словом EXTERNAL в полі Subject. Таким чином зловмисникам стане складніше підробляти електронні листи так, ніби вони надходять із ваших корпоративних поштових доменів, а фішинг з саморобних доменів та безкоштовних поштових сервісів привертатиме увагу позначкою про походження зовні.
Як соціальний інженер з багаторічним досвідом, я стверджую, що ці дії можуть убезпечити персонал від фішингових атак відсотків на 95, а решта 5 закривається тренінгом та “інцидентною практикою”. Проте, на жаль, багатьом організаціям набагато простіше звинуватити користувачів в тупості, обізвати прокладкою між кріслом та монітором, та налякати покаранням за кожне натиснуте посилання.
4. Відокремлення юзерів від адмінів.
Мені важко уявити умови, в яких в бізнес-середовищі користувачам можуть знадобитися права адміністратора в додатках та операційній системі. Тим не менш, в багатьох організаціях звичайним користувачам часто надають щонайменше права локальних адмінів на їхній робочій машині.
Звісно ж, так набагато простіше для всіх: адміни можуть розслабитись та рідше відриватися від “справжньої роботи”, а юзери можуть за потреби встановити собі потрібну програму або драйвер нового пристрою. Але це спрощення може стати причиною повної компрометації інфраструктури компанії в наслідок зламу всього одного робочого місця. І мені не відомі випадки, коли користувачів позбавляли підвищених привілеїв до того, як траплявся такий тотальний інцидент.
Тому що, ясна річ, у всіх “топів” на лаптопах та сама картина, а в разі чого хто винен? Та ніхто, бо як же ж від тих хакерів захиститись? Стихійне лихо…
5. Відокремлення мереж за призначенням.
Буквально всі організації починають будувати свої мережі не за принципом бізнес-необхідності, а з міркувань територіальної розподільності. Тобто, окремі мережі отримують київський, львівський та харківський офіси, а не окремі департаменти.
Це може здаватись логічним, але насправді є ще одним шляхом найменшого спротиву, який веде до компрометації. Адже різні підрозділи виконують різні функції, мають різні стосунки з зовнішнім світом, і наражають організацію на ризики різного рівня. Наприклад, ІТ-департамент довго обирає постачальника нового ІТ-рішення, потім місяці випробовує його в віртуальній лабораторії, після чого розгортає в ізольованій мережі та поступово відкриває до нього доступ іншим підрозділам. В той час, як департамент розробки програмного забезпечення повинен мати змогу протягом 10–15 хвилин розгорнути з шаблону нове середовище розробки та під’єднати його до власної мережі, мережі клієнта та дикого інтернету.
Звісно ж, в разі компрометації менш суворо захищеної мережі, коли між нею та іншими підмережами немає надійної політики контролю доступу, інцидент швидко поширюється в усі боки та бізнес зупиняється повністю. В той час, як у випадку правильної сегментації наслідки будь-якого проникнення можна обмежити рамками однієї бізнес функції.
Сподіваюся, ці рядки надихнуть когось переглянути своє ставлення до зазначених проблем та щось змінити в цьому світі. Але сподіваюся не дуже сильно, адже така ймовірність дуже мала. Принаймні до наступного глобального мережевого вірусу, який вкладе пів інтернету.
Бережіться.