Політика безпеки

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

* рішення сформувати або переглянути комплексну програму забезпечення інформаційної безпеки, призначення відповідальних за впровадження програми;

* формулювання цілей, які переслідує організація в області інформаційної безпеки, визначення загальних напрямків у досягненні цих цілей;

* забезпечення бази для дотримання законів і правил;

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

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

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

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

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

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

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

Тобто необхідно включати в документ, що характеризує політику безпеки організації, наступні розділи:

* вступний, підтверджуючий занепокоєність вищого керівництва проблемами інформаційної безпеки;

* організаційний, який має опис підрозділів, комісій, груп і т.д., відповідальних за роботу в області інформаційної безпеки;

* класифікаційний, що описує наявні в організації матеріальні й інформаційні ресурси й необхідний рівень їхнього захисту;

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

* розділ, що висвітлює питання фізичного захисту;

* керівний розділ, що описує підхід до керування комп'ютерами й комп'ютерними мережами;

* розділ, що описує правила розмежування доступу до виробничої інформації;

* розділ, що характеризує порядок розробки й супроводу систем;

* розділ, що описує заходи, спрямовані на забезпечення безперервної роботи організації;

* юридичний розділ, що підтверджує відповідність політики безпеки чинному законодавству.

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

Політика середнього рівня повинна для кожного аспекту висвітлювати наступні теми:

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

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

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

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

Законослухняність. Політика повинна містити загальний опис заборонених дій і покарань за них.

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

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

* хто має право доступу до об'єктів, підтримуваним сервісом?

* за яких умов можна читати й модифікувати дані?

* як організований вилучений доступ до сервісу?

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

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

4.3. Програма безпеки

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

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

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

* керування ризиками (оцінка ризиків, вибір ефективних засобів захисту);

«координація діяльності в області інформаційної безпеки, поповнення й розподіл ресурсів;

* стратегічне планування;

* контроль діяльності в області інформаційної безпеки.

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

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

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

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

4.4. Синхронізація програми безпеки з життєвим циклом систем

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

У життєвому циклі інформаційного сервісу можна виділити наступні етапи:

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

Закупівля. На даному етапі складаються специфікації, проробляються варіанти придбання, виконується власне закупівля.

Установка. Сервіс установлюється, конфігурується, тестується й уводиться в експлуатацію.

Експлуатація. На даному етапі сервіс не тільки працює й адмініструється, але й піддається модифікаціям.

Виведення з експлуатації. Відбувається перехід на новий сервіс.

Розглянемо дії, виконувані на кожному з етапів, більш докладно.

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

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

* якого роду інформація призначається для обслуговування новим сервісом?

* які можливі наслідки порушення конфіденційності, цілісності та доступності цієї інформації?

* які загрози, стосовно яких сервіс та інформація будуть найбільш уразливі?

* чи є які-небудь особливості нового сервісу (наприклад, територіальна роззосередженість компонентів), що вимагають прийняття спеціальних процедурних заходів?

* які характеристики персоналу, що має відношення до безпеки (кваліфікація, благонадійність)?

* які законодавчі положення й внутрішні правила, яким повинен відповідати новий сервіс?

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

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

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

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

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

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

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

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

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

Розділ 5. Керування ризиками

5.1. Основні поняття

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

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

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

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

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

* (пере)оцінка (вимір) ризиків;

* вибір ефективних та економічних захисних засобів (нейтралізація ризиків).

Стосовно виявлених ризиків можливі наступні дії:

* ліквідація ризику (наприклад, за рахунок усунення причини);

«зменшення ризику (наприклад, за рахунок використання додаткових захисних засобів);

* прийняття ризику (і вироблення плану дії у відповідних умовах);

* переадресація ризику (наприклад, шляхом висновку страхової угоди). Процес керування ризиками можна розділити на наступні етапи:

1. Вибір аналізованих об'єктів і рівня деталізації їхнього розгляду.

2. Вибір методології оцінки ризиків.

3. Ідентифікація активів.

4. Аналіз загроз та їхніх наслідків, виявлення уразливих місць у захисті.

5. Оцінка ризиків.

6. Вибір захисних заходів.

7. Реалізація й перевірка обраних заходів.

8. Оцінка залишкового ризику.

Етапи 6 та 7 відносяться до вибору захисних засобів (нейтралізації ризиків), інші - до оцінки ризиків.

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

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

На етапі ініціації відомі ризики варто врахувати при виробленні вимог до системи взагалі й засобів безпеки зокрема.

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

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

На етапі експлуатації керування ризиками повинно супроводжувати всі істотні зміни в системі.

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

5.2. Підготовчі етапи керування ризиками

У цьому розділі будуть описані перші три етапи процесу керування ризиками.

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

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

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

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

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

Одним з головних результатів процесу ідентифікації активів є одержання детальної інформаційної структури організації й способів її (структури) використання. Ці відомості доцільно нанести на карту ІС як межі відповідних об'єктів.

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

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

5.3. Основні етапи керування ризиками

Етапи, що передують аналізу загроз, можна вважати підготовчими, оскільки прямого зв'язку з ризиками вони не мають. Ризик з'являється там, де є загрози.

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

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

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

Після ідентифікації загрози необхідно оцінити ймовірність її здійснення, Можливе використання при цьому трибальної шкали (низька (1), середня (2) і висока (3) ймовірність).

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

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

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

Після того, як накопичені вихідні дані й оцінений ступінь невизначеності, можна переходити до обробки інформації, тобто власне до оцінки ризиків. Цілком припустимо застосовувати такий простий метод, як множення ймовірності здійснення загрози на передбачуваний збиток. Якщо для ймовірності й збитку використовувати трибальну шкалу, то можливих добутків буде шість: 1, 2, 3, 4, 6 й 9. Перші два результати можна віднести до низького ризику, третій і четвертий - до середнього, два останні - до високого, після чого з'являється можливість знову привести їх до трибальної шкали. По цій шкалі й варто оцінювати прийнятність ризиків. Щоправда, граничні випадки, коли обчислювальна величина збіглася із прийнятною, доцільно розглядати більш ретельно через наближений характер результату.

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

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

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

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

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

Як і будь-яку іншу діяльність, реалізацію й перевірку нових регуляторів безпеки варто попередньо планувати. У плані необхідно врахувати наявність фінансових засобів і строки навчання персоналу. Якщо мова йде про програмно-технічний механізм захисту, потрібно скласти план тестування (автономного й комплексного).

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

Розділ 6. Процедурний рівень інформаційної безпеки

6.1. Основні класи заходів процедурного рівня

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

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

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

На процедурному рівні можна виділити наступні класи заходів:

* керування персоналом;

* фізичний захист;

* підтримка працездатності;

* реагування на порушення режиму безпеки;» планування відновлювальних робіт.

6.2. Керування персоналом

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

* розподіл обов'язків;

* мінімізація привілеїв.

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

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

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

Коли кандидат визначений, він, імовірно, повинен пройти навчання; принаймні, його варто докладно ознайомити зі службовими обов'язками, а також з нормами й процедурами інформаційної безпеки. Бажано, щоб заходи безпеки були ним засвоєні до вступу на посаду й до введення його системного рахунку із вхідним ім'ям, паролем та привілеями.

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

Ліквідація системного рахунку користувача, особливо у випадку конфлікту між співробітником та організацією, повинна вироблятися максимально оперативно (в ідеалі - одночасно з повідомленням про покарання або звільнення). Можливе й фізичне обмеження доступу до робочого місця. Зрозуміло, якщо співробітник звільняється, у нього потрібно прийняти все його комп'ютерне господарство й, зокрема, криптографічні ключ?, якщо використовувалися засоби шифрування.

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

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

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

6.3. Фізичний захист

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

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

Ми коротко розглянемо наступні напрямки фізичного захисту:

* фізичне керування доступом;

* протипожежні заходи;

* захист підтримуючої інфраструктури;

* захист від перехоплення даних;

* захист мобільних систем.

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

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

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

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

Більш докладно дана тема розглянута в статті В. Барсукова "Фізичний захист інформаційних систем" (Jet Info, 1997, 1).

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

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

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

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

Бажаючим докладніше ознайомитися з питанням ми рекомендуємо прочитати статтю В. Барсукова "Блокування технологічних каналів витоку інформації" (Jet Info, 1998, 5-6).

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

Загалом кажучи, при виборі засобів фізичного захисту варто робити аналіз ризиків. Так, ухвалюючи рішення щодо закупівлі джерела безперебійного живлення, необхідно врахувати якість електроживлення в будинку, займаному організацією (втім, майже напевно воно виявиться поганим), характер і тривалість збоїв електроживлення, вартість доступних джерел і можливі втрати від аварій (поломка техніки, припинення роботи організації й т.п.) (див. також статтю В.Барсукова "Захист комп'ютерних систем від силових деструктивних впливів" в Jet Info, 2000, 2). У той же час, у багатьох випадках рішення очевидні. Засоби протипожежної безпеки обов'язкові для всіх організацій. Вартість реалізації багатьох засобів (наприклад, установка звичайного замка на двері серверної кімнати) або мала, або хоч і помітна, але все-таки значно менша, ніж можливий збиток. Зокрема, має сенс регулярно копіювати великі бази даних.

6.4. Підтримка працездатності

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

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

Можна виділити наступні напрямки повсякденної діяльності:

* підтримка користувачів;

* підтримка програмного забезпечення;

* конфігураційне керування;

* резервне копіювання;

* керування носіями;

* документування;

* регламентні роботи.

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

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

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

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

Кращий спосіб зменшити кількість помилок у рутинній роботі -максимально автоматизувати її. Праві ті "ледачі" програмісти й системні адміністратори, які, оглянувши поглядом море одноманітних завдань, говорять: "Я нізащо не буду робити цього; я напишу програму, що зробить усе за мене". Автоматизація й безпека залежать один від одного; той, хто піклується в першу чергу про полегшення свого завдання, насправді оптимальним чином формує режим інформаційної безпеки.

Резервне копіювання необхідно для відновлення програм і даних після аварій. І тут доцільно автоматизувати роботу, як мінімум, сформувавши комп'ютерний розклад створення повних й інкрементальних копій, а як максимум - скористатись відповідними програмними продуктами (див., наприклад, Jet Info, 2000, 12). Потрібно також налагодити розміщення копій у безпечному місці, захищеному від несанкціонованого доступу, пожеж, протікань, тобто від усього, що може привести до крадіжки або ушкодження носіїв. Доцільно мати кілька екземплярів резервних копій і частину з них зберігати за межами території організації, захищаючись у такий спосіб від великих аварій й аналогічних інцидентів.

Час від часу в тестових цілях варто перевіряти можливість відновлення інформації з копій.

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

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

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

6.5. Реагування на порушення режиму безпеки

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

Реакція на порушення режиму безпеки переслідує три головні цілі:

* локалізація інциденту й зменшення нанесеної шкоди;

* виявлення порушника;

* попередження повторних порушень.

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

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

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

Щоб знайти порушника, потрібно заздалегідь з'ясувати контактні координати постачальника мережевих послуг і домовитися з ним про саму можливість і порядок виконання відповідних дій.

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

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

6.6. Планування відновлювальних робіт

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

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

Процес планування відновлювальних робіт можна розділити на наступні етапи:

* виявлення критично важливих функцій організації, установлення пріоритетів;

* ідентифікація ресурсів, необхідних для виконання критично важливих функцій;

* визначення переліку можливих аварій;

* розробка стратегії відновлювальних робіт;

* підготовка до реалізації обраної стратегії;

* перевірка стратегії.

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

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

* персонал;

* інформаційна інфраструктура;

* фізична інфраструктура.

Формуючи списки відповідальних фахівців, варто враховувати, що деякі з них можуть безпосередньо постраждати від аварії (наприклад, від пожежі), хтось може перебувати в стані стресу, частина співробітників, можливо, не буде мати змоги потрапити на роботу (наприклад, у випадку масових безладь). Бажано мати невеликий резерв фахівців або заздалегідь визначити канали, по яким можна на деякий час залучити додатковий персонал.

Інформаційна інфраструктура містить у собі наступні елементи:

* комп'ютери;

* програми й дані;

* інформаційні сервіси зовнішніх організацій;

* документацію.

Потрібно підготуватися до того, що на "запасному аеродромі", куди організація буде евакуйована після аварії, апаратна платформа може відрізнятися від вихідної. Відповідно, варто продумати заходи підтримки сумісності по програмам і даним.

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

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

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

Аналізуючи критичні ресурси, доцільно врахувати часовий профіль їхнього використання. Більшість ресурсів потрібні постійно, але потреба може виникати тільки в певні періоди (наприклад, наприкінці місяця або року при складанні звіту).

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

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

Стратегія повинна передбачати не тільки роботу по тимчасовій схемі, але й повернення до нормального функціонування.

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

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

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

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

Розділ 7. Основні програмно-технічні заходи

7.1. Основні поняття програмно - технічного рівня інформаційної безпеки

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

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

Це друга причина, шо пояснює важливість програмно-технічних заходів.

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

* підвищення швидкодії мікросхем, розвиток архітектур з високим ступенем паралелізму дозволяє методом грубої сили переборювати бар'єри (насамперед криптографічні), які раніше здавалися неприступними;

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

* поява нових інформаційних сервісів призводить і до утворення нових уразливих місць як "усередині" сервісів, так і на їхніх з'єднаннях;

* конкуренція серед виробників програмного забезпечення змушує скорочувати строки розробки, що приводить до зниження якості тестування й випуску продуктів з дефектами захисту;

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

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

Центральним для програмно-технічного рівня є поняття сервісу безпеки.

Дотримуючись об'єктно-орієнтованого підходу, при розгляді інформаційної системи з одиничним рівнем деталізації ми побачимо сукупність надаваних нею інформаційних сервісів. Назвемо їх основними. Щоб вони могли функціонувати й мали необхідні властивості, необхідно кілька рівнів додаткових (допоміжних) сервісів - від СУБД і моніторів транзакцій до ядра операційної системи й устаткування.

До допоміжного відносяться сервіси безпеки (ми вже зіштовхувалися з ними при розгляді стандартів і специфікацій в області ІБ); з-поміж них нас у перш}' чергу будуть цікавити універсальні, високорівневі, що допускають використання різними основними й допоміжними сервісами. Далі ми розглянемо наступні сервіси:

* ідентифікація й аутентифікація;

* керування доступом;

* протоколювання й аудит:

* шифрування;

* контроль цілісності;

* екранування;

* аналіз захищеності;

* забезпечення відмовостійкості;

* забезпечення безпечного відновлення;

* тунелювання;

* керування.

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

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

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

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

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

* превентивним, перешкоджаючим порушенням ІБ;

* заходи виявлення порушень;

* локалізуючі, звужуючі зону впливу порушень;

* заход виявлення порушника;

* заходи відновлення режиму безпеки.