Использование отчетов СЗИ при общении с руководством

Использование отчетов СЗИ при общении с руководством

Сначала отыщите факты, а потом непринужденно
манипулируйте ими так, как считаете нужным.

Марк Твен

Вам нужны деньги на новую систему защиты? Вам нужны финансы на поддержку существующей? Вы хотите выбить деньги на свое обучение? Если вы просто придете и попросите денег, то вероятнее всего вам откажут. Поэтому вы должны обосновать трату денег. И вам не обойтись без правильно составленных отчетов, которые лягут на стол руководителю и послужат аргументом в вашу пользу. Как составить отчет и как он повлияет на руководство? Этому и посвящена моя статья.

Руководство и отчеты

Журналы регистрации (в просторечье логи) можно анализировать:

• для составления представления о текущей ситуации с безопасностью в компании или на отдельных ее участках (эта цель останется за рамками текущей статьи, хотя я о ней пару слов и скажу)
• для представления руководству и выбивания из него "чего-нибудь" полезного.

В любом случае анализ логов и генерация на их основе отчетов производятся только с одной целью – совершение некоторого действия. Настройка СЗИ, сканирование сети в поисках дыр, прищучить "продвинутого юзера", выбить деньги на новую СЗИ или обновление существующей, составление служебной записки с рекомендациями и т.п. Без действия генерация отчетов будет бессмысленной тратой времени; если, конечно вы не пишите диссертацию (в моей практике были и такие случаи).

Как должен выглядеть отчет, который ляжет на стол руководителю? Что он может и должен содержать? Ни в коем случае не десятки страниц, на которых в виде таблицы перечислены IP-адреса, с которых фиксировались атаки. Отчет должен передавать основную мысль сразу – начальник не должен думать, что вы хотели сказать своими глубокомысленными фразами. Старайтесь избегать синдрома «нестерпимого желания продемонстрировать свою значимость и свои знания», когда докладчик старается вложить в короткий отчет всю доступную информацию, не заботясь о том, что из этого может извлечь слушатель и читатели. Сконцентрируйтесь на чем-то одном, - не забывайте о русской пословице о двух зайцах. Плохо подготовленный и оформленный отчет, представленный руководству, не только не решает проблему, но и перечеркивает все ваши старания. Отчет для руководства должен быть

• легко читаемым
• легко понятным
• коротким.

Если информации много и ужать ее невозможно (хотя это трудно себе представить), то приложите к отчету пояснительную записку на одну страницу – квинтесенцию (резюме) информации, содержащейся в отчете. Через руководство проходят большие потоки и объемы информации и им нужна точная, четкая, понятная и краткая информация, суть которой можно разместить на одной странице.

Любой руководитель, который вынужден часами просиживать на различных заседаниях и привык к графическому представлению статистики. А посему все, что можно поместить на графики и диаграммы, должно быть туда помещено. Подача информации в таком виде прибавляет веса докладчику и избавляет его от необходимости придумывать способ подачи логов, содержащих десятки тысяч записей. В любом случае помните, что руководителю все равно, с какого адреса идет атака – с 192.168.1.2 или с 192.168.2.1. Ему важно увидеть тенденцию и угрозу для бизнеса.

В любом учебнике по менеджменту написано «Не приносите руководству проблему – принесите ее решение». Тоже применимо и к информационной безопасности. В отчете руководству нужно не просто констатировать факт взлома, состояния безопасности или уровень защищенности, но и что-то просить – денег на СЗИ, увольнения проштрафившегося администратора, поддержки в борьбе с другими подразделениями, обучения и т.п.

Чтобы не связывать ни себе, ни руководству руки, предложите ему в отчете несколько возможных альтернатив и опишите плюсы и минусы каждой из них. Пусть руководство само поучаствует в выборе. Это даст ему почувствовать свою значимость. А чтобы руководитель не ушел в сторону от нужного вам результата, подготовьте заранее все аргументы. Но не перегружайте ими отчет – это может убить интерес к нему. Просто будьте готовы в нужный момент вынуть туза из рукава.

Для придания отчету веса и значимости в отчет можно включить следующие фразы:

• «текущее состояние средств безопасности не обеспечивает достаточной защиты бизнес-ресурсов, в т.ч. и недавно внедренной ERP-системы»
• «информация, хранящаяся в ERP-системе, подвергается значительному риску несанкционированного раскрытия, изменения и уничтожения»
• «текущее положение дел в области информационной безопасности в компании возникло в результате следующих причин: недостаточное обучение, недостаточный штат, отсутствие утвержденной политики безопасности, нехватка средств на СЗИ и ...»
• «необходимо срочно принять неотложные меры по устранению возникшей ситуации и снижению уровня риска ERP-системы. Предлагаю ...»

Очковтирательство или что такое неправильно подготовленный отчет

Сейчас по Москве развешаны рекламные щиты МВД, на которых они отчитываются (перед кем, непонятно) о проделанной за 2003 год и первую половину 2004 года работе. В частности, одним из достижений (а иначе, зачем рекламировать) называется число раскрытых автомобильных угонов - 27 тысяч с небольшим (аналогичная статистика недавно появилась и по компьютерным преступлениям). Это яркий пример очковтирательства, когда цифры выглядят солидно, но не говорят ни о чем. Что такое 27 тысяч? Как изменилось это число по сравнению с прошлым годом? А сколько всего было угнано машин? Может 27 тысяч - это капля в море? А сколько машин возвращено владельцам? Согласитесь, что автовладельца интересует возврат железного друга, а не установление личности угонщика (хотя последнее тоже немаловажно). Аналогичная ситуация и с отчетами, генерируемыми средствами защиты на основе собираемых логов, – правильное их использование может очень сильно помочь вам в вашем нелегком труде, а вот неправильное применение отчетов может навредить состоянию информационной безопасности компании.

Но создать правильный отчет - дело непростое. С одной стороны он должен иллюстрировать работу системы защиты, а с другой - быть понятным для руководства, непогруженного в технические детали. Например, мне не раз (да и вам, наверное, тоже) приходилось слышать такую фразу: "Система зафиксировала 5342 атаки". И что? Из фразы мало что понятно. Кроме того, вопросов после нее возникает гораздо больше. Каких атак? За какой период? Откуда исходят атаки? Куда они направлены? Все эти вопросы очень важны и надо быть готовыми ответить на них. Вдруг ваш начальник, увидев отчет, в котором будет написано про 5432 атаки, спросит вас «Направлены ли они на только что внедренную ERP-систему?»

"Как я могу создавать отчеты, если у меня нет СЗИ?" Так возьмите ее! В Интернет полно свободно распространяемых решений, которые позволят вам собрать неплохую статистику для представляемых руководству отчетов. Да и почти любая компания, работающая на рынке ИБ, не будет возражать, если вы попросите у нее версию с ограниченным сроком действия. В такой ситуации выгода обоюдная. Производитель получает нового потенциального клиента, а вы используете предлагаемое им средство защиты для решения своих задач.

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

Примеры отчетов и их анализ

- Петька, приборы!
- Триста.
- Что "триста"?
- А что "приборы"?

Анекдот

Отчет №1. Система обнаружения вторжений зафиксировала 5342 атаки.

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

Отчет №2. Система зафиксировала 5342 атаки с 1-го по 30 ноября.

И этот отчет тоже никому не нужен и ни о чем не говорит. Хотя он и более грамотен с точки зрения построения отчетов. А каково число атак в предыдущем месяце? А в этот же месяц в прошлый год? А куда направлены атаки и откуда? А какие выводы из него можно сделать, а следовательно, чего вы хотите добиться? Видите, ввод временного параметра сам по себе еще ничего не решает.

Отчет №3. Число атак, зафиксированных системой в ноябре, возросло на 35% по сравнению с ноябрем прошлого года

Более интересен отчет, показывающий рост (или спад) числа атак, т.е. сравнивающий число атак в разные моменты времени. Этот отчет уже показывает динамику и более наглядно иллюстрирует текущую ситуацию с безопасностью корпоративной сети. Разумеется, вы должны предоставить данные, демонстрирующие динамику.

Лучше всего это сделать, используя процентное отношение, хорошо понятное любому руководителю. Итак, отчет может быть таким - "Число атак за прошедший месяц возросло на 35% по сравнению с аналогичным периодом прошлого года". Используя относительные значения, вы также уходите от необходимости указания точных цифр, которые могут и не впечатлить ваше руководство. Этот отчет уже позволяет вам обосновывать увеличения финансирования, связанное с ростом хакерской активности.

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

Отчет №4. Система зафиксировала дыры в сети

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

Если число растет, то возможны следующие ситуации:

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

В качестве действий, следующих за этим отчетом, можно назвать:

• увольнение администраторов-дармоедов
• обучения администраторов
• оплаты поддержки ПО с целью своевременного получении патчей и других обновлений
• оплаты систем управления патчами
• проведение аудита сети.

Но даже если число дыр растет, то надо также смотреть, увеличивается ли число узлов, на которых эти дыры обнаруживается. Если растет теми же темпами, что и дыры, то может быть ничего серьезного и не происходит.

Поэтому на этом этапе необходимо выбрать дальнейшую детализацию. Возможно, что вы решите, что надо в отчет-рекомендацию включить несколько диаграмм, иллюстрирующих различные аспекты одной и той же проблемы. К таким диаграммам можно отнести:

• число критичных атак за прошедший месяц возросло на 35% по сравнению с аналогичным периодом прошлого года.
• число внутренних атак за прошедший месяц возросло на 35% по сравнению с аналогичным периодом прошлого года.
• по сравнению с аналогичным периодом прошлого года число атак на ERP-систему возросло за прошедший месяц на 35%.

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

Использование информации об источниках атак в отчетах

Итак, если за основу взяты источники атак, то необходимо обратить внимание на следующее. Если число источников не меняется при росте атак, то это плохо и означает, что некто (этот некто определяется в результате процедуры реагирования на инциденты) увеличивает свою активность и пытается проникнуть в вашу сеть или вывести из строя ваши ресурсы. А вот если число источников растет вместе с ростом атак, то и тенденции ухудшения ситуации нет (если какой-либо график не опережает другой). Например, постоянно используемый на многих выступлениях (я сам его регулярно демонстрирую) график, иллюстрирующий экспоненциальный рост числа взломанных сайтов, на самом деле ни о чем не говорит. Он имеет смысл только тогда, когда число самих сайтов растет неэкспоненциально. Тогда действительно динамика очевидна. В противном случае, отношение числа взломанных сайтов к общему числу сайтов не меняется и рост числа атак является следствием роста числа узлов в Интернет.

Использование информации о природе атак в отчетах

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

Успешные и неуспешные атаки

Гораздо более важно знать, сколько атак завершилось «успешно» и с каких адресов. Возможно окажется, что все успешные атаки произошли изнутри, а все внешние нападения отражены или блокированы. Надо заметить, что систем, которые в состоянии определить «успешность» атаки практически не существует. Нужна кооперация нескольких систем, например, сканеров безопасности и систем обнаружения атак или систем обнаружения атак и межсетевых экранов и т.п. А для этого необходимо применение систем более высокого уровня, умеющих коррелировать события от разнородных средств защиты. Такие системы есть (например, CiscoWorks SIMS, Intelligent Vision и т.п.) и к ним применимы те же самые рекомендации при подготовке отчетов.

Отчет №5. Система зафиксировала некоторую атаку внутри сети

И этот отчет тоже ни о чем не говорит, даже если в нем указано, что это за атака и куда направлена. Более интересен отчет, сравнивающий записи системы обнаружения атак и межсетевого экрана. Если в логах МСЭ нет записи об атаке, но ее источник внешний, то:

• МСЭ не способен контролировать трафик и его надо менять
• МСЭ плохо настроен и необходимо заняться его конфигурацией.

Такой отчет, который можно получить из системы корреляции или составить собственноручно, позволяет требовать:

• увольнения администратора МСЭ
• обучения администратора МСЭ
• оплаты поддержки МСЭ
• замены существующего МСЭ на новый
• покупки системы обнаружения атак.

Рекомендации по использованию диаграмм и графиков

Данный раздел уже не имеет отношения ни к теме статьи, ни вообще к информационной безопасности. Но я решил его включить, т.к. он напрямую относится к тому, как правильно создавать отчеты. Тем более, что вам вряд ли удастся автоматизировать процесс создания отчетов для руководства. В существующих на рынке системах защиты эти вопросы не учитываются. А уже упомянутые системы корреляции не всем по карману. Самое главное в использовании этих элементов оформления – идея, т.е. понимание того, что вы хотите сказать диаграммой.

Все ваши идеи могут быть описаны всего пятью типами анализа:

• Покомпонентный, при котором доля каждого сравниваемого компонента показывается в процентах от целого. Например, доля атак на ERP-систему составляет всего 15% от всех нападений на информационные ресурсы.
• Позиционный, при котором показывается, как сравниваемые объекты соотносятся друг с другом (одинаковы, больше или меньше). Например, число атак на ERP-систему превысило число атак на внешний Web-сервер.
• Временный, при котором показывается изменение одного или нескольких объектов во времени. Например, число атак на ERP-систему растет каждый месяц.
• Частотный, при котором показывается, сколько сравниваемых объектов попадает в определенные последовательные области значений. Иными словами, данный вариант позволяет обобщить накопленные системами защиты данные. Например, число атак в рабочее дообеденное время – 15%, рабочее послеобеденное время – 35%, нерабочее время – 50%. Этот тип анализа обычно используется для предсказания рисков, вероятности или возможности осуществления какой-либо угрозы, либо для показа некоторой значимой взаимосвязи.
• Корелляционный, при котором показывается наличие или отсутствие связи между сравниваемыми переменными. Например, рост зарплаты сотрудников напрямую связан с уменьшением числа атак на ERP-систему (в данном отчете главное не показывать длительную тенденцию, иначе окажется, что это взаимосвязь действует всего в течение 2-3-х месяцев после повышения зарплаты ;-) Другой пример использования данного типа анализа – показ числа атак до и после установки межсетевого экрана или системы предотвращения атак.

Тип диаграммы определяют не данные, а идея, т.е. тот смысл, который вы вкладываете в диаграмму. Таких типов существует всего 5:

• Круговая – используется при покомпонентном сравнении.
• Линейчатая – используется при позиционном и корреляционном сравнении. В последнем случае используется, если значений мало.
• Гистограмма – используется при временном и частотном сравнении (при числе значений не более 6-7).
• График – аналог гистограммы, но для числа значений, превышающих 6-7.
• Точечная – используется при корреляционном сравнении большого числа значений (в противовес линейчатой диаграмме).

К сожалению, тема эффективного использования графиков и диаграмм достаточно обширна (ей посвящаются даже целые книги) и рассмотреть все ее аспекты в одной статье невозможно. Главное, не доверять создание отчетов, которые лягут на стол руководству, системе защиты. Лучше потратить денек на «ручную» работу, но достичь результата, чем автоматизировать эту задачу, потеряв надежду на достижение цели.

Заключение

Прошли те времена, когда гонцу с плохой вестью отрубали голову. Взлом вашей сети – это конечно плохо, но при правильном подходе это может сыграть вам на руку. Придя с повинной к руководству и заранее грамотно составив отчет и подготовив аргументы, вы можете выйти из кабинета начальника победителем. Но помните, что используемые вами логи нужны только в контексте принятия решения. На их основе должно строиться конкретное решение, вывод или действие. Не надо ставить информацию во главу угла - она нужна только для подтверждения вашего вывода или доказательства предлагаемого решения. Иногда бывает достаточно одностраничного отчета всего с одной диаграммой, чтобы руководство поверило вам и не стало требовать исходных данных, подтверждающих ваши выкладки.

И не забывайте, что в ваших отчетах, в которых идет речь о деньгах, необходимо добиваться, чтобы их прочтение вызвало у руководства понимание всей опасности и возможные последствия. Только в этом случае, отчет будет работать на вас.

Об авторе:

Алексей Лукацкий, Cisco Systems

alukatsk@cisco.com