Уроки року боротьби з порушеннями інформаційної безпеки



У 2016 році у мене було дуже багато завдань, пов'язаних з реагуванням на інциденти інформаційної безпеки. Я витратив на них в загальній складності близько 300 годин, самостійно виконуючи необхідні дії або консультуючи фахівців постраждалої сторони. Матеріалом для статті послужили мої записи, зроблені в процесі цієї роботи.
Централізоване логування
Підзаголовком цього розділу може послужити такий питання: «Чим стандартний інцидент відрізняється від катастрофи?»
Хороше або погане ведення логів визначає подальшу роботу з інцидентом. Я кожен раз на практиці переконуюся, що журнали аудиту є фундаментом хорошої політики безпеки і ефективного реагування на порушення ІБ (інформаційної безпеки).
Починаючи роботу з інцидентом, я першою справою намагаюся зрозуміти, чи можна покластися на логи потерпілої сторони. Від отриманої відповіді залежить успіх усієї кампанії. На щастя, CI/CD/DevOps-культурі використання централізованих систем ведення журналів та оповіщення стає стандартом. Я вже почав розраховувати на те, що створена в останні три роки компанія надасть мені велика кількість даних, придатних для аналізу.
Якщо ви з тих чи інших причин відкладаєте модернізацію своєї системи ведення журналів, настійно рекомендую пожертвувати всім, чим тільки можна, але постаратися інвестувати в якісну журналювання. Треба прагнути до того, щоб отримувати якомога більше логів і зберігати їх у якомога меншій кількості місць.
Дуже важливо вести журнали хостів, додатків, подій аутентифікації і дій з хмарної інфраструктурою. Ця інформація допоможе у розслідуванні інцидентів, проведення профілактичної роботи і буде корисна іншим командам, наприклад, для оцінки доступності сервісів.
При налаштуванні журналювання не забувайте про конфіденційність користувачів, а також необхідних і достатніх терміни зберігання даних в журналах. Загальною практикою є зменшення цих термінів (але багато що залежить від специфіки створюваного продукту).
Висновок: добре оформлені, доступні, централізовані та корисні з точки зору генерації тривожних повідомлень логи краще поставити в пріоритет перед іншими проектами ІБ. А новий тип оповіщення, якщо все зроблено правильно, повинен потрапляти у production протягом десяти хвилин.
Ви можете так і не дізнатися основну причину злому
Кілька інцидентів, з яким я працював у минулому році, закінчилися тим, що первісний спосіб проникнення так і не був знайдений.
Це справжній кошмар для фахівців постраждалої сторони, які повинні проінформувати керівництво про вжиті кроки, на ділі не базуються на достовірній інформації. Локалізація проблеми стає неповною і проводиться за принципом «зробили все можливе».
Якщо відома основна причина, план з мінімізації наслідків виглядає приблизно так: «Ми вичищаємо цей ноутбук, замінюємо цей сервер, блокуємо один обліковий запис».
В іншому ж випадку: «Ми чистимо ВСІ ноутбуки, замінюємо ВСІ сервера, блокуємо ВСІ закладки.
Знаходження основної причини інциденту — важлива віха, визначає емоційну атмосферу, в якій буде проходити подальша робота. Ця причина може суттєво впливати на кінцевий результат.
До тих пір, поки основна причина інциденту не знайдена, в команді буде наростати напруженість, яка може призвести до внутрішніх конфліктів. Я намагаюся не допускати подібних ситуацій. Пам'ятаю випадки, коли буквально одна розмова на підвищених тонах відділяв команду від загальної паніки, взаємних звинувачень і масових звільнень за власним бажанням.
Незалежно від того, якого розміру ваша компанія, дуже важливо «розподіляти ролі» для членів команди і періодично відпрацьовувати взаємодію під час кризи.
Висновок: проводьте регулярні штабні навчання і тести на проникнення. Відпрацьовуйте будь-яку знайдену уразливість як повноцінний інцидент. Практикуйте сценарії, в яких ви не керуєте ситуацією, не всеведущи, не маєте потрібних логів і не розумієте, що відбувається. Не упускайте можливість тренувати навички боротьби в партері з положення «лежачи на лопатках», так як в реальності сторона, що захищається, часто починає свої найважливіші сутички саме в цій позиції.
Будинок під прицілом
Фраза «Bring your own device» часто використовується, щоб категорично описати ризики, які співробітники в буквальному сенсі слова «приносять» на роботу. Однак дуже часто персонально спрямовані атаки під це визначення не підпадають.
Багато хто пам'ятає недавню історію з групою APT, коли хакери атакували особисту пошту та пристрої співробітників. Якщо там зберігаються ключі і паролі або з цих пристроїв здійснюється доступ до корпоративних ресурсів, вже не має значення, приносять їх в офіс чи ні.
Неймовірно складно оцінити масштаб загрози інформаційної безпеки компанії, яку представляють домашні пристрої співробітників, оскільки навіть після інциденту, що люди неохоче діляться особистою інформацією, що ускладнює розслідування. Загальною тенденцією є використання однакових паролів для домашніх і корпоративних акаунтів, а також зберігання своїх робочих облікових даних на особистих пристроях, в тому числі і на тих, які не використовуються для доступу до корпоративних ресурсів.
Також варто згадати інцидент, при розслідуванні якого виникли серйозні підстави вважати, що один з інженерів з метою віддаленого налагодження зберігав важливі облікові дані в особистому хмарної інфраструктури.
Необхідно враховувати і той факт, що перевірка пристроїв може виявитися занадто неприцільної і дорогий, і це також доводить важливість збору якісних логів.
Висновок: знаходьте способи підвищити домашню інформаційну безпеку співробітників. Сплачуйте використання менеджерів паролів, обладнання для багатофакторної аутентифікації і т. д. Переконуйте, що вони повинні залучати співробітників відділу інформаційної безпеки, якщо у них виникли проблеми із забезпеченням особистої ІБ або вони помітили якусь підозрілу активність, навіть не пов'язану з роботою. Вчіть співробітників стежити за безпекою членів їх сімей і в разі необхідності допомагайте в цьому питанні.
Ваші биткоины в небезпеці, навіть якщо у вас їх немає
Інтеграція використовуваної платформи з биткоин-компаніями ставить вашу інформаційну безпеку під загрозу. Для більш докладного вивчення питання можна почитати Blockchain Graveyard і SendGrid's blog.
Висновок: якщо ви сильно залежите від технологій партнерів, знайдіть спосіб убезпечити себе. Якщо ви биткоин-компанія, доведіть свою параною до крайнього ступеня загострення і прийміть екстраординарні заходи з обмеження доступу до систем партнерів.
Витончені методи злому
В минулому році багато повідомлень про зломи згадували «висококваліфікованих хакерів», які далі починали критикувати за тривіальний спосіб проникнення.
Багато атаки починаються з фішингу, куплених експлойтів, злитих ключів та деяких інших очевидних і порівняно легко предотвращаемых способів злому.
насправді «витончена» частина зазвичай докладно не обговорюється. Занадто легко вказати на «дилетантський» вектор атаки і проігнорувати все інше.
Але не судіть противника щодо його першого кроку. Він може показати, що таке «витонченість», розвиваючи напад з плацдарму, завойованого простими методами.
Наприклад, початковий вектор атаки може і не представляти особливого інтересу, але способи, з допомогою яких атакуючий отримав доступ або облікові дані, зламавши сторонню платформу, можуть багато чого сказати про вмотивованість і кваліфікації вашого супротивника.
Наприклад, назвав би Lockheed методи їх злому в 2011 році витонченими, навіть враховуючи, що нападники добре підготувалися, вкравши дані RSA SecureID? Якщо атака почалася зі звичайного фішингу, чи означає це, що противник слабкий?
Висновок: висококваліфіковані хакери, починаючи вторгнення, не грають м'язами. Не робіть помилку: не варто недооцінювати початкові незграбні спроби злому. Можливо, атакуючий просто хоче добитися результату мінімальними зусиллями. За черговий черговою спробою фішингу може послідувати новий 0Day.
Керуйте своїми обліковими даними і ключами
Управління конфіденційними даними є важливим фактором інформаційної безпеки.
У минулому році мене не залучали до роботи з інцидентами в компаніях, які застосовують рольові моделі доступу і керуючих конфіденційними даними за допомогою спеціального сховища.
Це може означати наступне: таких компаній не існує, їх мало, або вони не стикаються з інцидентами, гідними залучення спеціаліста з реагування на інциденти.
У процесі роботи я постійно був свідком випадків, коли ключі прописувалися у вихідному коді, витікали в хмарні платформи логування, небезпечно зберігалися на персональних пристроях співробітників або копіювалися в gist і pastebin. Всі перераховані вище помилки ставали як першопричиною зломів, так і посилюють фактором (звичайно, якщо атакуючому вдавалося заволодіти цими даними).
Висновок: подивіться на ролі AWS, не вбивайте ключі і паролі у вихідний код, не давайте розробникам реквізити доступу до бойових систем і будьте готові розгортати їх швидко і часто.
Крадіжка облікових даних до цих пір є однією з найбільш простих завдань
В організаціях, якісно інформують користувачів (особливо керівництво) про небезпеку повторного використання паролів, тим не менш сталося кілька інцидентів. Ці інформаційні повідомлення, якщо тільки вони не були адресовані особисто певним працівникам, втрачали силу, коли справа доходила до персональних облікових записів.
Підвищення обізнаності може відстрочити неминуче, але набагато ефективніше виявляється впровадження системи управління обліковими даними на базі провайдера ідентифікації, а також інтеграція технології Single Sign On у хмарні рішення. Мені не доводилося стикатися з інцидентами, при яких би був зламаний механізм MFA, що використовується в рамках корпоративного рішення по ідентифікації користувачів.
Якщо Single Sign On не варіант, використання MFA скрізь, де це тільки можливо, сприяє мінімізації ризиків. Окремо згадаю GitHub, оскільки розробники часто зберігають конфіденційні дані у вихідному коді. В цьому випадку в якості тимчасової міри можна застосувати примусову багатофакторну аутентифікацію, поки для ключів, паролів та інших секретних даних не знайдеться відповідне сховище.
Загальні риси інсайдерських загроз
У минулому році мені потрапило зовсім небагато пов'язаних з інсайдерами завдань. В усіх випадках їхні мотиви були добре відомі — я регулярно зустрічаюся з ними ось уже протягом кількох років. 2016 також не став винятком.
Можна виділити групу інцидентів, яка пов'язана з діяльністю людей, які вважають себе частиною культури стартапів Кремнієвої Долини. Вони дуже активно спілкуються з пресою, намагаючись привернути увагу до своєї теперішньої або майбутньої компанії.
зокрема, інсайдер може думати так: «Якщо я зараз сіллю що-небудь цікаве журналістам, можливо, вони потім напишуть про мою ідею для стартапу».
Хоч це і досить специфічний сценарій, співробітники високотехнологічних компаній люблять передавати пресі IP-адресу та інформацію про продукти, отримуючи натомість різні вигоди.
Ця проблема стала в достатній мірі загальної і вже може називатися тенденцією. Від неї складно знайти ефективний захист, так як подібні витоку допускають співробітники, що не мають високого рівня доступу. Для цієї проблеми важко знайти рішення загального виду, яке одночасно не призведе до перетворення організації в повністю закриту Apple-подібну компанію. Більшість виконавчих директорів прагнуть залишатися відкритими для своїх співробітників і готові піти на цей ризик.
У наступну групу потрапляють випадки, пов'язані з внутрішніми інструментами підтримки користувачів. Як тільки у вас набереться певну кількість співробітників з доступом до інструментів адміністратора, один з них обов'язково нашкодити (поодинці або змовившись з кимось ще).
Знайте розмір своїх боргів і не забувайте їх повертати
Практично у всіх організаціях, яким я допомагав в минулому році, була відстала область з величезною технічної заборгованістю.
Це наводить мене на думку, що компанії, які вважають такі борги частиною інженерного процесу, зазвичай добре організовані, і ризики у них помітно нижче.
Стартап може розвиватися дуже швидко, зрізати кути, вести агресивну конкурентну боротьбу і бути готовим йти на ризик.
У фазі розробки та успішного запуску проекту початківці компанії сильно відрізняються один від одного підходом до документування випадків, в яких їм доводилося йти на компроміс, і ретроспективного аналізу накопиченої заборгованості.
Потім вони повертають свої борги.
Вкрай рідко я був свідком того, щоб компанія закривала абсолютно всю технічну заборгованість. Але організації, які принаймні знають, де і що вони повинні, ніколи не відстають настільки, щоб пройти точку неповернення і опинитися в становищі, коли їх уже практично неможливо захистити.
Борги приходять з різних напрямків: масштаб, швидкість розробки, надійність сайту, нюанси роботи з користувачами, що передує автоматизації ручна робота і, нарешті, безпека.
Проблема боргів з інформаційної безпеки в тому, що вони голосно про себе не заявляють. Інші форми заборгованостей призводять до помилок, витрат, скарг користувачів і люті інженерів. Борги по ІБ призводять лише до створення вразливостей, і розмір цих боргів дуже складно виміряти. Для цього потрібно кропітка ручна робота або використання просунутих технологій.
Інженерна компанія, яка уміло керує своїми технічними боргами, зазвичай має менше проблем з безпекою.
Я рідко зустрічав це на практиці, але навіть просто усвідомлення проблеми і бажання рухатися в напрямку її вирішення — вже відмінний знак. Google — одна з небагатьох компаній, яка структурувала свою «заборгованість по помилок», пов'язану з випуском релізів, і прописала відповідні політики. Вони змогли зробити проблему «боргів» вимірної і розв'язуваної. Ollie Whitehouse з NCC Group говорив про це.
Багато організації і не підозрюю, що деякі їх стандартні процеси (ретроспективний аналіз, розбір завершилися інцидентів) допомагають уникнути накопичення надмірних технічних заборгованостей.
Висновок: перш ніж робити наступний великий крок вперед, переконайтеся, що ваші найбільші борги віддані.
Висновок
Інциденти інформаційної безпеки можуть багато чому нас навчити. Дуже важливо знайти способи говорити про них і, працюючи з ними, підвищувати свою майстерність.


@magoo
Про мене: я займаюся інформаційною безпекою, раніше працював на Facebook і Coinbase. Зараз є радником і консультантом кількох стартапів. Спеціалізуюся на реагуванні на інциденти та створення команд ІБ, але беруся і за багато інших ІТ-завдання.
Дякую Collin Greene і Rob Witoff.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.