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

Три причини формалізації

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

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

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

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

неефективні політики

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

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

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

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

Створення ефективної політики

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

Поняття і документи

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

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

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

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

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

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

Крім того, в загальній схемі нормативного забезпечення інформаційної безпеки слід виділити документи, які умовно можна віднести до аварійного плану. Тут теж існують поняття, які іноді плутають між собою. Найбільш відомі з них прийшли з західних практик безпеки, це план відновлення інформаційних систем після аварії або катастрофи (Disaster Recovery Plan, DRP); аналіз негативних наслідків реалізації загроз інформаційної безпеки для бізнес-процесів підприємства (Business Impact Analysis, BIA); план відновлення бізнес-процесів після настання негативних подій (Business Continuity Plan, BCP).

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

структура концепції

Повернемося до розгляду політики верхнього рівня - концепції. Стандарт ISO 17799: 2005 (розділ 5.1.1) описує приблизну структуру цього документа, який повинен містити розділи: визначення інформаційної безпеки, її цілі та масштаб; підтримка інформаційної безпеки керівництвом підприємства відповідно до бізнесом; структура інформаційної безпеки, опис контрольних механізмів, оцінка та управління ризиками; принципи і стандарти інформаційної безпеки, характерні для даного підприємства; ролі і відповідальність в області інформаційної безпеки; посилання на інші документи з безпеки.

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

Ось приклади таких високорівневих метрик.

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

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

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

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

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

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

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

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

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

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

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

Ролі та відповідальність

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

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

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

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

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

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

взаємовідносини

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

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

Про що не треба писати

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

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

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

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

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

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

Кращі практики

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

• хто виконує контроль - роль, посаду або конкретний співробітник, в обов'язки яких входить виконання відповідних процедур;

• коли виконується контроль - зазначення терміну або умов, коли необхідно виконати процедури;

• що робиться в рамках контролю - опис самих процедур;

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

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

Іскандер коні - менеджер групи технічної інтеграції, «Делойт і Туш СНД», [email protected]