назад Оглавление вперед


[Старт] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [ 66 ] [67] [68] [69] [70] [71] [72]


66

Примеры регулярных отчетов и включаемых в них событий: Подпроцесс планирования:

•отчеты о степени соответствия соглашению SLA и согласованным ключевым показателям качества по вопросам безопасности;

•отчеты о внеиитх договорах и связанных с ними проблемах;

•отчеты об Операционных Соглашениях об Уровне Услуг (внутренпие Планы по безопасности) и собственных иринпипах безопасности поставиип<а (например, ио базовому Уровню Безопаспости);

•отчеты о годовых планах но безопаспости и планах действий.

Подпроцесс внедрения:

•отчеты о С0СГ0Я1П1И дел в информационной безопаспости. Сюда входят отчет о выполнении годового плана по безонасности, перечень осушествлениых или намеченных мер, информация об обучении, результаты дополнитсльно[0 анализа рисков и т. д.;

•перечень ипцидеитов, связанных с безопасностью и ответных мер, возлюжно, в с[)авненип с предыдущим отчетным периодом;

•определите тенденций возникновения инцидентов;

•состояние программы оиоветеиия.

Подпроцесс оценки:

•отчеты об .эффективпослт! подпроцессов;

•результаты аудиторских проверок, анализа и внутренних ouchoic;

•предупреждения, определение новых угроз.

Специальные отчеты:

Для сообп1ений об определенных в соглашетш SLA инцидентах, связан1П5х с безопасностью, поставщик услуг должен иметь прямой канал связи с представителем заказчика (возможно, инспектором информационной безопасности предприятия) через Руководителей Процессов Управления Уровнем Услуг, Управления Инцидентами или Управления Информационной Безопасностью. Должна быть также определена процедура для связи в особых случаях.

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

15.5. Контроль процесса

15.5.1.Критические факторы успеха и ключевые показатели эффективности

Критическими факторами успеха являготся:

•полтюе noHHMainie необходимости процесса со стороны руководства и его иривлсчение к процессу;

•привлечение пользователе!! к разработке процесса;

•точное определение и разделеш1е ответственностей.

Показатели .эффективности Процесса У11])авления Информационной Безопасностью соответствуют таким же показателям Процесса Управления Уровнем Сервиса в той степени, в Korojioii послеуите связаны с зат1)агивасмыми в SLA вопросами безопаспости.

15.5.2.Функции и роли

В небольших И1"-оргаиизациях один человек может руководи-1ъ несколькими п)оцесса.ми. В круп-пых же организациях иескоп>ко человек работают над одним процессом, например, таким как Упра-вле]И1е Информагшоиной Безопасностью. В таких случаях обычно назначается одни руководитель Процесса Управления Информационной Безопасностью. Этот руководитель песет ответственность за эффективное функционирование процесса. Его коллегой в организации заказчика является ип-сиектор ин([1ормацнониой безопасности.



15.6. Проблемы и затраты 15.6.1. Проблемы

Следующие аспекты имеют существипюе зиачепие для успешной реализацин Процесса Управления Информационно!! Безонасностью:

•Понимание 1геобходимости процесса (понимание со стороны участников): меры безопасности редко встречают бьютрое положитслыюе поипмапие со сто])опы персонала; ча1це встречается сопро-THBJieiHic, а не одобрение. Пользователи возмушаются noTepeii определенных привилегий из-за введения мер безопасности, даже если эти возможности не являются суи1ествепнылп1 для их работы. Это объясняется тем, ч то привилегии дают им определе1Н1ЫЙ статус. По.этому необходима специальная работа по мотивации пользователей и получению согласия руководства на введение мер безопасности. Особенно в области Управления Информационной Безопасностью руководство должно показать irpuMC]) («разъяснять курс» и «вести за собой»). При отсутствии инцидентов по безопааю-стн у руководства может возникнуть искушение сократить расходы па Управление Безопасностью.

•Отношенпе: пн(юрмациопные системы небезопасны не из-за их технического несовершенства, а из-;{а ошибок при псполыюваппи технологии. Обычно это свя:тано с человеческим отношением и поведением. Это означает, 4T(j процедуры безопасности должны быть нитегрирова1П1 в рутинные операции.

•Осведомленность: осведомленность тгли, скорее, коммуникации является ключевым понятием. Между коммуникациями и безопасностью иногда возьипсает конфликт интересов: коммуникации мостят дорогу, а безопасность создает препятствия. Это означает, что реализация мер бе:«)пасно-сти требует нспользования всех сгюсобов коммуникаций для того, чтобы пользователи приняли необходимый стиль иоведсния.

•Верификация: должна существовать возможность проверки и верификации безопасности. Это относится как ко BBO/uiMbiM мерам, так и к причинам их введения. Необходима возможность убе-;Титься, чт(з в соответствующих обстоятельствах приняты правильные решения. Например, должна быть возможность проверки полномочий тех, кто принимал решетш.

•Управление Изменениями: часто при проведении из.менений ослабе1!ает качество оцопси соответствия базовому Уровню Безопасности.

•Амбиции: при желании оргаинзации делать все сразу часто возникают ошибки. В случае введения Процесса Управления Ииформациоппой Безопасностью реа.пизация технических мер гораздо менее важна по сравнению с организацнопными мерами. РЬменение организации требует поэтапного подхада и занимает длительное время.

•Отсутствие систем обнаружения: новые системы, такие, как Интернет, не были рассчитаны на безопасность и необходимость обнаружения взлома. Причина заключается в том, что разработка запщщепной системы требует больше времени, чем незащищенной, и находится в конфликте с требованиями бизнеса по невысокой стоимости разработки и скорейшей поставке иа рынок.

•Чрезмерные надежды на технологию «неприступной крепости»: уфозы безопасности систем все 4an.ie возникают в непредсказуемых местах. Сравните первые атаки вирусов ILOVEYOU и Nimda с первым примером атак Denial of Service (DoS). В то время как запщта ин(1)ормации с использованием традиционного подхода «непристушгой крепости» сохраняет свое значение, также приобретает важность гюдхода «встречных атак» при возшнсповении наруп:ений безогщсности. Организация должна иметь возможность быстро направить ресурсы в место возннк1Гопсти1я дефекта до того, как он сможет выйти нз-нод контроля.

15.6.2. Затраты

Защита ИТ-ипфраструщ-уры требует привлечения персонала, а следовательно, и денег для принятия, по;и1ержки и н]юверки мер безопасности. Однако неспособность защитить ИТ-иифраструктуру также стоит денег (стоимость непроизвсдешюй продукции; стоимость замены; ущерб для данных, программного илп аппаратного обеспечения; потеря репутации; штрафы илп компенсации в связи с иевозмож-н(хтыо в1,толпения договорных обязательств). Как всегда, необходимо соблюдение баланса.



1Ь. VrmbMs-sNfe ИМФ01>МА14ИОй1ИОЙ ШЕОПАОЮОЫО 15.6. Проблемы и затраты

15.6.1. Проблемы

Следующие аспекты имеют сутестнешюе значение для успешной реа.анзацнн Процесса Управления Информационно!! Безо11ас1!ость!о:

•Понимание необходимости процесса (понимание со стороны участников): меры безоиас!юсти редко встречают быстрое положительное понимание со сто1Юиы псрсопача; ча1!(е встречается сопро-T!!!yieii!ic, а не олобре!1ие. Пользователи 1Юзмуп!а!огся потере!! опрсде;!е1!Ных 1!ривилегий из-за вве-деи!!я мер безопас1!ости. даже если эти возможности не являются cymecT!JC!nibiN!n д;!Я их работы. Это объясняется тем, чго привилегии дают нм определе1Н1ЫЙ статус. Поэтому необходима специаль-!!ая работа !io мотива1И!и пользователей и получению согласия руководства иа введение мер безопасности. Особе!!!10 в области У1!равле1!ия Информацион1!ОЙ Безопасностью руководство должно 1!0казать примс]) («разъясня--ь курс?> и «вести за собой»). При отсутствии !И1цидентов по безопасности у ру!соводства может возиик!1уть искушение сократить расходы на Управление Безо!!ас!10стыо.

•Отношение: нн()орма1и!0!П!ые системы небезопасны iie из-за их техиичес1ч-о!-о несовер!ие!1ства, а из-за ошибок !1ри испол!130ва!1ии технологии. Обычно это с.пязшо с человечеслшм отно11!ением и !10!1едснисм. Э1-о означает, чтс; процедуры 6езо!1асности должны быть иите!~рирова1И11 в рути!!ные

0ПСра!1!1И.

•Осведомленность: осведомле!1ность или, скорее, комму1!Ика!и1И является ключевым ио!!ятием. Между комму!И!ка!П1ями и безопасность!о ино!-да возникает конфликт интересов: коммуникащп! мостят доро17, а безопасность создает препятствия. Это означает, что реализация мер безо1!асно-сти требует !1С!!ользова1!ия всех способов коммуникаций для того, чтобы пользователи приняли псобход!!мый стиль иовсдсния.

•Верификация: должгга существовать возможность проверки и верификации безопасности. Это относится как ко вводимым мерам, так и к причинам их введс1!ия. Необходима возмож1!ОСть убедиться, ч-о в соответствующих обстоятельствах приняты правильные решения. Например, долж-!ia быт1> возможность проверки полномочий гех, кто принимал рсшеиия.

•Управление Изменениями: часто при проведении изме!1е1И1й ослабе!!ает качество оце1!ки соответствия базовому Уровню Безопасности.

•Амбиции: при желании ор!-аиизации делать псе сразу часто вознтсают ошибки. В случае введения Процесса Управления Ииформа1П10!1ной Безопасность!о реализащгя технических мер !-ораздо менее важна по срав!1е!1ию с организа!;иоиными мерами. РЬмепение ор1аиизации требует !1оэтапио-io полхш1а и заггимаег длительное время.

•Отсутствие систем обнаруи<епия: 1говые системы, такие, как И1!!срнет, не были рассчитаны i!a безо!!асность и необходимость обнаружения взлома. Причина зaкJ!Ючaeтcя в том, что разработка занцпценной системы чребуст больше времени, чем !1сзащищенной, и находится в коифлисте с требованиями бизнеса по невысокой стоимости разработки и скореЙ!ией поставке иа рьшок.

•Чрезмерные надежды на технологию «неприступной крепости»: yiposbi безопасности систем все ча!це возникают в непредсказуемых местах. Сравните первые атаки вирусов ILOVEYOU и Nimda с nepB!JM примером атак Denial of Service (DoS). В то время как защи]а ин()орма1Ши с исг!ользова-пием традиционного подхода «пепристу1!1гой крепости?» сохраняет свое значе1!ие, также приоб1)е-тает важность 1!Одхола «встречных атак» ири воз!Н1Кповении нар}чпеиий безогшсности. Орга1!иза-ция должна иметь возможность быстро на1!рави!Ь ресурсьг в место возш1К1Говс!1ия дефекта до то-1-0, как он сможет выйти из-нод контроля.

15.6.2. Затраты

Заишта ИТ-и!фрасгруктуры требует при!игечеиия персонала, а следовательно, и денег для принятия, нод/чержки и н]юверки мер безопасности. Однако неспособность .за1цитить ИТ-иифрастру1Стуру также стоит дспе! (стоимость непроизвсдеппой продукции; стоимость 3aMei!i)i; yi!icp6 для да1!ных, программ-H0IX1 ИЛ1! а11парат!Ю1о обеспече1!ия; потеря репутации; !итрафь1 ил!1 компенсации в связи с невозможностью выполнения до!-овор!1ых обязательегв). Как Bcei-да, !1собход1!мо собл!оде1!ие баланса.

[Старт] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [ 66 ] [67] [68] [69] [70] [71] [72]