Процесна модель управління ризиками

 

У березні цього року був прийнятий новий британський стандарт BS 7799 Частина 3 - Системи управління інформаційною безпекою - Практичні правила управління ризиками інформаційної безпеки. Чекає, що до кінця 2007 року ISO затвердить цей документ у якості міжнародного стандарту. BS 7799-3 визначає процеси оцінки та управління ризиками як складовий елемент системи управління організації, використовуючи ту ж процесну модель, що й інші стандарти управління, яка включає в себе чотири групи процесів: планування, реалізація, перевірка, дії (ПРПД), що відображає стандартний цикл будь-яких процесів управління. У той час як ISO 27005 описує загальний безперервний цикл управління безпекою, в BS 7799-3 міститься його проекція на процеси управління ризиками ІБ.

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

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

На етапі Перевірки відстежується функціонування механізмів контролю, контролюються зміни факторів ризику (активів, погроз, вразливостей), проводяться аудити і виконуються різні контролюючі процедури.

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

 

Реактивний підхід

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

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

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

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

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

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

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

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

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

Проактивних підхід

Проактивних підхід до управління ризиками безпеки володіє багатьма перевагами в порівнянні з реактивним. Замість того аби починати щось робити лише після виникнення проблем, організація зменшує вірогідність їх появи (у тому числі вірогідність появи проблем, що не виникали раніше). Для цього розробляються плани забезпечення безпеки важливих активів організації шляхом вживання елементів контролю, що зменшують ризик використання вразливих місць шкідливими програмами і зловмисниками або випадкового зловживання. Аби краще зрозуміти цю ідею, приведемо наступну аналогію. Грип - це смертельно небезпечне респіраторне захворювання, яким в США щорік захворюють мільйони людей. Більше 100 000 з них потребують госпіталізації, а близько 36 000 вмирають. Аби впоратися з цією загрозою, людина може або нічого не робити, поки не захворіє, а потім звертатися до лікарів і лікуватися, або ж пройти попередню вакцинацію до початку епідемії.

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

У останньому розділі цієї глави і в главах даного стандарту, що залишилися, про активних підхід до управління ризиками безпеки буде розглянутий детальніше. Всі методики управління ризиками безпеки використовують ряд загальних високорівневих процедур.

1. Виявлення бізнес-активів.

2. Визначення збитку, який може понести організація в результаті атаки на актив.

3. Виявлення вразливих місць в системі безпеки, які можуть бути використані при атаці.

4. Пошук методів мінімізації ризиків атаки шляхом реалізації відповідних елементів контролю.