Як я писав політику безпеки

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

image

А навіщо, власне?

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

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

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

Дорогі читачі

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

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

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

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

Перш ніж сперечатися

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

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

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

Закон і порядок

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

В якості прикладу наведемо мінімальний набір тем, які має сенс відобразити в розроблюваної політики:

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

Ну і ще одна важлива зі змістовної точки зору деталь – політика безпеки може бути описової («as is», фіксується поточний стан) або директивної («to be», що має бути зроблено). Директивний варіант видається більш зрозумілим для читання і логічним для подальшого застосування, так як зазвичай «вже зроблено набагато менше, ніж «буде зроблено».

А судді хто?

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

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

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

Згоду і примирення

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

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

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

Успішність впровадження

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

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

Про граблі (замість висновку)

Ще раз коротко перерахуємо типові проблеми, з якими можна зіткнутися при написанні політики безпеки:

  • «А це взагалі про що?» – вимоги, не знаходять свого читача (виконавця) або звернені в нікуди.
  • «Муть якась...» – нечітка термінологія, незрозумілі формулювання вимог політики.
  • «Повна хрень!» – Складнощі при узгодженні і впровадженні із-за активної протидії ключових користувачів, думка яких не було враховано.
  • «Хіба документи так пишуться?!» – Ігнорування правил оформлення, стилістичні, орфографічні і пунктуаційні помилки.
Ну і, звичайно ж, автор буде радий будь-яких питань і зауважень, які можуть виникнути після прочитання цієї замітки.

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

0 коментарів

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