Не зовсім відомі рішення щодо захисту ІТ-інфраструктури бізнесу



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

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

Плюс пара прикладів на солодке — ви дізнаєтеся, що може творитися в повністю ізольованою від Інтернету мережі і на периметрі банку.

Розвиток

За останні два роки на ринку великих enterprise-рішень почалося досить сильний рух. Спочатку була досить хороша активність по захисту від DDoS — якраз тоді атаки подешевшали. Поки середній бізнес знайомився з IT з питань «чому у нас лежить сайт і не працюють каси в магазинах», розбудовував великий оборону в бік захисту від нестандартних атак. Нагадаю, більша частина спрямованих загроз реалізується через в'язку 0-day і социнжиниринга. Тому логічним кроком стало впровадження аналізаторів коду ще на стадії розробки ПО для компанії.

Перевірка до коміта

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

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


Приклад рішення — HP Fortify Software Security center.

Сторонній код

При імплементації стороннього коду ІБ великого бізнесу часто наполягає на статичному аналізі коду. Коли мова про опенсорс — ситуація дуже проста і зрозуміла, просто прогін через аналізатор і «придушення» від сотні до тисячі попереджень. Коли код комерційний, і замовник не готовий надати вихідні коди своєї підсистеми, настає більш цікава ітерація.

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

Крім автоматичних методів часто запрошується пентестер: це або співробітник ІБ/ІТ-відділу з профільною освітою, або, частіше — сторонній фахівець у компанії-партнера.

Старий код

При виявленні проблем з legacy-кодом, та ще й скомпільованим для підсистеми аж у 1996 році (був такий реальний випадок), природно, переписати його буває досить складно. У цьому випадку на файрволлі прописується правило, що описує тип експлуатації уразливості (фактично — сигнатури пакетів експлоїта), або ж на одній з проміжних систем (про них нижче) прописується відсічення всього того, що не є нормальним пакетом для кінцевої системи. Свого роду DPI, а для закриття уразливості, обв'язка рівнем вище.

Внутрішні обходи

Зовсім великий бізнес має ще одну характерну проблему — кількість змін у живій інфраструктурі таке, що навіть великому відділу не під силу встежити за всіма рухами в мережі. Тому ті ж банки, роздріб і страхові використовують спеціалізовані засоби начебто HP Webinspect або MaxPatrol від наших співвітчизників Positive Technologies. Ці системи дозволяють перевіряти різні компоненти інфраструктури, включаючи те, що накочується на мікроконтролери слабкострумових систем.

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

При цьому настройка йде у вигляді «додаток-користувач-сервер» у вигляді GUI прямо самим безопасником без участі IT-відділу. Як це ні дивно, подобаються такі системи в тому числі і адмінам — у мене був приклад, коли додаток Вконтакте початок генерувати 90% трафіку у смузі, і адмін це дуже легко помітив.

Приклад системи пошуку мережевих аномалій — StealthWatch.

При комплексному аналізі захищеності зазвичай робиться три процедури:

  • Аналіз на рівні «чорного ящика» без привілеїв користувачів, тобто просто захід зовні. Це вільні порти, аналіз всього що дивиться назовні служб, спроби використовувати зібрані уразливості і пройти DMZ. Стандартний пентест, як правило.
  • Аудит з учеткі адміна або привілейованого користувача. Передбачається, що зловмисник як-то «намутил» доступи (наприклад, засобами социнжинринга), і атака розвивається з цього моменту. В рамках цього ж аудиту робиться обхід по всьому зсередини мережі. Перевіряються налаштування, конфігураційні файли, коректність оновлення систем, контрольні суми кожного пакета і файлу, оцінюються версії ПЗ і їх відомі уразливості (наприклад, щоб вінда на машинах була правильно оновлено з сертифікованого джерела). Приклад пакету — RedCheck.
  • Третій режим — відповідність вимогам певного стандарту. Це розширений обхід мережі у відповідність з шаблоном, наприклад, моделі обробки персональних даних за класами. У наших вендорів є передналаштовані шаблони під Росію — в іноземних, як правило, в кращому випадку далі PCI DSS справа йде рідко.
Приклади таких аудитів є ось тут у нас. Але перейдемо до проблем і грі «знайди знайомого».

Типові проблеми

Як правило, велика частина проблем для ІБ великого бізнесу більше не технічні, а «побутові», на рівні організації:
  • Застаріле обладнання та ПЗ. Часто у великому бізнесі потрібні сертифіковані рішення, а вони стрімко відстають від новинок. Багато хто просто не можуть дозволити собі поставити нове або нову круту залізяку, а ставлять щось з наперед відомими дірками або відсутнім потрібною функціональністю і забивають милиці, щоб якось вирішити питання. Нерідка ситуація, коли банк ставить рішення, яке тільки проходить сертифікацію, і, по факту, місяць-два працює на свій страх і ризик без повної відповідності вимогам регуляторів. Альтернатива — мати дірку розміром з коня в ІБ, але при цьому намагатися закрити її папірцем, що все відповідає стандарту і вимогам.
  • Наслідок — один ящик замикає на себе всю мережу. Проблема абсолютно божевільна, але часто вся внутрішня мережа невеликого банку може впиратися в один пристрій, який років на 5 відстало від флагмана, але зате працює під сертифікатом. При виході з ладу цієї залізяки падає все до вирішення питання. Природно, більш сучасні рішення вміють байпассы на підсистеми, паралельність, резервування — але реальність трохи відрізняється від ідеальної схеми архітектури мережі.
  • Або інший варіант. Є, в цілому, все що потрібно. Але DLP і антибот не можна активувати, часто бувають проблеми з оновленням бази сигнатур антибота (заборонено оновлювати), проблеми з драйверами (була ситуація — поставили сертифіковане обладнання, а воно не зійшлося з RAID-масивом — на щастя, через кілька днів вийшла нова сертифікована версія).
  • «Хардкод». Різним пристроям потрібен різний тип трафіку, при впровадженні нових залізних рішень часто робиться болюча і довга перекоммутация. Тести одного захисного засобу можуть йти тижня просто з-за цього. На практиці ж досить поставити сучасне рішення, яке дозволить працювати на рівні каналу. Що дозволяє, наприклад, ставити IPS під цей канал до файрволла або після (що дуже позначається на продуктивності).



Скріншот Gigamon GigaVUE-HC2

  • Різне залізо під захист. Це не проблема насправді, просто тенденція така, що велика частина вендорів прийшла до того, що всі рішення по забезпеченню периметра вкладаються в один пристрій UTM. Справа в тому, що кожне рішення являє собою ПАК у вигляді «чорного ящика». Сучасний варіант — однакова x86-архітектура, і можливість оновлювати функціональність не викидаючи залізо раз у два роки. Наприклад, є пристрій, де всередині вже файрволл, потоковий антивірус, антибот-система і так далі. При цьому воно сертифіковане цілком і в залізній частині складається з x86-машини, розбитою на віртуальні програмні блейды на рівні. При необхідності доставляється туди софт, доплачується за ліцензію — і воно продовжує молотити по-новому.
  • Складна інтеграція зоопарку систем. Знову ж таки, наслідок попереднього пункту. Багато різного погано зістикувати заліза — це проблема проброски даних з однієї частини ІБ-системи в іншу. Приміром, давно вже стало нормою, що IPS чітко пов'язана з антиботнет-системою. Впевнений, що далеко не у всіх банках це так — тому що, знову ж, або складно робити інтеграційну механіку, або немає єдиної залозки з блейдами як я описав вище. До речі, останнє покоління ще і вміє «розщеплювати мозок», щоб сканувати сама себе на предмет відповідності конфігурації того ж PCI DSS. Раніше це робилося окремими зовнішніми системами.
  • Аналіз інфраструктури на відповідність стандартам не враховує російські реалії. Спрощуючи, у вас буде ідеальні набори «утиліт-обхідників» для перевірки відповідності PCI DSS. Але тільки мала частина рішень вміє № 152-ФЗ «ПРО персональних даних». Приміром, за це (ну і не тільки) вітчизняний MaxPatrol «ганяється» Лукойлі, Норнікелі, «Вымпелком», «Газпромі» і так далі.
  • Раптові зміни. Це взагалі за межею добра і зла, але так трапляється. Частий випадок — IT-спеціаліст щось робить і встановлює нове правило на рівні інфраструктури, що через місяць-другий раптово виявляє безопаснік (часто — не сам, а з підказки, програми пошуку багів, пентеста або реальної атаки) і впадає в паніку. Потім влаштовує всім рознос. Наприклад, на одній з наших інтеграцій була ситуація, коли нам треба було прискорити на тиждень впровадження важкого сервера-молотарки. При впровадженні, не знаючи всіх деталей ІТ-кухні замовника, ми дозволили ганяти певний тип трафіку прямо до нього. А потім відзвітували про успіх. У відповідь на це безпечники ініціювали службове розслідування, в результаті якого нам самим ледь не дісталося по шапці. Так от, правильно ставити систему, коли IT-спец впроваджує щось на мережі, але правило не проаппрувится, поки його не підтвердить безопаснік. Було б так, наші колеги отримали премії, тому що проблема була не в дозволі на трафік, а тому, що це пройшло повз ІБ-відділу.
  • Недоверенные джерела. У багатьох корпоративних середовищах на рівні приклада часто бувають проблеми з тим, що кінцеві користувальницькі пристрої — це цирк навпіл зі звіринцем вірусів. Наприклад, одна справа, коли страховий агент їде на місце, фотографує вм'ятину на машині на свою камеру, потім приїжджає додому, фотошопит на більш сильні пошкодження і відправляє. Інша справа, коли фотографія приходить з корпоративного додатки (під сертифікатом) по захищеному каналу і з нерутированного пристрою. Можна довіряти розміром вм'ятини. Більш серйозний випадок — різке зниження довіри до VPN в одній з компаній, де в результаті з-за вірусів у віддалених співробітників до зловмисникам потрапляли всі доступи. Вирішили питання віртуальним JAVA аплет в браузері, який забезпечує захищену довірену середовище при VPN доступ.


Захисні засоби, приклади

• системи класу NG FW (Check Point, Stonesoft, HP Tipping Point);
• система виявлення потенційно небезпечних файлів (пісочниця) (Check Point, McAfee, FireEye);
• спеціалізовані засоби захисту web-додатків (WAF) (Imperva SecureSphere WAF, Radware AppWall, Fortinet Fortiweb);
• Інтелектуальний центр (ByPass вузол) для підключення засобів ІБ (Gigamon GigaVUE-HC2).
• системи виявлення аномалій в мережевому трафіку (StealthWatch, RSA NetWitness, Solera Networks);
• Аналіз захищеності та відповідності (MaxPatrol, HP Webinspect)
• аудит безпеки коду (HP Fortify, Digital Security ERPScan CheckCode, IBM AppScan Source);
• система захисту від DDoS (залізо — Radware DefensePRO, ARBOR PRAVAIL, Check Point DDoS Protector; сервіс — Kaspersky DDoS Prevention, QRATOR HLL).

Приклади на десерт

Атестована мережа
В одному з великих державних відомств було вирішено провести оцінку захищеності атестованого сегмента мережі, призначеного для обробки конфіденційної інформації. Зокрема, користувачам цього сегмента категорично заборонявся доступ в Інтернет. Знайшлося ось що:
  • Сліди підключення USB-модемів.
  • Один з ноутбуків був підключений до зовнішньої мережі та публічною.
  • Знайшлося досить багато месенджерів та ігор.
В цілому, ви напевно бачили такі ізольовані мережі в армії, коли бійці штабу сидять на сайтах знайомств. Тут ситуація була дещо серйозніше.

Мережевий периметр комерційного банку
Потрібно було оцінити захищеність периметра. Зазвичай таку роботу проводять у рамках тестування на проникнення, але в даному випадку замовнику було цікавіше подивитися, що він зможе зробити самостійно зсередини. Для цього сервери та телекомунікаційне обладнання зовнішніх демілітаризованих зон просканували системою MaxPatrol в режимах Audit і Compliance, після чого проаналізували звіти. Перше, що кинулося в очі — певна кількість вразливостей, пов'язаних, як правило, із застарілим софтом або відсутністю оновлень безпеки (старі версії ОС, відсутність латок на більшості серверів тощо), але це не найстрашніше: до більшості таких вразливостей немає доступних хакерам експлойтів. Але зустрілися і сюрпризи. На парі периметровых маршрутизаторах відсутні ACL (як з'ясувалося, їх тимчасово відключили при діагностиці проблем зв'язки між підрозділами, і забули включити), так що зовні було доступно набагато більше вузлів, ніж уявляли адміністратори. У великий Інтернет мордою назовні дивилася бойова СУБД. Замість SSH використовувався TELNET на ряді вузлів. На ряді бойових серверів не змінили налаштування RDP після конфігурування (RDP-трафік закривався типовим ключем). Знайшлися герої, які не змінили дефольные паролі з моменту початку роботи в компанії. На щастя, зовні це не встигли помітити, тому все вдалося оперативно закрити майже без жертв у складі ІТ-відділу.

p.s. Якщо у вас питання не для коментарів, моя пошта — PLutsik@croc.ru.

Джерело: Хабрахабр

0 коментарів

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