stringtranslate.com

Уязвимость (вычисления)

Уязвимости — это недостатки в компьютерной системе, которые ослабляют общую безопасность устройства/системы. Уязвимости могут быть слабыми местами как в самом оборудовании, так и в программном обеспечении, которое работает на оборудовании. Уязвимости могут быть использованы субъектом угрозы , например злоумышленником, для пересечения границ привилегий (т. е. выполнения несанкционированных действий) внутри компьютерной системы. Чтобы воспользоваться уязвимостью, злоумышленник должен иметь хотя бы один применимый инструмент или метод, который может подключиться к слабости системы. В этом контексте уязвимости также называются поверхностью атаки . Конструкции в языках программирования , которые сложно использовать должным образом, также могут содержать большое количество уязвимостей.

Управление уязвимостями — это циклическая практика, которая различается в теории, но содержит общие процессы, которые включают в себя: обнаружение всех активов, определение приоритетности активов, оценку или выполнение полного сканирования уязвимостей, отчет о результатах, устранение уязвимостей, проверку исправления — повторение. Эта практика обычно относится к уязвимостям программного обеспечения в вычислительных системах. [1] Гибкое управление уязвимостями подразумевает предотвращение атак путем максимально быстрого выявления всех уязвимостей. [2]

Угрозу безопасности часто ошибочно классифицируют как уязвимость. Использование уязвимости с тем же значением риска может привести к путанице. Риск – это возможность значительного воздействия в результате использования уязвимости. Кроме того, существуют уязвимости без риска: например, когда затронутый актив не имеет ценности. Уязвимость с одним или несколькими известными экземплярами работающих и полностью реализованных атак классифицируется как эксплуатируемая уязвимость — уязвимость, для которой существует эксплойт . Окно уязвимости — это время с момента, когда дыра в безопасности была обнаружена или проявлена ​​в развернутом программном обеспечении, до момента, когда доступ был закрыт, исправление безопасности было доступно/развернуто или злоумышленник был отключен — см. « Атака нулевого дня» .

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

Определения

ISO 27005 определяет уязвимость как: [3]

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

Уязвимость IETF RFC 4949 : [5]

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

Комитет по системам национальной безопасности Соединенных Штатов Америки определил уязвимость в Инструкции CNSS № 4009 от 26 апреля 2010 г. Национальный глоссарий по обеспечению информационной безопасности : [6]

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

Многие публикации NIST определяют уязвимость в контексте ИТ в различных публикациях: термин FISMApedia [7] [8] предоставляет список. Между ними СП 800-30, [9] дают более широкую:

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

ENISA определяет уязвимость в [10] как:

Существование слабости, ошибки проектирования или реализации, которая может привести к неожиданному, нежелательному событию [G.11], ставящему под угрозу безопасность задействованной компьютерной системы, сети, приложения или протокола (ITSEC).

Открытая группа определяет уязвимость в [11] как

Вероятность того, что потенциал угрозы превышает способность противостоять угрозе .

Факторный анализ информационного риска (FAIR) определяет уязвимость как: [12]

Вероятность того, что актив не сможет противостоять действиям агента угрозы.

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

ISACA определяет уязвимость в системе Risk It как:

Слабость в проектировании, реализации, эксплуатации или внутреннем контроле.

Безопасность данных и компьютеров: Словарь концепций и терминов стандартов, авторы Деннис Лонгли и Майкл Шейн, Stockton Press, ISBN  0-935859-17-9 , определяет уязвимость как:

1) В компьютерной безопасности - слабость процедур безопасности автоматизированных систем, административного контроля, контроля Интернета и т. д., которая может быть использована угрозой для получения несанкционированного доступа к информации или нарушения критической обработки. 2) В компьютерной безопасности - недостатки в физическом расположении, организации, процедурах, персонале, управлении, администрировании, аппаратном или программном обеспечении, которые могут быть использованы для причинения вреда системе или деятельности ADP. 3) В компьютерной безопасности — любая слабость или изъян, существующий в системе. Атака или вредоносное событие, или возможность, доступная агенту угрозы, для осуществления этой атаки.

Мэтт Бишоп и Дэйв Бэйли [13] дают следующее определение компьютерной уязвимости :

Компьютерная система состоит из состояний, описывающих текущую конфигурацию объектов, составляющих компьютерную систему. Система выполняет вычисления посредством применения переходов между состояниями, которые меняют состояние системы. Все состояния, достижимые из данного начального состояния с использованием набора переходов между состояниями, попадают в класс авторизованных или неавторизованных, как это определено политикой безопасности. В данной статье определения этих классов и переходов считаются аксиоматическими. Уязвимое состояние — это авторизованное состояние, из которого можно перейти в неавторизованное состояние с помощью авторизованных переходов между состояниями. Скомпрометированное состояние – это состояние, достигнутое таким образом. Атака — это последовательность авторизованных переходов между состояниями, которые заканчиваются скомпрометированным состоянием. По определению, атака начинается в уязвимом состоянии. Уязвимость – это характеристика уязвимого состояния, которая отличает его от всех неуязвимых состояний. Если эта уязвимость носит общий характер, она может характеризовать многие уязвимые состояния; если конкретное, то оно может характеризовать только одно...

Национальный учебно-образовательный центр по обеспечению информации определяет уязвимость : [14] [15]

Слабость в автоматизированных процедурах безопасности системы, административном контроле, внутреннем контроле и т. д., которая может быть использована угрозой для получения несанкционированного доступа к информации или нарушения критической обработки. 2. Слабость в процедурах безопасности системы, конструкции аппаратного обеспечения, внутреннем контроле и т. д., которые могут быть использованы для получения несанкционированного доступа к секретной или конфиденциальной информации. 3. Слабость в физическом расположении, организации, процедурах, персонале, управлении, администрировании, аппаратном или программном обеспечении, которые могут быть использованы для причинения вреда системе или деятельности ADP. Наличие уязвимости само по себе не причиняет вреда; уязвимость — это просто условие или набор условий, которые могут привести к повреждению системы или деятельности ADP в результате атаки. 4. Утверждение, касающееся прежде всего объектов внутренней среды (активов); мы говорим, что актив (или класс активов) уязвим (каким-то образом, возможно, с участием агента или группы агентов); мы пишем: V(i,e) где: e может быть пустым множеством. 5. Подверженность различным угрозам. 6. Набор свойств конкретного внутреннего объекта, который в сочетании с набором свойств конкретного внешнего объекта предполагает риск. 7. Характеристики системы, которые приводят к ее определенной деградации (неспособности выполнять назначенную миссию) в результате воздействия определенного уровня воздействия в неестественной (искусственной) враждебной среде.

Модели уязвимости и факторов риска

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

Атака может быть активной , когда она пытается изменить системные ресурсы или повлиять на их работу, ставя под угрозу целостность или доступность. « Пассивная атака » пытается получить или использовать информацию из системы, но не затрагивает системные ресурсы, ставя под угрозу конфиденциальность. [5]

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

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

Общая картина представляет факторы риска сценария риска. [16]

Система управления информационной безопасностью

Набор политик, касающихся системы управления информационной безопасностью (СУИБ), был разработан для управления, в соответствии с принципами управления рисками , контрмерами для обеспечения того, чтобы стратегия безопасности была создана в соответствии с правилами и положениями, применимыми к данной организации. Эти контрмеры также называются мерами безопасности , но применительно к передаче информации они называются службами безопасности . [17]

Классификация

Уязвимости классифицируются в зависимости от класса активов, к которому они относятся: [3]

Причины

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

Последствия

Последствия нарушения безопасности могут быть очень значительными. [27] В большинстве законодательных актов неспособность ИТ-менеджеров устранить уязвимости ИТ-систем и приложений, если они известны им, рассматривается как неправомерное поведение; ИТ-менеджеры несут ответственность за управление ИТ-рисками . [28] Закон о конфиденциальности обязывает менеджеров действовать так, чтобы уменьшить влияние или вероятность такого риска безопасности. Аудит безопасности информационных технологий — это способ позволить другим независимым людям удостоверить, что ИТ-среда управляется должным образом, и уменьшить ответственность, по крайней мере, продемонстрировав добросовестность. Тест на проникновение — это форма проверки слабости и контрмер, принятых организацией: хакер в белой шляпе пытается атаковать информационные технологические активы организации, чтобы выяснить, насколько легко или сложно поставить под угрозу ИТ-безопасность. [29] Правильный способ профессионально управлять ИТ-рисками — это внедрить систему управления информационной безопасностью, например ISO/IEC 27002 или Risk IT , и следовать ей в соответствии со стратегией безопасности, установленной высшим руководством. [17]

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

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

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

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

Раскрытие уязвимостей

Скоординированное раскрытие (некоторые называют это «ответственным раскрытием», но другие считают этот термин предвзятым) уязвимостей является темой серьезных дискуссий. Как сообщила The Tech Herald в августе 2010 года, « Google , Microsoft , TippingPoint и Rapid7 выпустили руководящие принципы и заявления, описывающие, как они будут бороться с раскрытием информации в будущем». [30] Другой метод, как правило, представляет собой полное раскрытие информации , когда все подробности уязвимости публикуются, иногда с намерением оказать давление на автора программного обеспечения, чтобы тот быстрее опубликовал исправление. В январе 2014 года, когда Google обнаружил уязвимость Microsoft до того, как Microsoft выпустила патч для ее исправления, представитель Microsoft призвал компании-разработчики программного обеспечения к скоординированной практике раскрытия информации. [31]

Инвентаризация уязвимостей

Mitre Corporation ведет неполный список публично раскрытых уязвимостей в системе под названием Common Vulnerabilities and Exposures . Эта информация немедленно передается в Национальный институт стандартов и технологий (NIST), где каждой уязвимости присваивается оценка риска с использованием общей системы оценки уязвимостей (CVSS), схемы общего перечисления платформ (CPE) и общего перечисления слабых мест .

Поставщики облачных услуг часто не указывают проблемы безопасности в своих сервисах, использующих систему CVE . [32] В настоящее время не существует универсального стандарта для перечисления уязвимостей облачных вычислений , оценки серьезности и единого механизма отслеживания. [33] Инициатива Open CVDB — это управляемая сообществом централизованная база данных облачных уязвимостей, в которой каталогизируются уязвимости CSP и перечисляются шаги, которые пользователи могут предпринять для обнаружения или предотвращения этих проблем в своих собственных средах. [34]

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

Дата раскрытия уязвимости

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

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

Выявление и устранение уязвимостей

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

Уязвимости были обнаружены во всех основных операционных системах [36], включая Windows , macOS , различные версии Unix и Linux , OpenVMS и другие. Единственный способ снизить вероятность использования уязвимости в системе — это постоянная бдительность, включая тщательное обслуживание системы (например, применение исправлений программного обеспечения), передовые методы развертывания (например, использование брандмауэров и средств контроля доступа ) и аудит (как во время разработки и на протяжении всего жизненного цикла развертывания).

Места проявления уязвимостей

Уязвимости связаны и могут проявляться в:

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

Примеры уязвимостей:

Уязвимости программного обеспечения

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

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

Смотрите также

Рекомендации

  1. ^ «Жизненный цикл управления уязвимостями | NPCR | CDC» . www.cdc.gov . 12 марта 2019 г. Проверено 04 июля 2020 г.
  2. ^ Дин, Аарон Йи; Де Хесус, Джанлука Лимон; Янссен, Марин (2019). «Этический хакинг для повышения эффективности управления уязвимостями Интернета вещей». Материалы Восьмой Международной конференции по телекоммуникациям и дистанционному зондированию . Ictrs '19. Родос, Греция: ACM Press. стр. 49–55. arXiv : 1909.11166 . дои : 10.1145/3357767.3357774. ISBN 978-1-4503-7669-3. S2CID  202676146.
  3. ^ ab ISO/IEC, «Информационные технологии. Методы обеспечения безопасности. Управление рисками информационной безопасности» ISO/IEC FIDIS 27005:2008.
  4. ^ Британский институт стандартов, Информационные технологии. Методы обеспечения безопасности. Управление безопасностью информационных и коммуникационных технологий. Часть 1. Концепции и модели управления безопасностью информационных и коммуникационных технологий. BS ISO/IEC 13335-1-2004.
  5. ^ ab Целевая группа по интернет-инжинирингу RFC 4949 Глоссарий по интернет-безопасности, версия 2
  6. ^ «Инструкция CNSS № 4009» (PDF) . 26 апреля 2010 г. Архивировано из оригинала (PDF) 28 июня 2013 г.
  7. ^ "ФИСМАпедия". fismapedia.org .
  8. ^ «Термин: Уязвимость» . fismapedia.org .
  9. ^ NIST SP 800-30 Руководство по управлению рисками для систем информационных технологий
  10. ^ «Глоссарий». europa.eu .
  11. ^ Техническая стандартная таксономия рисков ISBN 1-931624-77-1 Номер документа: C081 Опубликовано The Open Group, январь 2009 г. 
  12. ^ ab «Введение в факторный анализ информационного риска (FAIR)», Risk Management Insight LLC, ноябрь 2006 г. Архивировано 18 ноября 2014 г. в Wayback Machine ;
  13. ^ Мэтт Бишоп и Дэйв Бэйли. Критический анализ таксономии уязвимостей. Технический отчет CSE-96-11, факультет компьютерных наук Калифорнийского университета в Дэвисе, сентябрь 1996 г.
  14. ^ Шу, Кори (1996). Справочник терминов INFOSEC, версия 2.0. Компакт-диск (Университет штата Айдахо и Организация безопасности информационных систем)
  15. ^ Глоссарий НИАТЕК
  16. ^ ISACA THE RISK IT FRAMEWORK (требуется регистрация). Архивировано 5 июля 2010 г. на Wayback Machine.
  17. ^ аб Райт, Джо; Харменинг, Джим (2009). «15». В Вакке, Джон (ред.). Справочник по компьютерной и информационной безопасности . Публикации Моргана Кауфмана. Elsevier Inc. с. 257. ИСБН 978-0-12-374354-1.
  18. ^ abcde Какарека, Альмантас (2009). «23». В Вакке, Джон (ред.). Справочник по компьютерной и информационной безопасности . Публикации Моргана Кауфмана. Elsevier Inc. с. 393. ИСБН 978-0-12-374354-1.
  19. ↑ Крсул, Иван (15 апреля 1997 г.). Технический отчет CSD-TR-97-026 . Лаборатория COAST, факультет компьютерных наук, Университет Пердью. CiteSeerX 10.1.1.26.5435 . 
  20. ↑ Паули, Даррен (16 января 2017 г.). «Просто сдавайтесь: 123456 по-прежнему остается самым популярным паролем в мире». Регистр . Проверено 17 января 2017 г.
  21. ^ «Шесть самых глупых идей в области компьютерной безопасности». ranum.com .
  22. ^ «Консорциум безопасности веб-приложений / Статистика безопасности веб-приложений» . webappsec.org .
  23. ^ Росс Андерсон. Почему криптосистемы терпят неудачу. Технический отчет, Компьютерная лаборатория университета, Кембридж, январь 1994 г.
  24. ^ Нил Шлагер. Когда технология терпит неудачу: значительные технологические катастрофы, аварии и неудачи двадцатого века. Гейл Рисерч Инк., 1994.
  25. ^ Хакерство: Искусство эксплуатации, второе издание
  26. ^ Киунтузис, Э.А.; Коколакис, С.А. (31 мая 1996 г.). Безопасность информационных систем: лицом к информационному обществу 21 века . Лондон: Chapman & Hall , Ltd. ISBN 0-412-78120-4.
  27. ↑ Аб Расмуссен, Джереми (12 февраля 2018 г.). «Лучшие практики кибербезопасности: оставайтесь кибер-умными». Технические решения . Проверено 18 сентября 2020 г.
  28. ^ «Что такое уязвимость? - База знаний - ICTEA». www.ictea.com . Проверено 3 апреля 2021 г.
  29. ^ Бависи, Санджай (2009). «22». В Вакке, Джон (ред.). Справочник по компьютерной и информационной безопасности . Публикации Моргана Кауфмана. Elsevier Inc. с. 375. ИСБН 978-0-12-374354-1.
  30. ^ «Новая эра раскрытия уязвимостей — краткая беседа с Х.Д. Муром». Технический вестник . Архивировано из оригинала 26 августа 2010 г. Проверено 24 августа 2010 г.
  31. ↑ Бетц, Крис (11 января 2015 г.). «Призыв к более скоординированному раскрытию уязвимостей - MSRC - Главная страница сайта - Блоги TechNet». blogs.technet.com . Проверено 12 января 2015 г.
  32. ^ «Wiz запускает открытую базу данных для отслеживания уязвимостей облака» . Поисковая безопасность . Проверено 20 июля 2022 г.
  33. ^ Барт, Брэдли (8 июня 2022 г.). «Централизованная база данных поможет стандартизировать обнаружение ошибок в облаке». www.scmagazine.com . Проверено 20 июля 2022 г.
  34. ^ Виджаян, Джай (28 июня 2022 г.). «Новые каталоги баз данных уязвимостей, проблемы облачной безопасности». Мрачное чтение . Проверено 20 июля 2022 г.
  35. ^ «Категория: Уязвимость» . owasp.org .
  36. ↑ Дэвид Харли (10 марта 2015 г.). «Уязвимости операционной системы, эксплойты и незащищенность» . Проверено 15 января 2019 г.
  37. ^ Большинство ноутбуков уязвимы для атак через периферийные устройства. http://www.sciencedaily.com/releases/2019/02/190225192119.htm Источник: Кембриджский университет]
  38. ^ Использование сетевых принтеров. Институт ИТ-безопасности Рурского университета в Бохуме
  39. ^ [1] Архивировано 21 октября 2007 г., в Wayback Machine.
  40. ^ «Джесси Рудерман »Условия гонки в диалогах безопасности» . Squarefree.com .
  41. ^ "Блог lcamtuf" . lcamtuf.blogspot.com . 16 августа 2010 г.
  42. ^ «Предупреждение об усталости». Freedom-to-tinker.com . 22 октября 2003 г.

Внешние ссылки