О работе CERT.UZ

[Maxim Khalmatov]

Друзья,

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

[Djalolatdin Rakhimov]

а можете предложить методику оценки этого показателя для конкретного данного процесса?

[Maxim Khalmatov]

с лету приходит
1.количество зарегистрированных инцидентов
2. количество инцидентов имевших статус критичный, особо критичный
3. кол-во инцидентов по которым выработано общее решение
4. кол-во инцидентов решенных в процентах к общему кол-ву
5. кол-во выработанных рекомендаций
6. статистика по спаму (?)
7. кол-во аудитов системы ИБ гос предприятий
ну и тд.

[Djalolatdin Rakhimov]

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

[Maxim Khalmatov]

позволю не согласиться. когда нет количественных показателей, необходимо задать качественные. например у меня есть такой показатель как количество решенных инцидентов во время отведенное в SLA. это показатель качества моей работы. как говорит один мой знакомый: Процесс надо строить правильно. Описать все возможные входы, описать деятельности по процессу, указать выходы. Когда вы знаете, что на входе и что на выходе, можете оценить как проходит деятельность внутри. Но на самом деле вопрос более глубокий, мне кажется. Те ваш процесс можно рассматривать как контактирующий с другими. А если так, то и у соседствующих процессов надо вводить параметры. Иначе допустим у вас возможна ситуация:вы не решаете инцидентов, на вас начинают катить "бочку", а возмжно проблема в процессе сбора инцидентов - те построен не правильно, и не может собрать инциденты и подать вам на вход. но это только как пример.
допустим, что ваша служба очень велика. она разбита на различные направления. по каждому направлению есть свои параметры. их конечно не нужно подавать в отчетность вышестоящему начальству. но собрать обощенные критерии и поставить их на оценку качества работы всей службы. ну и конечно все сказанное это мое IMHO :)
Кстати - а скажите где можно узнать четкие критерии, что является инцидентом, который вы будете рассматривать ?

[Ibrohim Djuraev]

Кстати - а скажите где можно узнать четкие критерии, что является инцидентом, который вы будете рассматривать ?

возможно вы имели в виду информацию приведенную здесь (http://cert.uz/about.php?10)

[Djalolatdin Rakhimov]

например у меня есть такой показатель как количество решенных инцидентов во время отведенное в SLA. это показатель качества моей работы.

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

[Evgeniy Sklyarevskiy]

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

[Maxim Khalmatov]

возможно вы имели в виду информацию приведенную здесь (http://cert.uz/about.php?10)


да! большое спасибо :)

[Maxim Khalmatov]

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

не совсем понял ? вопрос где работаю ?

[Djalolatdin Rakhimov]

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

мы к этому идем...

[Iskander Koneev]

Rainbow поднял интересный и актуальный сегодня вопрос.

Разработка метрик, KPI и BSC (balanced score card) для ИТ привлекает внимание многих предприятий. Владельцы и управленцы стали задумываться о том, как оценивать качество и эффективность работы своих и нанятых ИТ и ИБ.

Не уверен, что для CERT количество инцидентов является однозначным KPI…

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

“Высокое количество выявленных инцидентов безопасности – это показатель того, что ИБ предприятия работает хорошо или плохо?”

Предлагайте свои версии, обсудим…

Свой ответ я дам завтра (надеюсь, будет время)

Те, кто был на моем семинаре и знает ответ – не подсказывайте!
:-)

[Djalolatdin Rakhimov]

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

“Высокое количество выявленных инцидентов безопасности – это показатель того, что ИБ предприятия работает хорошо или плохо?”

Предлагайте свои версии, обсудим…

Свой ответ я дам завтра (надеюсь, будет время)

Те, кто был на моем семинаре и знает ответ – не подсказывайте!
:-)

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

Поэтому: большое кол-во (даже) раскрытых инцидентов - плохо, значит они есть. Неизвестно, сколько не заметили.

Важнее показатель качества работы уже реактивной части - доля раскрытых инцидентов с поправкой на неизвестное кол-во пропущенных инцидентов.

Короче, лучше делать профилактику.

[Eldar Ishimbaev]

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

[Iskander Koneev]

Большой дискуссии не получилось…
:-)

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

Смысл в том, что данный KPI (количество инцидентов) нельзя рассматривать оторвано от уровня зрелости предприятия в вопросах ИБ.

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

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

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

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

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

[Djalolatdin Rakhimov]

Согласен, что нужно было рассмотреть вопрос и дать оценку в зависимости от стадии развития. Это существенно. Лично в моем варианты - был только частный случай - при законченной процедуре формирования службы ИБ.

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

[Rustam Yunusov]

Поздравляю службу СЕРТ с ДР.

Уважаемые форумчани и сотрудники Уз-СЕРТ примите искренне поздравления от имени УзАСИ и лично от меня. Вы в течение 2 года сделали много хороших дел для развития УзНЕТа в области ИБ. Желаю Вам долгих успешного работы и дальнейшего развития Вашего Службы.

С уважением Рустам Юнусов!