«Информзащита» представляет новый аналитический отчет по уязвимостям различного класса, выявленным в ходе аудитов ИБ в компаниях разных бизнес-отраслей. На этот раз специалисты компании собрали и проанализировали данные по уязвимостям при проведении ASV-сканирований за 2014-й год и первый квартал 2015 года.
В процентном соотношении выборка распределилась следующим образом:
На основании исследования был составлен ТОП-10 популярных уязвимостей, наиболее часто встречающихся в компаниях из данных отраслей при проведении ASV-сканирований:
| № | Название уязвимости | Критичность уязвимости по шкале CVSS* | Как часто встречаются у заказчиков |
|---|---|---|---|
| 1. | SSL Server Supports Weak Encryption Vulnerability | 9,00 | 32% |
| 2. | Internet Information Services Could Allow Elevation of Privilege (CVE-2009-1122) | 7,60 | 32% |
| 3. | Microsoft Outlook Web Access Redirection Weaknesses (CVE-2005-0420, CVE-2008-1547) | 7,50 | 29% |
| 4. | OpenSSL Multiple Remote Security Vulnerabilities (CVE-2014-0224, CVE-2014-0221, CVE-2014-0195, CVE-2014-0198, CVE-2010-5298, CVE-2014-3470, CVE-2014-0076) | 6,80 | 25% |
| 5. | Apache HTTP Server Prior to 2.4.10 Multiple Vulnerabilities (CVE-2014-0231, CVE-2014-3523, CVE-2014-0117, CVE-2014-0118, CVE-2014-0226) | 6,80 | 25% |
| 6. | Weak IPsec Encryption Settings | 6,40 | 25% |
| 7. | X.509 Certificate MD5 Signature Collision Vulnerability (CVE-2004-2761) | 5,00 | 21% |
| 8. | Account Brute Force Possible Through IIS NTLM Authentication Scheme (CVE-2002-0419) | 5,00 | 14% |
| 9. | DNS Zone Transfer Enabled on Internet Facing Interface | 5,00 | 14% |
| 10. | Windows Remote Desktop Protocol Weak Encryption Method Allowed | 4,70 | 11% |
*Common Vulnerability Scoring System, CVSS v2 – Общая Система Оценки Уязвимостей, предназначенная для классификации уязвимостей по шкале критичности от 0 до 10, где:
- 0,0 – 3,9 — низкая степень критичности;
- 4,0 – 6,9 — средняя степень критичности;
- 7,0 – 10 — высокая степень критичности.
Наиболее часто встречающиеся уязвимости были выявлены в устаревших версиях программного обеспечения Apache, Microsoft IIS и Open SSL, а в протоколах IPSec, SSL и Microsoft RDP было выявлено использование слабого шифрования. Частота выявления уязвимостей в данном программном обеспечении обусловлена популярностью их использования. Нередко при первом прохождении ASV-сканирования выявляется доступный извне протокол TELNET.
В целом, значительная часть уязвимостей (даже с высоким CVSS) может быть очень быстро и «безболезненно» устранена, поэтому в вопросах управления уязвимостями главную роль играет именно знание об их существовании. И тут всплывает ошибка №1, которую совершают многие организации:
Ошибка 1: Сканирования проводятся только по истечении срока предыдущего сканирования
(1 раз в 90 дней).
Проблема в данном случае заключается в том, что низкая периодичность сканирования не позволяет контролировать появление новых уязвимостей на публично-доступных хостах.
В среднем в месяц выявляется около 100 новых уязвимостей, часть из которых вполне может иметь средний и высокий уровни критичности.
Евгений Сачков, старший аудитор отдела безопасности банковских систем компании «Информзащита»: «Даже если вы устранили критичные уязвимости во время прохождения очередного сканирования, это не отменяет факта повышенного риска компрометации публично-доступных хостов на протяжении прошедших трех месяцев».
Решение:
- Проводить плановые сканирования чаще, чем это требуется в рамках соответствия требованиям PCI DSS и ASV (например, ежемесячно).
- Проводить внеплановые сканирования инфраструктуры при публикации информации о новых уязвимостях в новостных рассылках (для этого администраторы и сотрудники службы информационной безопасности должны быть подписаны на соответствующие рассылки, чтобы реагировать максимально оперативно).
Ошибка 2: Несвоевременная установка обновлений операционных систем, сервисов и прикладного программного обеспечения.
Уязвимости со статусом «FAIL», выявленные незадолго до аттестационного ASV-сканирования (или уже в процессе) требуют оперативного устранения, что может потребовать перезагрузки операционной системы и сетевого устройства.
«Стоимость одной минуты простоя процессинга достаточно велика, что приводит к негативным последствиям в виде потери части прибыли, а также к появлению репутационных рисков в виде негативных отзывов, приводящих к естественному оттоку клиентов», – отмечает Никита Перевалов, старший аудитор отдела безопасности банковских систем компании «Информзащита».
Решение:
- Проведение сканирований не только боевых систем, но и тестовых – часть уязвимостей можно просто «не переносить» в продакшн.
- Формирование перечня уязвимостей, которые необходимо устранить в первую очередь.
- Тщательное планирование технологических окон, путем анализа нагрузки ресурсов в разное время.
Никита Перевалов: «В рамках проведения аудитов PCI DSS мы иногда сталкиваемся с такой проблемой, как некорректно оформленный отчет по результатам проведения ASV-сканирований – такой отчет является непригодным для подтверждения выполнения требований 11.2.2 PCI DSS. Требования к формату отчета указаны в приложениях к документу Approved Scanning Vendors Program Guide Version 2.0:
- Appendix A: ASV Scan Report Attestation of Scan Compliance
- Appendix B: ASV Scan Report Executive Summary
В общей части отчета «Approved Scanning Vendor Information» должны быть указаны реквизиты сотрудника компании, предоставляющей услуги по ASV-сканированию. Проверить, имеет ли компания статус ASV можно на официальном сайте PCI SSC: Approved Scanning Vendors.
В разделе ASV Attestation должен быть указан номер сертификата ASV компании. Актуальный номер сертификата ASV-компании всегда доступен на сайте PCI SSC: Approved Scanning Vendors.
Вывод:
Нередки случаи, когда при проведении повторного сканирования «вчерашний» отчет со статусом PASS на следующий день приобретает статус FAIL. Причина кроется в том, что разработчики сканеров пытаются обновлять свои базы уязвимостей в кратчайшие сроки после появления информации о выходе новой уязвимости. Поэтому, если заказчик действительно заинтересован в защищенности своих публично-доступных ресурсов, не следует подходить к реализации процесса управления уязвимостями формально.