Jump to content

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

Уязвимости — это недостатки в компьютерной системе, которые ослабляют общую безопасность системы.

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

Управление уязвимостями — это процесс, который включает в себя идентификацию систем и определение наиболее важных из них, сканирование на наличие уязвимостей и принятие мер по обеспечению безопасности системы. Управление уязвимостями обычно представляет собой комбинацию исправления (устранения уязвимости), смягчения последствий (увеличения сложности или снижения опасности эксплойтов) и принятия рисков, устранение которых экономически или практично. Уязвимости могут быть оценены по уровню риска в соответствии с Общей системой оценки уязвимостей или другими системами и добавлены в базы данных уязвимостей. По состоянию на 2023 год зарегистрировано более 20 миллионов уязвимостей В базе данных Common Vulnerabilities and Exposures (CVE) .

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

Причины [ править ]

Несмотря на цель разработчиков создать продукт, который работает полностью так, как задумано, практически все программное и аппаратное обеспечение содержит ошибки. [1] Если ошибка создает угрозу безопасности, это называется уязвимостью. [2] [3] [4] Исправления программного обеспечения часто выпускаются для исправления выявленных уязвимостей, но те, которые остаются неизвестными ( нулевые дни ), а также те, которые не были исправлены, по-прежнему подлежат эксплуатации. [5] Уязвимости различаются по возможности использования злоумышленниками . [2] Фактический риск зависит от характера уязвимости, а также ценности окружающей системы. [6] Хотя некоторые уязвимости можно использовать только для атак типа «отказ в обслуживании» , более опасные из них позволяют злоумышленнику внедрить и запустить свой собственный код (называемый вредоносным ПО ), без ведома пользователя. [2] Лишь небольшая часть уязвимостей допускает повышение привилегий , что необходимо для более серьезных атак. [7] Без уязвимости эксплойт не сможет получить доступ. [8] Также возможна вредоносного ПО установка напрямую, без эксплойта, если злоумышленник использует социальную инженерию или внедряет вредоносное ПО в законное программное обеспечение, которое загружается намеренно. [9]

Факторы проектирования

Фундаментальные факторы проектирования, которые могут увеличить бремя уязвимостей, включают:

  • Сложность. Большие и сложные системы увеличивают вероятность возникновения ошибок и непредусмотренных точек доступа . [10]
  • Знакомство: использование общего, хорошо известного кода, программного обеспечения, операционных систем и/или аппаратного обеспечения увеличивает вероятность того, что злоумышленник обладает или сможет найти знания и инструменты для использования уязвимости. [11]
  • Возможность подключения: любая система, подключенная к Интернету, может быть доступна и взломана. Отключение систем от Интернета — действительно эффективная мера против атак, но она редко осуществима. [12]
  • Устаревшее программное и аппаратное обеспечение подвергается повышенному риску, но обновление часто является непомерно дорогим с точки зрения затрат и времени простоя . [13]

Факторы развития

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

DevOps , рабочий процесс разработки, в котором особое внимание уделяется автоматическому тестированию и развертыванию для ускорения развертывания новых функций, часто требует, чтобы многим разработчикам был предоставлен доступ к изменению конфигураций, что может привести к преднамеренному или непреднамеренному включению уязвимостей. [16] Разделение зависимостей на части, которое часто является частью рабочих процессов DevOps, может уменьшить поверхность атаки , ограничивая зависимости только тем, что необходимо. [17] Если используется программное обеспечение как услуга , а не собственное оборудование и программное обеспечение организации, организация зависит от поставщика облачных услуг в предотвращении уязвимостей. [18]

Национальной базы Классификация уязвимостей данных

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

  1. проверки ввода (включая переполнение буфера и граничные условия Уязвимости ) возникают, когда проверки ввода недостаточно для предотвращения внедрения злоумышленником вредоносного кода. [20]
  2. Уязвимости контроля доступа позволяют злоумышленнику получить доступ к системе, которая должна быть ограничена для него, или участвовать в повышении привилегий . [20]
  3. Если система не может правильно обработать исключительное или непредвиденное состояние, злоумышленник может воспользоваться ситуацией для получения доступа. [21]
  4. возникает Уязвимость конфигурации , когда параметры конфигурации создают угрозу безопасности системы, что приводит к таким сбоям, как необновленное программное обеспечение или разрешения файловой системы, которые недостаточно ограничивают доступ. [21]
  5. Состояние гонки , когда время или другие внешние факторы изменяют результат и приводят к непоследовательным или непредсказуемым результатам, может вызвать уязвимость. [21]

Уязвимости по компонентам [ править ]

Аппаратное обеспечение [ править ]

Умышленные ошибки безопасности могут возникнуть во время или после производства и привести к тому, что интегральная схема будет вести себя не так, как ожидалось, при определенных конкретных обстоятельствах. Тестирование на наличие ошибок безопасности в аппаратном обеспечении довольно сложно из-за ограниченного времени и сложности чипов двадцать первого века. [22] в то время как глобализация проектирования и производства увеличила вероятность внесения этих ошибок злоумышленниками. [23]

Операционная система [ править ]

Хотя уязвимости операционной системы различаются в зависимости от операционной системы используемой , общей проблемой являются ошибки повышения привилегий , которые позволяют злоумышленнику получить больше доступа, чем ему должно быть разрешено. Операционные системы с открытым исходным кодом, такие как Linux и Android, имеют свободно доступный исходный код и позволяют любому вносить свой вклад, что может привести к появлению уязвимостей. Однако те же уязвимости встречаются и в проприетарных операционных системах, таких как Microsoft Windows и операционные системы Apple . [24] Все авторитетные поставщики операционных систем регулярно выпускают исправления. [25]

Клиент-серверные приложения [ править ]

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

  • Незашифрованные данные, находящиеся в постоянном хранилище или пересылаемые по сети, злоумышленникам относительно легко украсть. [26]
  • Перехват процесса происходит, когда злоумышленник захватывает существующий компьютерный процесс . [26]

Веб-приложения [ править ]

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

Управление [ править ]

Существует мало данных об эффективности и экономической эффективности различных мер по предотвращению кибератак. [31] Хотя оценить риск атаки непросто, среднее время взлома и ожидаемая стоимость могут учитываться для определения приоритета исправления или смягчения выявленной уязвимости и того, является ли это экономически эффективным. [32] Хотя внимание к безопасности может снизить риск атаки, достижение идеальной безопасности для сложной системы невозможно, и многие меры безопасности имеют неприемлемые недостатки в стоимости или удобстве использования. [33] Например, снижение сложности и функциональности системы эффективно снижает поверхность атаки . [34]

Успешное управление уязвимостями обычно включает в себя сочетание исправления (закрытия уязвимости), смягчения последствий (увеличения сложности и уменьшения последствий эксплойтов) и принятия некоторого остаточного риска. Часто стратегия глубокоэшелонированной защиты используется для создания нескольких барьеров на пути атаки. [35] Некоторые организации сканируют только уязвимости с самым высоким риском, поскольку это позволяет расставить приоритеты в контексте нехватки ресурсов для устранения каждой уязвимости. [36] Увеличение расходов, вероятно, будет иметь уменьшающуюся отдачу . [32]

Исправление [ править ]

Исправление устраняет уязвимости, например, путем загрузки исправления программного обеспечения . [37] Сканеры уязвимостей программного обеспечения обычно не способны обнаружить уязвимости нулевого дня, но более эффективны при поиске известных уязвимостей на основе базы данных. Эти системы могут найти некоторые известные уязвимости и порекомендовать их исправления, например установку исправлений. [38] [39] Однако у них есть ограничения, включая ложные срабатывания . [37]

Уязвимости можно использовать только тогда, когда они активны — программное обеспечение, в которое они встроены, активно работает в системе. [40] Прежде чем код, содержащий уязвимость, будет настроен для работы в системе, он считается носителем. [41] Спящие уязвимости могут работать, но в настоящее время не работают. Программное обеспечение, содержащее неактивные уязвимости и уязвимости оператора связи, иногда можно удалить или отключить, что устраняет риск. [42] Активные уязвимости, если их отличать от других типов, могут быть приоритетными для исправления. [40]

Смягчение [ править ]

Смягчение уязвимости — это меры, которые не закрывают уязвимость, но затрудняют ее эксплуатацию или уменьшают последствия атаки. [43] Сокращение поверхности атаки , особенно для частей системы с доступом root (администратора), и закрытие возможностей для использования эксплойтов в использовании привилегий — это распространенная стратегия снижения ущерба, который может нанести кибератака. [37] Если патч для стороннего программного обеспечения недоступен, возможно, его можно временно отключить. [44]

Тестирование [ править ]

Тест на проникновение пытается войти в систему с помощью эксплойта, чтобы проверить, небезопасна ли система. [45] Если тест на проникновение не пройден, это не обязательно означает, что система безопасна. [46] Некоторые тесты на проникновение могут проводиться с использованием автоматизированного программного обеспечения, которое проверяет существующие эксплойты на наличие известных уязвимостей. [47] Другие тесты на проникновение проводятся обученными хакерами. Многие компании предпочитают поручить эту работу подрядчикам, поскольку она имитирует атаку со стороны. [46]

Жизненный цикл уязвимости [ править ]

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

Жизненный цикл уязвимости начинается, когда уязвимости появляются в аппаратном или программном обеспечении. [48] Обнаружение уязвимостей может осуществляться поставщиком программного обеспечения или третьей стороной. В последнем случае считается наиболее этичным немедленно сообщить об уязвимости поставщику, чтобы ее можно было устранить. [49] Правительство или спецслужбы покупают уязвимости, которые не были публично раскрыты, и могут использовать их в атаке, накапливать их или уведомлять поставщика. [50] По состоянию на 2013 год « Пять глаз» (США, Великобритания, Канада, Австралия и Новая Зеландия) захватили большую часть рынка, а среди других крупных покупателей были Россия, Индия, Бразилия, Малайзия, Сингапур, Северная Корея и Иран. [51] Организованные преступные группы также покупают уязвимости, хотя обычно они предпочитают наборы эксплойтов . [52]

Даже общеизвестные или исправленные уязвимости зачастую могут быть использованы в течение длительного периода времени. [53] [54] Разработка исправлений безопасности может занять месяцы. [55] или, возможно, никогда не будет разработан. [54] Патч может оказать негативное влияние на функциональность программного обеспечения. [54] и пользователям может потребоваться протестировать патч, чтобы убедиться в его функциональности и совместимости. [56] Крупные организации могут не суметь выявить и исправить все зависимости, тогда как более мелкие предприятия и частные пользователи могут не устанавливать исправления. [54] Исследования показывают, что риск кибератак увеличивается, если об уязвимости становится публично известно или выпущено исправление. [57] Киберпреступники могут перепроектировать патч, чтобы найти основную уязвимость и разработать эксплойты. [58] часто быстрее, чем пользователи устанавливают патч. [57]

Уязвимости становятся устаревшими, когда программное обеспечение или уязвимые версии перестают использоваться. [49] Это может занять длительный период времени; в частности, промышленное программное обеспечение может оказаться невозможным заменить, даже если производитель прекратит его поддержку. [59]

Оценка, раскрытие информации и инвентаризация [ править ]

Оценка [ править ]

Обычно используемой шкалой для оценки серьезности уязвимостей является общедоступная система оценки уязвимостей (CVSS). CVSS оценивает возможность использования уязвимости и нарушения конфиденциальности, доступности и целостности данных. Также учитывается, как можно использовать уязвимость и насколько сложным должен быть эксплойт. При подсчете общего балла также учитывается объем доступа, необходимый для эксплуатации, и возможность ее осуществления без взаимодействия с пользователем. [60] [61]

Раскрытие информации [ править ]

Тот, кто обнаружил уязвимость, может сообщить о ней немедленно ( полное раскрытие ) или дождаться разработки исправления ( ответственное раскрытие или скоординированное раскрытие). Первый подход хвалят за его прозрачность, но недостатком является то, что риск атаки, вероятно, увеличится после раскрытия информации и отсутствия доступного исправления. [62] Некоторые поставщики платят вознаграждение за обнаружение ошибок тем, кто сообщает им об уязвимостях. [63] [64] Не все компании положительно реагируют на раскрытие информации, поскольку это может повлечь за собой юридическую ответственность и операционные накладные расходы. [65] Закона, требующего раскрытия уязвимостей, не существует. [66] Если уязвимость обнаруживается третьей стороной и не раскрывается поставщику или общественности, она называется уязвимостью нулевого дня и часто считается наиболее опасным типом, поскольку существует меньше средств защиты. [67]

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

Наиболее часто используемый набор данных об уязвимостях — Common Vulnerabilities and Exposures (CVE), поддерживаемый Mitre Corporation . [68] По состоянию на 2023 год , он имеет более 20 миллионов записей. [38] США Эта информация передается в другие базы данных, включая Национальную базу данных уязвимостей . [68] где каждой уязвимости присваивается оценка риска с использованием общей системы оценки уязвимостей (CVSS), схемы общего перечисления платформ (CPE) и общего перечисления уязвимостей . [ нужна ссылка ] CVE и другие базы данных обычно не отслеживают уязвимости в продуктах «программное обеспечение как услуга» . [38] Отправка CVE является добровольной для компаний, обнаруживших уязвимость. [66]

Ответственность [ править ]

Поставщик программного обеспечения обычно не несет юридической ответственности за расходы, если в ходе атаки используется уязвимость, что создает стимул для создания более дешевого, но менее безопасного программного обеспечения. [69] На некоторые компании распространяются законы, такие как PCI , HIPAA и Sarbanes-Oxley , которые устанавливают юридические требования к управлению уязвимостями. [70]

Ссылки [ править ]

  1. ^ Аблон и Богарт 2017 , с. 1.
  2. ^ Jump up to: Перейти обратно: а б с Аблон и Богарт 2017 , с. 2.
  3. ^ Дасвани и Эльбаяди 2021 , с. 25.
  4. ^ Моряк 2020 , стр. 47–48.
  5. ^ Дасвани и Эльбаяди 2021 , стр. 26–27.
  6. ^ Хабер и Хибберт 2018 , стр. 5–6.
  7. ^ Хабер и Хибберт 2018 , с. 6.
  8. ^ Хабер и Хибберт 2018 , с. 10.
  9. ^ Хабер и Хибберт 2018 , стр. 13–14.
  10. ^ Какарека, Альмантас (2009). «23». В Вакке, Джон (ред.). Справочник по компьютерной и информационной безопасности . Публикации Моргана Кауфмана. Elsevier Inc. с. 393. ИСБН  978-0-12-374354-1 .
  11. ^ Крсул, Иван (15 апреля 1997 г.). Технический отчет CSD-TR-97-026 . Лаборатория COAST, факультет компьютерных наук, Университет Пердью. CiteSeerX   10.1.1.26.5435 .
  12. ^ Линьков и Котт 2019 , с. 2.
  13. ^ Хабер и Хибберт 2018 , с. 155.
  14. ^ Страут 2023 , с. 17.
  15. ^ Хабер и Хибберт 2018 , с. 143.
  16. ^ Хабер и Хибберт 2018 , с. 141.
  17. ^ Хабер и Хибберт 2018 , с. 142.
  18. ^ Хабер и Хибберт 2018 , стр. 135–137.
  19. ^ Гарг и Балиян, 2023 , с. 17–18.
  20. ^ Jump up to: Перейти обратно: а б Гарг и Балиян 2023 , с. 17.
  21. ^ Jump up to: Перейти обратно: а б с Гарг и Балиян 2023 , с. 18.
  22. ^ Салмани 2018 , с. 1.
  23. ^ Салмани 2018 , с. 11.
  24. ^ Гарг и Балиян, 2023 , с. 20–25.
  25. ^ Шарп 2024 , с. 271.
  26. ^ Jump up to: Перейти обратно: а б с Страут 2023 , с. 15.
  27. ^ Jump up to: Перейти обратно: а б с д Страут 2023 , с. 13.
  28. ^ Хабер и Хибберт 2018 , с. 129.
  29. ^ Jump up to: Перейти обратно: а б с д и Страут 2023 , с. 14.
  30. ^ Страут 2023 , стр. 14–15.
  31. ^ Аграфиотис и др. 2018 , с. 2.
  32. ^ Jump up to: Перейти обратно: а б Хабер и Хибберт 2018 , стр. 97–98.
  33. ^ Тхоа и др. 2024 , с. 63.
  34. ^ Тхоа и др. 2024 , стр. 68, 70.
  35. ^ Магнуссон 2020 , стр. 34.
  36. ^ Хабер и Хибберт 2018 , стр. 166–167.
  37. ^ Jump up to: Перейти обратно: а б с Хабер и Хибберт 2018 , с. 11.
  38. ^ Jump up to: Перейти обратно: а б с Страут 2023 , с. 8.
  39. ^ Хабер и Хибберт, 2018 , стр. 12–13.
  40. ^ Jump up to: Перейти обратно: а б Хабер и Хибберт 2018 , с. 84.
  41. ^ Хабер и Хибберт 2018 , с. 85.
  42. ^ Хабер и Хибберт 2018 , стр. 84–85.
  43. ^ Магнуссон 2020 , стр. 32.
  44. ^ Магнуссон 2020 , стр. 33.
  45. ^ Хабер и Хибберт 2018 , с. 93.
  46. ^ Jump up to: Перейти обратно: а б Хабер и Хибберт 2018 , с. 96.
  47. ^ Хабер и Хибберт 2018 , с. 94.
  48. ^ Страут 2023 , с. 16.
  49. ^ Jump up to: Перейти обратно: а б Страут 2023 , с. 18.
  50. ^ Либицки, Аблон и Уэбб, 2015 , с. 44.
  51. ^ Перлрот 2021 , с. 145.
  52. ^ Либицки, Аблон и Уэбб, 2015 , стр. 44, 46.
  53. ^ Аблон и Богарт 2017 , с. 8.
  54. ^ Jump up to: Перейти обратно: а б с д Суд и Энбоди, 2014 , с. 42.
  55. ^ Страут 2023 , с. 26.
  56. ^ Либицки, Аблон и Уэбб, 2015 , с. 50.
  57. ^ Jump up to: Перейти обратно: а б Либицкий, Аблон и Уэбб, 2015 , стр. 49–50.
  58. ^ Страут 2023 , с. 28.
  59. ^ Страут 2023 , с. 19.
  60. ^ Страут 2023 , стр. 5–6.
  61. ^ Хабер и Хибберт 2018 , стр. 73–74.
  62. ^ «Спросите специалиста по этике: раскрытие информации об уязвимостях» . Комитет Ассоциации вычислительной техники по профессиональной этике . 17 июля 2018 года . Проверено 3 мая 2024 г.
  63. ^ О'Хэрроу 2013 , с. 18.
  64. ^ Либицки, Аблон и Уэбб, 2015 , с. 45.
  65. ^ Страут 2023 , с. 36.
  66. ^ Jump up to: Перейти обратно: а б Хабер и Хибберт 2018 , с. 110.
  67. ^ Страут 2023 , с. 22.
  68. ^ Jump up to: Перейти обратно: а б Страут 2023 , с. 6.
  69. ^ Слоан и Уорнер 2019 , стр. 104–105.
  70. ^ Хабер и Хибберт 2018 , с. 111.

Источники [ править ]

  • Аблон, Лилиан; Богарт, Энди (2017). Нулевые дни, тысячи ночей: жизнь и времена уязвимостей нулевого дня и их использования (PDF) . Корпорация Рэнд. ISBN  978-0-8330-9761-3 .
  • Аграфиотис, Иоаннис; Медсестра, Джейсон Р.К.; Голдсмит, Майкл; Криз, Сэди; Аптон, Дэвид (2018). «Таксономия кибер-вреда: определение последствий кибератак и понимание того, как они распространяются». Журнал кибербезопасности . 4 (1). дои : 10.1093/cybsec/tyy006 . ISSN   2057-2085 .
  • Дасвани, Нил ; Эльбаяди, Муди (2021). Большие нарушения: уроки кибербезопасности для всех . Апресс. ISBN  978-1-4842-6654-0 .
  • Гарг, Шиви; Балиян, Нияти (2023). Уязвимости мобильных ОС: количественный и качественный анализ . ЦРК Пресс. ISBN  978-1-000-92451-0 .
  • Хабер, Мори Дж.; Хибберт, Брэд (2018). Векторы атак на активы: построение эффективных стратегий управления уязвимостями для защиты организаций . Апресс. ISBN  978-1-4842-3627-7 .
  • Либицкий, Мартин С.; Аблон, Лилиан; Уэбб, Тим (2015). Дилемма защитника: прокладывая курс на кибербезопасность (PDF) . Корпорация Рэнд. ISBN  978-0-8330-8911-3 .
  • Линьков Игорь; Котт, Александр (2019). «Фундаментальные концепции киберустойчивости: введение и обзор». Киберустойчивость систем и сетей . Международное издательство Спрингер. стр. 1–25. ISBN  978-3-319-77492-3 .
  • Магнуссон, Эндрю (2020). Практическое управление уязвимостями: стратегический подход к управлению киберрисками . Нет крахмального пресса. ISBN  978-1-59327-989-9 .
  • О'Харроу, Роберт (2013). Нулевой день: угроза в киберпространстве . Книги по развлечению. ISBN  978-1-938120-76-3 .
  • Перлрот, Николь (2021). «Вот как мне говорят, что наступает конец света»: победитель премии FT и McKinsey «Бизнес-книга года 2021» . Издательство Блумсбери. ISBN  978-1-5266-2983-8 .
  • Салмани, Хасан (2018). Доверенные цифровые схемы: уязвимости аппаратных троянов, предотвращение и обнаружение . Спрингер. ISBN  978-3-319-79081-7 .
  • Моряк, Джим (2020). PCI DSS: Стандартное руководство по интегрированной безопасности данных . Апресс. ISBN  978-1-4842-5808-8 .
  • Шарп, Робин (2024). Введение в кибербезопасность: междисциплинарная задача . Спрингер Природа. ISBN  978-3-031-41463-3 .
  • Слоан, Роберт Х.; Уорнер, Ричард (2019). Почему бы нам не защититься лучше?: Утечки данных, управление рисками и государственная политика . ЦРК Пресс. ISBN  978-1-351-12729-5 .
  • Суд, Адитья; Энбоди, Ричард (2014). Целевые кибератаки: многоэтапные атаки, основанные на эксплойтах и ​​вредоносном ПО . Сингресс. ISBN  978-0-12-800619-1 .
  • Страут, Бенджамин (2023). Справочник исследователя уязвимостей: подробное руководство по обнаружению, составлению отчетов и публикации уязвимостей безопасности . Пакт Паблишинг. ISBN  978-1-80324-356-6 .
  • Тхоа, Саймон; Гафич, Мелиса; Кизеберг, Питер (2024). Основы киберустойчивости . Спрингер Природа. ISBN  978-3-031-52064-8 .

Внешние ссылки [ править ]

Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 1b8354c2ddf27622a20e5dd9840a87c5__1716057780
URL1:https://arc.ask3.ru/arc/aa/1b/c5/1b8354c2ddf27622a20e5dd9840a87c5.html
Заголовок, (Title) документа по адресу, URL1:
Vulnerability (computing) - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)