threat

Угроза в ITSM — это потенциальный источник вреда для услуги, продукта, компонента ИТ-инфраструктуры или способности организации предоставлять и поддерживать ИТ-услугу. Смысл термина в том, что угроза сама по себе ещё не является инцидентом: она описывает возможность неблагоприятного воздействия при наличии уязвимости и условий для её реализации. На практике угрозы учитываются при оценке риска, проектировании мер защиты и обеспечении устойчивости организации: в управлении информационной безопасностью это может быть вредоносная активность, утечка данных или злоупотребление полномочиями, а в управлении непрерывностью услуг — события вроде пожара, наводнения или длительного отключения электропитания. Также термин применим в управлении проблемами и управлении доступностью, когда анализируются факторы, способные вызвать сбой или деградацию услуги, и принимаются меры по снижению вероятности или влияния. Вне области понятия «угроза» находятся уже произошедшие факты нарушения, то есть инциденты, а также конкретные слабые места (уязвимости) и последствия в виде потерь ценности; угроза описывает именно потенциальный источник неблагоприятного события.

Частая ошибка — смешивать угрозу с риском: угроза — это возможная причина или источник воздействия, тогда как риск отражает сочетание вероятности и последствий для ценности, включая контекст, критичность услуги и эффективность контролей. Другая типичная путаница — угроза против уязвимости: уязвимость является слабым местом (например, отсутствует сегментация сети), а угроза — то, что может это слабое место эксплуатировать (например, злоумышленник, вредоносное ПО или ошибочные действия пользователя). Угроза также не равна событию или инциденту: обнаруженная попытка подбора пароля может быть событием, а успешный компромисс учётной записи с нарушением уровня услуги — инцидентом; при этом исходная угроза остаётся той же. На практике встречается чрезмерно буквальное понимание «угроза = хакер»: в управлении непрерывностью услуг значимы физические и организационные угрозы, включая зависимость от третьей стороны, кадровые риски, сбои электропитания и ошибки изменения. Ещё один подводный камень — считать, что угрозу можно «закрыть» раз и навсегда; обычно управляют не угрозами как таковыми, а уязвимостями и условиями реализации через контроль, архитектурные решения и процедуры.