Управління ризиками як дисципліна, Комерція, Різне, статті

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

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

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

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

Нове мислення


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

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

Але нескінченне повторення мантр, що складаються з модних термінів, не має нічого спільного з по-справжньому активним управлінням ризиками. За цією концепцією стоять наука і складні процеси. Ступінь зрілості сфери управління ризиками мінлива; тут поряд з місцевими страховими компаніями працюють такі корифеї, як Lloyd “s of London, а методики оцінки ризиків в ІТ представлені такими документами, як ANZ 4360, NIST 800-30 і Factor Analysis of Information Risk (FAIR). Але, яким би глибоким не було ваше розуміння проблеми, і яку б формальну методику ви не вибрали, – в будь-якому випадку є критично важливі положення, які необхідно врахувати, і кроки, які необхідно зробити.

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

Вживати правильні терміни надзвичайно важливо, і історично індустрії ІТ тут похвалитися нічим. Приміром, в ІТ слово “ресурс” може означати все, що завгодно, – від USB-накопичувача до автоматизованої системи розміщення замовлень або СУБД (скажімо, креслень відділу НДР). Справа ускладнюється ще й тим, як служба ІТ іменує ці ресурси (web14 або, гірше того, 10.1.2.3), при цьому бізнес-призначення того чи іншого ресурсу (що є, наприклад, частиною системи контролю за виконанням замовлень) повністю ігнорується. Щоб вести конструктивні дискусії на тему управління ризиками, необхідно усунути цей розрив. Найбільш прогресивні служби ІТ і безпеки вже навели тут мости спільно із зацікавленими бізнес-підрозділами компаній. Без цих кроків шанси конструктивно обговорити ризики будуть мізерно малі, а вже їх ранжувати – і того менше.

В процесі обговорення також важливо правильно вживати терміни “вразливість” і “загроза”, оскільки їх часто плутають. Несуворі визначення свідчать, що уразливість – це стан або знаходження в ньому ресурсу, результатом чого може бути нанесення шкоди підприємству; а загроза – це сутність або дія, здатні завдати такої шкоди. Подальше занурення в тонкощі використання цих термінів у ІТ та ІБ зажадало б написання окремої статті. Поки ж ми обмежимося ще одним нагадуванням про важливість їх правильного вживання при обговоренні ризиків. Як на приклад всеосяжної дискусії на тему термінології в управлінні ризиками в ІТ пошлемося на методику FAIR.

Що може статися?


Визначившись з ресурсами, уразливими і погрозами, ми нарешті впритул підійшли до вельми і вельми “слизькій” теми, а саме: визначення ймовірності. На жаль, і тут управління ризиками в ІТ потребує у вдосконаленні як ніяка інша галузь, серед іншого, внаслідок значної частки суб’єктивізму при недоліку статистичних даних. Зрілий підхід підказує, що поняття ймовірності, в більшості випадків виражається якісно, ​​варто було б замінити поняттям частоти, що оцінюється кількісно і розраховується статистично. Підрозділи ІТ, утворюють ще порівняно молоде співтовариство серед професіоналів в галузі управління ризиками, навряд чи можуть розраховувати на швидку появу в їхньому розпорядженні актуарних таблиць по всім можливим інцидентам, якщо таке взагалі можливо. Можна сподіватися, що оволодіння методиками, начебто FAIR, і використання байєсівського підходу допоможе заповнити деякі наявні прогалини, але навіть якщо спочатку ми обмежимося лише визначенням найважливіших метрик, подій і критичних втрат, то вже одне це стане великим кроком вперед.

Залишимо на час розмова про основи управління ризиками і задамо собі ось який важливе питання: як навчитися спокійно сприймати те, що відбувається? Спілкуючись з прихильниками традиційного підходу до ІБ, після слів “визначити ризик” зазвичай чуєш “послабити ризик”, рідше – “перекласти ризик”, а вже про “допустимому ризику” ніхто з них взагалі не говорить. Тут слід було б дещо уточнити, а саме: “перекладання ризику “не має нічого спільного з технологією, а лежить цілком у сфері страхування і законодавства, і тут багато чого ще належить вчитися.

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

Перекладаючи розмову в звичну площину ІБ, сформулюємо питання по-іншому: що для вашої організації важливіше – боротьба з “черв’яками” і вірусами або шифрування персональних даних? Чи знизить виявлення мережевих вторгнень ризик більше, ніж шифрування дисків всіх ноутбуків організації? Чи відомо нам, які системи підприємства є критично важливими і які – найменш важливими, враховуємо ми це розходження на практиці? Чи не потрібно в процесі навчання користувачів основам ІБ поряд із заходами захисту від “зла” також приділяти увагу заходам захисту від “дурня”? Ну і, нарешті, що слід віддати перевагу – поганеньку захист всього і вся чи належний захист мінімального набору ресурсів?

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

Ретельно вибирайте проект …


Коли мова заходить про конкретні кроки в справі забезпечення ІБ, на розум завжди приходить одна і та ж завчена мантра: “Будьте проактивними!” На жаль, на практиці акцент, як і раніше робиться на вжиття заходів, спрямованих на запобігання вже сталося … Зрозуміло, реагувати на події реального світу – це не чиясь примха, а нагальна необхідність. Але не дозволяйте боязні минулого повністю опанувати вами. Тут вас підстерігають дві небезпеки: порушення балансу стратегічних і тактичних заходів і страх упустити з виду безперервно розвивається ситуацію з виникненням все нових загроз.

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

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

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

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

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

… І приймайте правильні рішення


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

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

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

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

Від професіоналів ІБ нам часто доводиться чути таке: “Наша система контролю вразливостей чудово працювала півроку, потім ми деінсталювати її”.

Чи потрібно нам зупинитися на цьому і визнати, що всі технології ІБ, м’яко кажучи, далекі від досконалості? Ні, ми все-таки вміємо робити уроки з минулого: парольний захист як і раніше служить нам, але ми не покладаємося виключно на неї. Процедури “латання” і оновлення ПЗ вбудовуються тепер безпосередньо в ОС, і, навіть якщо не брати до уваги рекламну галас навколо NAC, що надходять на ринок мережеві пристрої оснащуються захисними функціями. Та й серед постачальників ПО спостерігається прагнення гарантувати якість і безпеку їхньої продукції.

Рухаючись далі, ми змушені не тільки продовжувати вчитися на своїх помилках, а й приймати на озброєння інноваційні стратегії. Для початку не випустите з уваги тенденцію до консолідації наборів властивостей продуктів. Коли якась захисна функція ІТ-продукту підноситься як його базової характеристики, слід задатися питанням: це все-таки продукт або функція? Для прикладу візьмемо полнодісковое шифрування (Full Disk Encryption – FDE). Не дивно, що після хвилі витоків конфіденційної інформації, що стали результатами крадіжок ноутбуків, впровадження в ІТ-продукти технологій FDE розгорнулося повним ходом. До недавніх пір підприємства впроваджували у себе спеціалізовані FDE-пакети, сьогодні ж провідні виробники вбудовують ці функції у свої продукти. Для прикладу: ряд моделей ноутбуків Think-Pad від Lenovo поставляються з вбудованими функціями FDE, доступними завдяки використанню підтримують шифрування жорстких дисків Seagate Momentus; опція FDE, відома під назвою BitLocker, є також в деяких версіях ОС Windows Vista. Враховуючи дану тенденцію до консолідації, просунуті підприємства та організації вимагають від своїх постачальників ІТ, щоб ті спочатку включали функції безпеки як в інфраструктурні рішення, так і в продукти для кінцевих користувачів.

Дивлячись вперед


Для забезпечення ІБ так чи інакше потрібні продукти і технології, але при всьому при цьому не менш необхідний збалансований підхід. Чи слід піддаватися пропаганді і займатися впровадженням рішень NAC або краще зашифрувати всі носії даних? Чи допоможе виявлення аномалій поведінки користувачів в мережі знизити ступінь ризику для організації або в даному відношенні для неї важливіше ретельно вивірені процедури виділення ресурсів? Чи не краще зайнятися виробленням політики безпеки для мобільних пристроїв, ніж витрачати час на аналіз журналів подій систем IDS?

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

У зв’язку з цим виникають питання: яка частина відповідальності за ІБ підприємства відійде до CRO і яка залишиться за службою ІТ? не ігноруємо ми має місце в дійсності тісний зв’язок ІБ з безперервністю ведення бізнесу і його стійкістю до катастроф (disaster recovery / business continuity)? Цим питанням вже починають приділяти увагу, але, на наш погляд, недостатнє.

Для нас очевидно одне: або нам, професіоналам ІТ, потрібно зробити над собою зусилля і стати менеджерами з управління ризиками, або замість нас ними стануть інші ..

Схожі статті:


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

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*