08.06.2015

«Информзащита»: 10 популярных уязвимостей при ASV-сканированиях

«Информзащита» представляет новый аналитический отчет по уязвимостям различного класса, выявленным в ходе аудитов ИБ в компаниях разных бизнес-отраслей. На этот раз специалисты компании собрали и проанализировали данные по уязвимостям при проведении ASV-сканирований за 2014-й год и первый квартал 2015 года.

В процентном соотношении выборка распределилась следующим образом: 

 

asv

На основании исследования был составлен ТОП-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 новых уязвимостей, часть из которых вполне может иметь средний и высокий уровни критичности.

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

Решение: 

  1. Проводить плановые сканирования чаще, чем это требуется в рамках соответствия требованиям PCI DSS и ASV (например, ежемесячно).
  2. Проводить внеплановые сканирования инфраструктуры при публикации информации о новых уязвимостях в новостных рассылках (для этого администраторы и сотрудники службы информационной безопасности должны быть подписаны на соответствующие рассылки, чтобы реагировать максимально оперативно).

 

Ошибка 2: Несвоевременная установка обновлений операционных систем, сервисов и прикладного программного обеспечения.

Уязвимости со статусом «FAIL», выявленные незадолго до аттестационного ASV-сканирования (или уже в процессе) требуют оперативного устранения, что может потребовать перезагрузки операционной системы и сетевого устройства.

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

Решение: 

  1. Проведение сканирований не только боевых систем, но и тестовых – часть уязвимостей можно просто «не переносить» в продакшн.
  2. Формирование перечня уязвимостей, которые необходимо устранить в первую очередь.
  3. Тщательное планирование технологических окон, путем анализа нагрузки ресурсов в разное время.

Никита Перевалов: «В рамках проведения аудитов 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. Причина кроется в том, что разработчики сканеров пытаются обновлять свои базы уязвимостей в кратчайшие сроки после появления информации о выходе новой уязвимости. Поэтому, если заказчик действительно заинтересован в защищенности своих публично-доступных ресурсов, не следует подходить к реализации процесса управления уязвимостями формально.