Hacked World

Hacked world

РусЗнающий об угрозах имеет шанс предотвратить их...
EngWho knows about threats, prevents them

Аналитика

Главная » Статьи » Угрозы

Сравнение различных терминологий в области ИБ

Сравнение различных терминологий в области ИБ

Даже если Ваше объяснение настолько ясно, что исключает всякое ложное толкование, все равно найдётся человек, который поймёт вас неправильно.

Первое следствие из третьего закона Чизхолма


1. Introduction

Если Вы встретились с другим специалистом по ИБ, то если он кивнул в знак согласия, знайте, что он согласился не с Вашим мнением, а с тем как он его понял.

Пример. Одно из самых распространённых слов, используемых ИБ-шниками «угроза, threat». При этом антивирусники понимают под угрозами – появление активности вредоносов. Поэтому покупая защиту от угроз у них, вы покупаете только защиту от угроз, связанных с вредоносным кодом. У DLP-шников угрозы – это угрозы утечки информации. И так далее.

У иностранных коллег не часто используется слово threats. Они используют термины attack, vulnerabilities, иногда risk.

С чем это связано?

В статье постараюсь сравнить основные термины и отношение отдельных специалистов – апологетов той или иной методологии.

2. Terms

Угроза [ISO/IEC 27000:2014]

Рус: возможная причина нежелательного инцидента, который может нанести ущерб [информационной] системе или всей организации

Eng: potential cause of an unwanted incident, which may result in harm to a system or organization

Слабость программного обеспечения [cwe.mitre.org]

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

Eng: Flaw, fault, bug, vulnerability or other error in software implementation, code, design, or architecture that if left unaddressed could result in systems and networks being vulnerable to attack

Угроза безопасности информации [ГОСТ Р 53114-2008]

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

Уязвимость [ISO/IEC 27000:2014]

Рус: слабость актива или управления, эксплуатация которой приведёт к реализации одной или нескольких угроз

Eng: weakness of an asset or control that can be exploited by one or more threats

Уязвимость [ГОСТ Р 56545-2015]

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

Уязвимость программного обеспечения [cwe.mitre.org]

Рус: ошибка в программном обеспечении, способная быть непосредственно использована хакером для получения доступа к системе или сети

Eng: Mistake in software that can be directly used by a hacker to gain access to a system or network

3. Theoretic IS

Приступим. По ISO

Угроза – причина.

Причиной может быть уязвимость. Тогда Угроза = Уязвимость. Однако рассмотрев термин «уязвимость» по ИСО, видим, что

уязвимость – это слабость, которая способна быть поэксплуатирована угрозой.

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

Давайте сравним с ГОСТовским определением.

Угроза - совокупность условий и факторов

Что есть условие: свойство, особенность, неотъемлемая часть, характеристика чего-либо. Например, уязвимость. Уязвимость – неотъемлемая часть программного кода. Наличие уязвимости – условие, необходимое, но не достаточное. Чтобы получилась угроза, должен быть ещё фактор – действие, явление, процесс. Например, запуск нарушителем вредоноса, эксплойта. Итак, пример угрозы по ГОСТ:

запуск нарушителем эксплойта на уязвимость при условии, что она не прикрыта в системе.

Итак, по ГОСТу должно быть и действие, и условие, при котором это действие «выстрелит». А по ISO – для существования угрозы [threat] достаточно действия [cause].

Поэтому,

говоря на английском, слово threat мы должны использовать в смысле «из-за чего, why», а, говоря на русском, слово «угроза» – в смысле «кто и при каком условии».

Идём дальше.

Русский термин «угроза» для ИБшников, существует только в узком смысле – «угроза безопасности информации». Т.е. от реализации угрозы может быть нарушена только безопасности информации – некая абстракция, которую каждый волен понимать, как хочет. Более того, если от нарушения безопасности информации вы не несёте убытков (забросили вы учётку ВКонтакте пару лет назад. Пароль забыли. Но её сбрутили и всё стёрли, а саму учётку перепродали. А Вы не знаете. Вам всё равно. С точки зрения русского ИБ – угроза реализована. А с точки зрения международного threat – нет. Раз ущерба организации нет, то и угрозы нет.

Таким образом, уточним наши выводы:

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

4. Practical IS

В практическом плане ФСТЭК России создал Банк данных угроз безопасности информации. В нём соединены оба подхода. Т.е. есть совместимость с ГОСТовским термином «угроза БИ» и выполнен шаг в сторону иностранного похода. Несмотря на то, что каждую угрозу в Банке данных угроз безопасности информации можно описать формулой:

Угроза действия над объектом

все их можно разделить на две большие группы:

- угрозы, в основном, обусловленные воздействием факторов;

- угрозы, в основном, связанные с наличием условий (уязвимостей).

Например, угроза УБИ.123 «Угроза подбора пароля BIOS» - явно угроза, обусловленная воздействием фактора (нарушитель подбирает пароль). Без действия угроза явно бессмыслена. При этом в описании угрозы даны и условия её осуществления, но тем не менее, это угроз, в основном, обусловлена именно действием.

Второй пример. Угроза УБИ.001 «Угроза автоматического распространения вредоносного кода в грид-системе» - явно угроза, в основном, связанная с наличием условий (уязвимостей). Особо нарушителю ничего на надо делать. Всё само произойдёт в силу особенностей грид-системы. Нарушитель выполняет предыдущий шаг вектора атаки, а данная угроза реализуется практически сама.

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

Итак, ФСТЭК России пошёл дальше и предложил обобщённую методологию. С её точки зрения:

говоря на английском или на русском, слово threat (угроза) мы должны использовать в прагматичном смысле «из-за чего или при каком условии я могу понести убытки?»

5. Vulnerabilities

Что касается уязвимостей и слабостей, то здесь всё проще.

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

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

Т.е. слабости (ошибки) либо способны привести реализации угроз (тогда они являются уязвимостями), либо не особо способны, вряд ли способны (тогда они не уязвимости).

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

Внучка: - May I eat this cake?

Бабушка: - You may if you can.

Дословный перевод не очень понятен:

Внучка: - Могу я съесть этот торт?

Бабушка: - Ты можешь, если сможешь.

Исходя из контекста, в России, мы бы услышали:

Внучка: - Можно я съем этот торт?

Бабушка: - Можно то можно. А ты осилишь?

Поэтому, не смотря на то, что в ГОСТовском термине «уязвимость» использован глагол «мочь», его надо читать, как «быть способным, смочь»:

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

6. Software errors

В ИТ и иногда в ИБ используется понятие программной ошибки.

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

С точки зрения ИТ, ошибки можно разделить на faults (неисправности), flaws (изъяны) и bugs (баги).

- Fault - кривизна рук, т.н. неполное/некорректное функционирование программного кода
- Flaw - например, неправильная обработка запросов программы, воздействую на которые можно создать уязвимость переполнения буфера. 
- Bug - случайная недекларированная возможность, которая проявляется при стечении каких-либо обстоятельств. Например, Y2K Error 

Есть ещё дополнительные классификации багов:

а) по серьёзности:

0 - max) showstoppers;
1) серьёзные;
2) мелкие;
3) *ня;
4 - min) придирки тестировщиков;

б) по частоте появления:

1 - max) постоянно;
2) иногда (самый неприятный тип бага, «плавающий»);
3 - min) только на машине у Заказчика во время приёмки.

Вот и основные отличия.

 

PS.

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


Если Вам понравилось - поделитесь ссылкой с друзьями в соцсетях. Кнопки ниже:
Категория: Угрозы | Добавил: vaminakov (21.02.2017) | Автор: Vladimir Minakov
Просмотров: 608 | Теги: term, Vulnerability, Threat, уязвимость, угроза, термин | Рейтинг: 0.0/0
Всего комментариев: 0
Среда
21.08.2019
06:47
Вход на сайт
Категории раздела
Угрозы [5]
Аналитические материалы об угрозах, моделях угроз безопасности информации
Уязвимости [1]
Уязвимости кода, конфигурации, документации
Средства и меры [2]
Средства защиты информации, меры защиты информации. Их применение. Проблемы и решения
Требования и рекомендации [5]
Требования нормативных правовых актов. Рекомендации методических документов. ФСТЭК России. ФСБ России. NIST. ISO. ISACA
Популярное
Поиск
Наш опрос
Следует ли использовать сертифицированные средства ЗИ
Всего ответов: 6
Автор в медиа
Блоггер
Читатель твиттера
Архитектор систем защиты информации
Статистика

Онлайн всего: 1
Гостей: 1
Пользователей: 0