Уязвимости — это недостатки компьютерной системы, которые ослабляют общую безопасность системы.
Несмотря на намерения достичь полной корректности, практически все оборудование и программное обеспечение содержат ошибки, из-за которых система ведет себя не так, как ожидалось. Если ошибка может позволить злоумышленнику нарушить конфиденциальность, целостность или доступность системных ресурсов, она называется уязвимостью. Небезопасные методы разработки программного обеспечения , а также факторы проектирования, такие как сложность, могут увеличить бремя уязвимостей. Существуют различные типы, наиболее распространенные в различных компонентах, таких как оборудование, операционные системы и приложения.
Управление уязвимостями — это процесс, который включает в себя идентификацию систем и расстановку приоритетов, которые являются наиболее важными, сканирование на наличие уязвимостей и принятие мер по защите системы. Управление уязвимостями обычно представляет собой комбинацию исправления (устранения уязвимости), смягчения (повышения сложности или снижения опасности эксплойтов) и принятия рисков, устранение которых неэкономично или непрактично. Уязвимости могут быть оценены по риску в соответствии с Common Vulnerability Scoring System или другими системами и добавлены в базы данных уязвимостей. По состоянию на 2023 год в базе данных Common Vulnerabilities and Exposures (CVE) [update]каталогизировано более 20 миллионов уязвимостей .
Уязвимость инициируется, когда она внедряется в оборудование или программное обеспечение. Она становится активной и доступной для эксплуатации, когда работает программное обеспечение или оборудование, содержащее уязвимость. Уязвимость может быть обнаружена поставщиком или третьей стороной. Раскрытие уязвимости (в виде исправления или иным образом) связано с повышенным риском компрометации, поскольку злоумышленники часто действуют быстрее, чем выпускаются исправления. Независимо от того, будет ли когда-либо выпущено исправление для устранения уязвимости, его жизненный цикл в конечном итоге закончится, когда система или ее более старые версии выйдут из эксплуатации.
Несмотря на то, что разработчики стремятся создать продукт, который работает полностью так, как задумано, практически все программное обеспечение и оборудование содержат ошибки. [1] Если ошибка создает угрозу безопасности, она называется уязвимостью. [2] [3] [4] Часто выпускаются исправления программного обеспечения для исправления выявленных уязвимостей, но те, которые остаются неизвестными ( нулевого дня ), а также те, которые не были исправлены, по-прежнему подлежат эксплуатации. [5] Уязвимости различаются по своей способности использоваться злоумышленниками , [2] и фактический риск зависит от характера уязвимости, а также от ценности окружающей системы. [6] Хотя некоторые уязвимости могут использоваться только для атак типа «отказ в обслуживании» , более опасные позволяют злоумышленнику внедрить и запустить собственный код (называемый вредоносным ПО ) без ведома пользователя. [2] Только меньшинство уязвимостей допускает повышение привилегий , что необходимо для более серьезных атак. [7] Без уязвимости эксплойт не может получить доступ. [8] Также существует возможность установки вредоносного ПО напрямую, без использования эксплойта, если злоумышленник использует социальную инженерию или внедряет вредоносное ПО в легитимное программное обеспечение, которое загружается намеренно. [9]
К основным факторам проектирования, которые могут увеличить бремя уязвимостей, относятся:
Некоторые практики разработки программного обеспечения могут влиять на риск внедрения уязвимостей в кодовую базу. Недостаток знаний о безопасной разработке программного обеспечения или чрезмерное давление с целью быстрой поставки функций может привести к появлению уязвимостей, которых можно было бы избежать, в производственном коде, особенно если безопасность не является приоритетом в корпоративной культуре . Это может привести к непреднамеренным уязвимостям. Чем сложнее система, тем легче уязвимости остаются незамеченными. Некоторые уязвимости создаются намеренно, что может быть вызвано любой причиной: от продажи недовольным сотрудником доступа хакерам до сложных схем, спонсируемых государством, по внедрению уязвимостей в программное обеспечение. [14] Неадекватные проверки кода могут привести к пропуску ошибок, но существуют также инструменты статического анализа кода , которые можно использовать в рамках проверок кода и которые могут обнаружить некоторые уязвимости. [15]
DevOps , рабочий процесс разработки, который делает упор на автоматизированное тестирование и развертывание для ускорения развертывания новых функций, часто требует, чтобы многим разработчикам был предоставлен доступ к изменению конфигураций, что может привести к преднамеренному или непреднамеренному включению уязвимостей. [16] Разделение зависимостей, которое часто является частью рабочих процессов DevOps, может уменьшить поверхность атаки , урезая зависимости только до того, что необходимо. [17] Если используется программное обеспечение как услуга , а не собственное оборудование и программное обеспечение организации, организация зависит от поставщика облачных сервисов для предотвращения уязвимостей. [18]
Национальная база данных уязвимостей классифицирует уязвимости по восьми основным причинам, которые могут пересекаться, в том числе: [19]
Преднамеренные ошибки безопасности могут быть внесены во время или после производства и привести к тому, что интегральная схема будет вести себя не так, как ожидалось при определенных обстоятельствах. Тестирование ошибок безопасности в оборудовании довольно сложно из-за ограниченного времени и сложности чипов двадцать первого века, [22] в то время как глобализация проектирования и производства увеличила возможность внесения этих ошибок злоумышленниками. [23]
Хотя уязвимости операционной системы различаются в зависимости от используемой операционной системы , распространенной проблемой являются ошибки повышения привилегий , которые позволяют злоумышленнику получить больше доступа, чем ему должно быть разрешено. Операционные системы с открытым исходным кодом , такие как Linux и Android, имеют свободно доступный исходный код и позволяют любому вносить свой вклад, что может привести к появлению уязвимостей. Однако те же самые уязвимости встречаются и в проприетарных операционных системах, таких как Microsoft Windows и операционные системы Apple . [24] Все авторитетные поставщики операционных систем регулярно предоставляют исправления. [25]
Клиент-серверные приложения загружаются на компьютеры конечных пользователей и обычно обновляются реже, чем веб-приложения. В отличие от веб-приложений, они напрямую взаимодействуют с операционной системой пользователя . Распространенные уязвимости в этих приложениях включают: [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]
Обычно используемая шкала для оценки серьезности уязвимостей — это спецификация Common Vulnerability Scoring System (CVSS) с открытым исходным кодом. CVSS оценивает возможность эксплуатации уязвимости и нарушения конфиденциальности, доступности и целостности данных. Она также учитывает, как уязвимость может быть использована и насколько сложным должен быть эксплойт. Объем доступа, необходимый для эксплуатации, и может ли это произойти без взаимодействия с пользователем, также учитываются в общей оценке. [60] [61]
Тот, кто обнаруживает уязвимость, может раскрыть ее немедленно ( полное раскрытие ) или подождать, пока будет разработан патч ( ответственное раскрытие или скоординированное раскрытие). Первый подход хвалят за его прозрачность, но недостатком является то, что риск атаки, вероятно, увеличится после раскрытия при отсутствии доступного патча. [62] Некоторые поставщики выплачивают вознаграждение за ошибки тем, кто сообщает им об уязвимостях. [63] [64] Не все компании положительно реагируют на раскрытие информации, поскольку это может повлечь за собой юридическую ответственность и операционные издержки. [65] Не существует закона, требующего раскрытия информации об уязвимостях. [66] Если уязвимость обнаружена третьей стороной, которая не раскрывает ее поставщику или общественности, она называется уязвимостью нулевого дня , часто считающейся наиболее опасным типом, поскольку существует меньше средств защиты. [67]
Наиболее часто используемый набор данных об уязвимостях — Common Vulnerabilities and Exposures (CVE), поддерживаемый Mitre Corporation . [68] По состоянию на 2023 год [update]он содержит более 20 миллионов записей. [38] Эта информация передается в другие базы данных, включая Национальную базу данных уязвимостей США , [68] где каждой уязвимости присваивается оценка риска с использованием Common Vulnerability Scoring System (CVSS), схемы Common Platform Enumeration (CPE) и Common Weakness Enumeration . [ необходима ссылка ] CVE и другие базы данных обычно не отслеживают уязвимости в программном обеспечении как услугах . [38] Отправка CVE является добровольной для компаний, которые обнаружили уязвимость. [66]
Поставщик программного обеспечения обычно не несет юридической ответственности за расходы, если уязвимость используется в атаке, что создает стимул для создания более дешевого, но менее безопасного программного обеспечения. [69] Некоторые компании подпадают под действие законов, таких как PCI , HIPAA и Sarbanes-Oxley , которые устанавливают юридические требования к управлению уязвимостями. [70]
Медиа, связанные с Уязвимость (вычисления) на Wikimedia Commons