Безпека як процес

Зігфрід Хубер

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

Без надійної і стабільної інфраструктури інформаційних технологій промислові підприємства, як і інші сучасні компанії, не зможуть працювати продуктивно протягом тривалого часу. Постачальники ж охоче експлуатують цю тему для реклами своїх продуктів і послуг, при цьому як конкурентного переваги підкреслюється їх захищеність. Як наслідок, безліч пропозицій створює оманливе враження, що безпека можна просто купити і що одного разу досягнутий високий рівень буде зберігатися вічно. У Насправді все навпаки. Недавнє дослідження німецького Федерального управління інформаційної безпеки показало, що найбільшу загрозу представляє недостатня сенсибілізація управління, відсутність аналізу процесів і слабо опрацьовані плани поведінки в разі кризових та аварійних ситуацій ( «Стан безпеки ІТ в Німеччині», http://www.bsi.de, стор 31). Так, підприємств, що впровадили у себе безперервний процес забезпечення безпеки, як і раніше, дуже мало.

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

З малими витратами досягти багато чого

патентованих рішень, поширених в інших галузях ІТ, у сфері безпеки ІТ не існує. Стандартним підходом до захисту демілітаризованої зони і Intranet є застосування брандмауерів. Порівняно недавно настільки ж обов'язковими стали системи виявлення вторгнень. Часто складовими частинами «надійною» інфраструктури ІТ є інфраструктура з відкритими ключами (Public Key Infrastructure, PKI), віртуальні приватні мережі (Virtual Private Network, VPN) і багато чого іншого.

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

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

Всі підприємства працюють по-різному

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

Наприклад, компанія А розробляє програми відповідно до стандартної громадської ліцензією (General Public License, GPL), а отже, зобов'язана публікувати вихідні коди. Компанія У створює додатки і продає їх без публікації коду під власною ліцензією. Якщо обидві стануть аналізувати небезпеки, то результати вийдуть різними: компанія А, ймовірно, вважатиме, що її знаходиться в відкритому доступі вихідного коду майже ніщо не загрожує, і присвоїть йому дуже низьку оцінку за п'ятибальною шкалою, а от для компанії У її вихідний код має високе, можливо, життєво важливе значення - бачити його дозволяється лише певному колу осіб. Зважаючи на небезпеку розкрадання і публікації вихідного коду йому присвоюється оцінка в діапазоні від трьох до п'яти.

Особливо серйозний ризик для підприємства виникає в тому випадку, коли один з компонентів процесу має ще й слабке місце. Це можуть бути, наприклад, «Дірки» в підсистемі безпеки операційної системи, не захищене шифрування даних чи помилка в коді програми. З урахуванням усіх цих факторів впливу ризик обчислюється у відповідності з наступною формулою: ризик = небезпека х слабке місце х оцінка. У контексті розглянутого вище прикладу для компаній А і В можна побудувати відповідні матриці ризиків (див. Таблиці 1 і 2).

Чотири кроки до всеосяжного процесу забезпечення безпеки

Річард Бейтліч в «Дао моніторингу мережевої безпеки» пише: «Безпека - це процес регулярної перевірки наявних прийнятних ризиків »(Addison Wesley, 2005). Він ділить процес безпеки на чотири наступні один за одним, постійно повторюються етапи: оцінка, захист, виявлення і реакція.

Етап 1: оцінка. Поряд з аналізом ризику цей етап складається головним чином у підготовці до наступних трьох і починається з опису інфраструктури ІТ. Для забезпечення можливості для планування подальших дій необхідна інвентаризація всіх мережевих компонентів: серверів, комутаторів, маршрутизаторів і т. д. В результаті проведеної інвентаризації для кожного врахованого компоненти повинні бути визначені як мінімум ім'я хоста, IP-адресу, операційна система, версія програмного забезпечення та завдання. Лише після збору всієї зазначеної інформації підприємство може приступити до планування реальних заходів захисту. Системи, опис яких складено фрагментарно або взагалі відсутній, є найбільш серйозне джерело небезпеки. Причина в тому, що при плануванні потреби в захисті врахувати їх повною мірою не вдається.

Ще одна важлива задача, яка виконується на етапі оцінки, полягає в розробці директив безпеки. Вони є обов'язковими як для користувачів, так і для персоналу ІТ і повинні проводитися в життя за відповідної підтримки з боку керівництва.

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

дозволеними протоколами для вихідного трафіку є:

• HTTP і HTTPS - для звернення через Web до будь-якого сервера Web і FTP - для звернення до будь-якого сервера FTP;

• DNS - для передачі даних про імена на сервер імен підприємства;

• SMTP і РОРЗ - для передачі трафіку електронної пошти на поштові сервери підприємства;

• IPSec або SSL - для передачі трафіку віртуальних приватних мереж на шлюз VPN. Дозволеними протоколами для вхідного трафіку є:

• HTTP і HTTPS - для звернення через Web до серверів Web підприємства;

• DNS - для звернення до сервера імен підприємства з метою визначення адреси;

• протоколи для передачі трафіку електронної пошти на поштові сервери підприємства.

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

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

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

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

Етап 3: виявлення. Виявлення порушень директив безпеки і відповідне реагування на них - ось заходи, які визначаються на третьому етапі. Системи виявлення вторгнень (Intrusion Detection System, IDS) записують мережевий трафік на ключових вузлах інфраструктури ІТ для його подальшої оцінки. У відміну від витрат на брандмауери, витрати на конфігурування та обслуговування IDS дуже високі - момент, який нерідко не беруть до уваги. Часто з IDS надходять так само, як і з системами брандмауерів: визначення політики, реалізація політики та її розгортання.

Як правило, відносно брандмауерів такого способу дій достатньо, оскільки їх єдине завдання полягає в тому, щоб дозволяти користування одними мережевими службами і блокувати інші. Один раз сконфігуровані, вони надійно і з незначними адміністративними витратами роблять свою роботу. Інша справа IDS: будь-яке порушення директиви спочатку має бути проінтерпретувати системою і за певних обставин охарактеризовано як «вторгнення». Кожне вторгнення в залежності від рівня загрози тягне за собою різні дії: одні виконуються автоматично за допомогою систем попередження вторгнень (Intrusion Prevention Systemen, IPS), інші ж, навпаки, вимагають безумовного втручання адміністратора. Систему можна, наприклад, налаштувати так, щоб у разі недозволеного доступу до будь-якої певної службі вона самостійно блокувала IP-адреса відправника. Істотно більш небезпечні «вторгнення», наприклад зараження мережі клієнтами, що перебувають під контролем зловмисника і використовуються для проведення розподілених атак з метою викликати «відмова в обслуговуванні», зажадають, можливо, відключення цілих сегментів мережі.

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

Етап 4: реакція. Імовірність неспрацьовування механізмів етапу захисту виключити не можна, як і те, що зловмисник знайде лазівку в мережі, розставлені на етапі виявлення. На цей випадок на етапі відповідних дій підготовляються належних заходів та відповідні механізми.

Якщо зловмисник використовує для атаки слабке місце в програмному забезпеченні будь-якої служби сервера, розумні контрзаходи складаються з наступних кроків: • фізичне відключення всіх мережевих з'єднань сервера;

• завершення роботи постраждалої серверної служби;

• запуск відповідного виправлення на сервері;

• вимкнення сервера;

• підключення від'єднаних мережних шнурів;

• повторний запуск сервера;

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

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

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

Список літератури

Журнал мережевих рішень, лютий 2007