СОИБ. Оценка рисков. База инцидентов ИБ


Недавно на incidents.su был опубликован отчет по инцидентам ИБ за 2011 год.
База инцидентов вышла на достаточно серьезный уровень в 850 инцидентов, который позволяет её использовать в некоторых задачах. Хочется надеется, что авторы ресурса incidents.su и приведенного отчета (кроме них в России базы инцидентов ведутся компаниями Infowatch и Group-IB) планируют использовать данную базу не только в своих целях, но и сделают достоянию общественности. 
Ведь любая занимающаяся анализом рисков нуждается в такой базе, для проведения точных расчетов.  Но пока нет базы, готовой к применению.

1.            Зачем такая база нужна организации проводящей анализ рисков ИБ?
Как правило, при оценке рисков выполняются следующие мероприятия:
·        составляется перечень оцениваемых активов (или типов активов)
·        составляется перечень возможных угроз
·        оценивается вероятность реализации угрозы
·        оценивается возможный ущерб от угрозы
·        оцениваются риски ИБ в соответствии с выбранной методологией
Специалист проводящий оценку рисков хочет увеличить объективность своей оценки опираясь на некую историческую статистику.
Для этого может использоваться база инцидентов по всему миру (как правило, объемная, широко охватывающая все возможные угрозы, но для России не совсем точная, в виду отставания в информатизации на 1-2 года), которая детализируется и уточняется статистикой инцидентов по России (пока охват невелик, ввиду закрытости инцидентов в России, но по тому что опубликовано, статистика более точная) и уточняется статистикой по инцидентам внутри самой организации (как правило в базе минимум инцидентов, но их достоверность самая высокая).

Приведу несколько пожеланий к авторам, ведущим базу incidents.su, а так-же ведущим других баз инцидентов ИБ.
2.            Нужно положение о применимости базы. В нем должно быть описано:
·        инциденты связанные с какими угрозами попадают в базу
·        инциденты связанные с какими угрозами не попадают в базу по причине отсутствия публикаций (например, инциденты по которым ущерб минимален)
·        инциденты связанные с какими угрозами не рассматриваются авторами, потому что им не интересны
·        рекомендации авторов по использованию базы, в которых описывается как эта база дополняет или заменяет другие базы – статистики в мире и статистике в организации.

3.            Какую информацию хотелось бы видеть в базе по каждому инциденту:
·        Дату инцидента (статистика по более свежим инцидентам более достоверна)
·        Источник информации об инциденте (пригодится для оценки достоверности информации)
·        Наименование организации в которой произошел инцидент
·        Отрасль организации в которой произошел инцидент (для оценки более достоверна будет выборка инцидентов по своей отрасли)
·        Качественная оценка размера организации по шкале “малый”, “средний”, “крупный” (некоторые инциденты характерны только для крупных организаций, другие наоборот для малых)
·        Текстовое описание инцидента
·        Описание угрозы реализацией которой связан инцидент.
(Нужно для определения вероятности определенной угрозы. Взяв количество инцидентов в год, связанных с определенным классом угроз – получим его вероятность.
Но для этого надо ввести базовую классификацию угроз.  Авторы incidents.su предложили следующие классы угроз: Утечки, DDoS, Взлом, Кража, Фишинг, Сбой, Другое.
Мне кажется данный вариант слишком простым. Надо использовать кукую-то методологию. Например, вариант от ФСТЭК:  угроза = источник угрозы + уязвимость + способ реализации угрозы + объект воздействия + тип несанкционированного воздействия
Способ реализации угрозы – можно как раз использовать классы предложенные авторами. Объект воздействия - тип актива. Тип несанкционированного воздействия – нарушение доступности, целосности, доступности и т.п.)
o   источник угрозы
o   уязвимость, которая использовалась для реализации угрозы
o   способ реализации угроз
o   объект воздействия
o   тип несанкционированного воздействия
·        Сумма ущерба связанного с инцидентом в рублях (нужно для определения степени опасности угроз)
·        Качественная оценка степени ущерба по шкале “низкий”, “средний”, “высокий” (там где не удается сразу оценить в деньгах)
·        Текстовое описание ущерба, на основе которого сделана оценка
В любом случае авторам incidents.su хочу сказать спасибо за начинание и прошу рассматривать данную заметку не как критику, а как возможно полезные предложения.


UPD: Если авторам incidents.su не хвататет ресурсов для реализации каких-то задач или для сбора информации об инцидентых из каких-то источников то было бы логично написать на сайте просьбу о помощи, которую могут оказать другие энтузиасты:

перечень разовых задач:
- написать движок для сохранения инцидентов в базу, для поиска информации по базе
- написать форму для сбора анонимной информции об инцидентах
- написать форму для проверенного сбора информации об инцидентах
перечень постоянных задачи:
- сбор и классификация инцидентов из таких то источников1
- сбор и классификация инцидентов из таких то источников2



Возможно кто-то обладает небольшиз запасом времени и готов помочь если это ему будет инетересно.

Комментарии

Artem Ageev написал(а)…
авторы получают информацию об инцидентах из открытых источников и делают это все бесплатно.
Поэтому 90% твоих пожеланий не выполнимы =)

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

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

И на западе кстати все совсем не лучше (или жду линк на хорошую статистику).
Александр Бодрик написал(а)…
Спасибо за рекомендации, мы честно говоря где-то к тому же пришли раньше, но вот пока что у нас нет программиста что бы все сделать совсем красиво.

Обсудим по пунктам:
2 - у нас уже есть политика учета инцидентов (в начале каждого отчета), и вне сомнений, что мы будем ее улучшать и дорабатывать, в этой связи особенно данный пункт
3 - честно говоря есть видение как реализовать как минимум часть (источник, отрасль и т.п.), но у нас нет программиста что бы сделать это с каким-то вменяемым расходом времени. Я бы ТЗ сделал, но вот именно изучать PHP нет времени..

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

Утечки охраняемой законом тайны, хищения в ДБО, DDoS, взломы, фишинг

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

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

>инциденты связанные с какими угрозами не рассматриваются авторами, потому что им не интересны

Естественно невозможно объять необъятное - но по перечисленным выше стараемся учесть все.

>рекомендации авторов по использованию базы, в которых описывается как эта база дополняет или заменяет другие базы – статистики в мире и статистике в организации

Как Вам удобно, так и используйте.
Началось все с банального несогласия с выборкой - http://personal-data.livejournal.com/277699.html

>Какую информацию хотелось бы видеть в базе по каждому инциденту

Подпишитесь на RSS или в Твиттере. Там будут идти агрегируемые сообщения в которых все указано

>Надо использовать кукую-то методологию. Например, вариант от ФСТЭК

Киньте пинг на мое мыло см. на http://securitywiki.ru/AlexToparenko

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

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

на счет западных ресурсов всё сложно. их много. они в большинстве не публичные и не понятно как к ним получить доступ. Ладно хоть отчеты делают подробные:

http://www.juniper.net/us/en/local/pdf/additional-resources/jnpr-2011-mobile-threats-report.pdf?utm_source=promo&utm_medium=right_promo&utm_campaign=mobile_threat_report_0212

http://www.cisco.com/web/about/security/intelligence/reports/cisco_global_threat_report_4Q11.pdf

http://www.mcafee.com/us/mcafee-labs/threat-intelligence.aspx

http://projects.webappsec.org/w/page/13246995/Web-Hacking-Incident-Database#SearchtheWHIDDatabase

http://www.securityincidents.net/
Сергей Борисов написал(а)…
Александр Бодрик.
Теоретически специалисты могли бы публиковать статистику по своим организациям в некую базу, если бы была обеспечена анонимность.

Но если обеспечить анонимность, как проверить достоверность сведений?
Сергей Борисов написал(а)…
toparenko:
вот меня например интересует статистика по инцидентам:
1) пожарам или затопленим в офисных зданиях которые привели к недоступности сервисов
2) отключениям электричества в офисных зданиях приведших к недоступности сервисов
3) обрывы каналов связи приведших к недоступности сервиса
4) выхода из строя технических средств приведших к недоступности сервиса
5) утери/кражи ноутбуков
6) утери/кражи флешек
7) внедрения вредоносных программ
8) потери данных в результате ошибки и т. п.

Как я понимаю, такие инциденты либо не попадают в базу, либо попадают самые критические из них?
toparenko написал(а)…
>Как я понимаю, такие инциденты либо не попадают в базу, либо попадают самые критические из них?

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

"Но если обеспечить анонимность, как проверить достоверность сведений?"
Есть 2 варианта - 1) центр доверия, как организовано на роем.ру, т.е. избранный модератор занимается идентификацией, и отвечает за достоверность (но это трудоемкий вариант)...
2) можно рейтинговать по степени достоверности и соответственно учитывать в отчетности с некими весами, в принципе, по аналогии с весами контролей в при оценке соответствия СТО БР ИББС;)

Популярные сообщения из этого блога

СКЗИ. НПА. Некоторые вопросы применения криптографии

Модель угроз безопасности клиента финансовой организации

КИИ. Категорирование объектов, часть 3