Способы классификации угроз

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

По виду активов, на которые они направлены (объектам воздействия), угрозы делятся на:

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

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

По источнику угрозы можно разделить, например, на следующие классы:

  • угрозы со стороны различных классов внешних нарушителей;
  • угрозы со стороны различных классов внутренних нарушителей;
  • угрозы со стороны партнеров и подрядчиков;
  • антропогенные катастрофы (терроризм, взрывы, массовые беспорядки);
  • техногенные аварии (сбои технических средств);
  • природные катаклизмы (землетрясение, наводнение, ураганы и т.п.);
  • несчастные случаи (пожар, обрушение здания и т.п.).

По типу нарушения угрозы можно разделить на следующие классы:

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

Далее мы более подробно рассмотрим некоторые основные классы угроз безопасности.

Угрозы, реализуемые при помощи программных средств

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

К этому классу угроз относится, например, следующее:

  • использование ошибок проектирования, кодирования, либо конфигурации для получения НСД;
  • использование закладок в ПО, оставленных для отладки, либо умышленно внедренных;
  • сбои в работе средств защиты информации;
  • маскарад, перехват паролей или взлом паролей пользователей;
  • нецелевое использование ПО;
  • анализ сетевого трафика с целью перехвата информации;
  • замена, вставка, удаление или изменение данных пользователей в информационном потоке;
  • ошибки пользователей и технического персонала;
  • внедрение вредоносного ПО;
  • утечка конфиденциальной информации по электронным каналам связи (электронная почта, системы мгновенных сообщений и т.п.) либо на внешние устройства и носители информации;
  • и т.п.

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

Угрозы утечки информации по техническим каналам

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

К данному классу угроз относится следующее:

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

Угрозы в отношении программных средств

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

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

  • порча ПО и резервных копий;
  • внесение несанкционированных изменений в исходные тесты ПО;
  • использование нелицензионного ПО;
  • нарушение лицензионных соглашений;
  • нарушение конфиденциальности программных кодов.

Угрозы техническим средствам

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

В этом классе целесообразно рассмотреть следующие основные виды угроз:

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

Источниками угроз в отношении технических средств могут служить:

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

Подробный перечень угроз безопасности, обычно рассматриваемых при оценке информационных рисков, приведен в Приложении № 5.

Задание № 1. Описание угроз безопасности

________________________________________

Опишите профиль и жизненный цикл для одной из следующих угроз:

  1. Заражение компьютерным вирусом
  2. Атака на отказ в обслуживании
  3. Несанкционированный доступ к системе и хищение конфиденциальной информации
  4. Выход из строя файлового сервера
  5. Пожар в офисе

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

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

________________________________________

Профиль и жизненный цикл угрозы

Формально угрозу можно описать, используя понятия профиля и жизненного цикла угрозы.

Профиль угрозы определяется следующими статичными атрибутами:

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

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

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

  • зарождение;
  • развитие;
  • проникновение в АС;
  • проникновение в критичную информацию;
  • инициализация;
  • результат действия;
  • регенерация.

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

Профиль угрозы:

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

Жизненный цикл угрозы:

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

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

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

Разработка профилей угроз является полезным упражнением для эксперта по оценке рисков. Эта задача требует определенного навыка. Далее мы рассмотрим различные виды и классификации угроз безопасности более подробно. Однако, прежде чем переходить к следущим разделам, рекомендуем вам самостоятельно выполнить Задание №1.

Анализ угроз и уязвимостей

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

Угрозы информационной безопасности на редкость разнообразны. Сориентироваться в этом разнообразии помогают перечни угроз, приведенные в приложениях к стандартам BS 7799-3 и ISO 27005. Одно из наиболее детальных описаний тысяч угроз информационной безопасности можно встретить в открытом немецком стандарте BSI IT Baseline Protection Manual (Базовое руководство по защите ИТ).

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

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

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

Определение приоритетов аварийного восстановления

– Внимание, Земля! Говорит станция «Мир»! У нас отказал бортовой компьютер. Что делать?
– Станция «Мир»! Станция «Мир»! Это диспетчер! Слышите меня?
Играйте пока на резервном! Играйте на резервном!

Анекдот

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

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

Согласно определению британского стандарта BS 25999-1, управление непрерывностью бизнеса (УНБ) – это процесс, связанный с бизнесом и развивающийся в зависимости от него, в ходе которого в соответствии с поставленными целями формируется система, направленная на следующее:

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

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

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

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

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

На этапе планирования УНБ организации следует определить и документально зафиксировать воздействие, которое способно оказать нарушение нормального хода различных видов деятельности, обеспечивающих производство основных продуктов и услуг. Данный процесс часто называют анализом воздействия на бизнес (business impact analysis). Анализ воздействия на бизнес – это процесс анализа функций, выполняемых бизнесом, и воздействия, которое может на них оказать нарушение нормального хода бизнеса.

Для каждого вида деятельности, обеспечивающего производство основных продуктов и услуг, в рамках программы УНБ организация должна:

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

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

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

При оценке воздействия организации следует учитывать его составляющие, относящиеся к целям и задачам бизнеса и заинтересованным сторонам. Сюда могут относиться:

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

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

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

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

В течение основного периода после аварийного восстановления придется смириться с определенным сокращением работоспособности. Для целей планирования необходимо определить два ключевых положения:

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

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

Для оценки критичности прикладных систем используются семь показателей, позволяющих установить степень уязвимости приложения к падению производительности ИТ инфраструктуры после аварии, а также ограничения, которые могут возникнуть при восстановлении приложения:

  1. Допустимое время, которое может пройти перед тем, как приложение заработает после аварии.
  2. Особые ресурсы, которые необходимы в случае, если приложение будет восстанавливаться.
  3. Способность приложения переносить смену компьютера в процессе восстановления.
  4. Опыт сотрудников в тестировании процесса восстановления.
  5. Предельные значения потерь, на которые можно пойти, если восстановление приложения задерживается или невозможно.
  6. Структурные или функциональные ошибки, которые могут присутствовать в приложении.
  7. Требования к структуре или функционированию.

Все эти факторы вместе определяют относительную важность после аварийного восстановления данного приложения. Оценки отдельных факторов располагаются в следующем порядке:

  • Время восстановления:

5 – требуется достичь среднего уровня производительности за время от 4 до 6 часов после аварии;

4 – требуется достичь среднего уровня производительности за время от 7 до 12 часов после аварии;

3 – требуется достичь среднего уровня производительности за время от 13 до 24 часов после аварии;

2 – требуется достичь среднего уровня производительности за время от 25 до 48 часов после аварии;

0 – никаких ограничений по времени восстановления.

  • Потребность в особых ресурсах:

5 – восстановление в достаточном объеме возможно только при восстановлении специальной базы данных и/или программной/аппаратной части заказчика и/или средств связи по некоммутируемым линиям;

4 – возможно функционирование в достаточной мере при использовании связи по коммутируемым линиям, если есть все необходимые ресурсы;

3 – достаточная степень производительности может быть обеспечена при частичном восстановлении ключевых ресурсов (например, при использовании текущей/резервной версии базы данных);

2 – для восстановления не нужно никаких уникальных ресурсов;

0 – может функционировать в течение периода после аварийного восстановления даже при отсутствии отдельных блоков и подсистем.

  • Переносимость:

5 – приложение не может быть восстановлено нигде, кроме основного рабочего компьютера;

3 – приложение может быть успешно перемещено, но с задержкой, превосходящей фактор времени данного приложения;

0 – при перемещении приложения не предвидится никаких трудностей.

  • Необходимая квалификация:

5 – сотрудники не смогли успешно протестировать процесс восстановления приложения;

3 – тестирование восстановления приложения было успешным, но достигнуто это было с большой задержкой;

0 – тестирование восстановления прошло успешно. Не было встречено никаких проблем.

  • Устойчивость к потерям:

5 – задержка с восстановлением, скорее всего, приведет к финансовым потерям, превышающим пределы, установленные руководством;

4 – задержка с восстановлением вызовет проблемы с главными заказчиками/поставщиками, которые превысят эксплуатационные или установленные руководством пределы;

2 – приложение должно быть успешно восстановлено, но проблемы потерь, связанные с неполным или задержанным восстановлением, не выходят за установленные пределы;

0 – при задержанном или неполном восстановлении никаких проблем или потерь не предвидится.

  • Рабочие неисправности:

5 – успешное восстановление и «нормальная» эксплуатация требуют непосредственного участия основного программиста и оператора;

4 – приложение нуждается документировании;

3 – Приложение имеет значительную чувствительность к изменениям в объемах входных данных, их качеству и/или имеет склонность к отказам;

0 – никаких известных дефектов.

  • Необходимый уровень защищенности:

5 – приложение содержит важные для компании сведения;

4 – приложение содержит систему управления финансовыми активами;

0 – не нужны никакие дополнительные меры безопасности сверх организации обслуживания на время процесса восстановления.

Особенности интервьюирования бизнес-пользователей

Ребенок подходит к отцу и говорит: «Папа-а, а че это? Я яблоко откусил, а оно полежало и стало из белого желтым.»
Папа: Понимаешь, сынок, любое яблоко содержит элементы железа. Когда они вступают во взаимодействие с молекулами кислорода, то происходит процесс, известный в неорганической химии как процесс окисления. Этот процесс и вызывает изменение окраски любого железосодержащего вещества…
Сын: Папа-а, а ты сейчас с кем разговаривал?!

Анекдот

Грамотное проведение интервью с представителями бизнес-подразделений – задача весьма нетривиальная, требующая определенного опыта, знаний и правильного подхода. Стратегической ошибкой было бы поручать эту задачу человеку плохо подготовленному, да еще и не обладающему представительской внешностью, например студенту-практиканту.

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

_____________________________________

Курьезные вопросы, получаемые группой технической поддержки Panda Security и лабораторией PandaLabs

1. Вирусы, инфицирующие физические компоненты ПК

Несколько месяцев назад инженеры PandaLabs получили загадочную коробку, отправленную одним из клиентов Panda в Германии. В коробке обнаружилось письмо на чистейшем немецком со следующим содержанием: “Уважаемые господа, я являюсь вашим клиентом. Убедившись, что самостоятельно не могу дезинфицировать компьютерный DVD-привод, я извлек его и отправляю вам для чистки и последующего возвращения мне. Искренне ваш”. В коробке лежал пустой DVD-привод.

2. Антивирусы, вышибающие электрические пробки

Вот письмо одного из наших клиентов: “Здравствуйте. На протяжении некоторого времени у меня были неисправны пробки, и до тех пор, пока энергоснабжение не было восстановлено, я оставался без электричества (света, холодильника и других электроприборов). Я кое-что проверил и пришел к выводу, что причиной может быть мой антивирус “Panda Titanium”, которым я очень доволен. Я думаю, что антивирус вышиб пробки при попытке скачать обновления в то время, когда компьютер был выключен. Это могло послужить причиной?”.

3. Говорящие вирусы

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

Это очевидно, что вирусы ведут себя нахально и прячутся в самых неожиданных местах. Вот еще пример: “Мой компьютер неделю назад заразился вирусом. Используя акустические колонки, вирус сказал: “Ты – дурак”. У меня нет биоса, у меня нет ничего, кроме материнской платы (Asus k8v Deluxe) и микрофона (AMD 64-bit), оперативной памяти и графической памяти. Он постоянно повторяет одни и те же слова: “Ты – дурак”. Я заменил биос, но это не помогло. Мне показалось, что я знаю, где искать этот вирус: он находится на чипе в 1MB на материнской плате (w55f10b). Я не могу перепрограммировать ее, так как внутри находится целых 3 чипа (один из них – аудиочип). Я купил другую материнскую плату, точно такую же, как моя старая, установил ее, еще установил микрофон, оперативную память и графическую плату. Я был в шоке, когда выяснилось, что слова продолжали повторяться.»

4. «Претадионы» Windows отключают антивирус

Мы не могли поверить своим глазам, когда клиент прислал нам следующий вопрос: “Антивирус становится неактивным, когда Windows запускает претадионы. Должен ли я закрывать panda antivirus, когда Windows закрыт?”

5. Вирусы, которые издают звуки

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

Уже на протяжении некоторого времени у меня не получается заставить работать мой ActiveScan Pro. Я ввожу имя пользователя и пароль, но единственное, что происходит, – «пукание» (простите за выражение)”.

Эта информация была опубликована представителями компании Panda Security в антологии компьютерного юмора на портале ISO27000.ru.

____________________________________________

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

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

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

_____________________________________

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

___________________________________________

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

Таблица ценности активов

Результаты оценки ущерба сводятся в таблицу ценности активов. В «Примечаниях» надо подробно описывать, в чем будет заключаться ущерб и почему он оценивается именно таким образом. Это позволит обеспечить воспроизводимость результатов и предоставить обоснование оценки рисков для руководства организации и владельцев бизнеса.

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

Критерии оценки ущерба

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

Для оценки возможного ущерба в результате осуществления угроз в отношении активов могут использоваться следующие критерии:

  • У1 – ущерб коммерческим интересам партнеров и третьих лиц;
  • У2 – санкции со стороны правоохранительных и регулирующих органов (штрафы, административная и уголовная ответственность);
  • У3 – ущерб коммерческим интересам организации;
  • У4 – финансовые потери;
  • У5 – ущерб репутации организации;
  • У6 – дезорганизация деятельности, ухудшение морального климата в коллективе, снижение эффективности работы.

Для оценки величины возможного ущерба может использоваться пятибалльная качественная шкала, показанная на рисунке.

Здесь 0 – минимально возможный (незначительный) ущерб, 4 – максимальный ущерб (разрушительные последствия для организации). Оценка ущерба дается для каждого свойства актива (конфиденциальности, целостности и доступности) независимо.

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

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

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

Определение ценности активов

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

____________________________________________

Этапы определения ценности активов:

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

_____________________________________

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

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

Согласно ISO 27002 (раздел 7.2) информация и другие активы организации должны быть классифицированы в соответствии с идентифицированной ценностью активов, законодательными и бизнес-требованиями и уровнем критичности. Классификация показывает потребность, приоритеты и ожидаемый уровень защиты при обращении с информацией. Определение классификации, а также ее пересмотр с целью предоставления гарантий того, что классификация остается на соответствующем уровне, входит в обязанности владельца актива.

________________________________________

Классификация последствий нарушения безопасности активов:

  • Последствия угроз:
  • К – нарушение конфиденциальности;
  • Ц – нарушение целостности;
  • Д – нарушение доступности.
  • Последствия нарушения требований:
  • Т1 – нарушение требований бизнеса;
  • Т2 – нарушение контрактных обязательств;
  • Т3 – нарушение законодательства.

______________________________________

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

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

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

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

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

Требования бизнеса

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

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