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

Компания «Информзащита» представила свой новый аналитический отчет по уязвимостям различного класса, выявленным в ходе аудитов ИБ в компаниях разных бизнес-отраслей. Как сообщили CNews в «Информзащите», на этот раз специалисты компании собрали и проанализировали данные по уязвимостям при проведении ASV-сканирований за 2014 г. и первый квартал 2015 г. На основании исследования был составлен топ-10 популярных уязвимостей (см. таблицу ниже), наиболее часто встречающихся при проведении ASV-сканирований в банках (51% от общего числа компаний, в которых были выявлены уязвимости в ходе аудитов ИБ), процессинговых центрах (20%), торгово-сервисных предприятиях (20%), платежных шлюзах (7%) и телеком-компаниях (2%). По данным «Информзащиты», наиболее часто встречающиеся уязвимости были обнаружены в устаревших версиях программного обеспечения Apache, Microsoft IIS и Open SSL, а в протоколах IPSec, SSL и Microsoft RDP было выявлено использование слабого шифрования. По словам специалистов компании, частота выявления уязвимостей в данном программном обеспечении обусловлена популярностью их использования. Нередко при первом прохождении ASV-сканирования выявляется доступный извне протокол TELNET. Уязвимости оценивались по системе Common Vulnerability Scoring System (CVSS v2), предназначенной для их классификации по шкале критичности от 0 до 10, где: 0,0 – 3,9 — низкая степень критичности; 4,0 – 6,9 — средняя степень критичности; 7,0 – 10 — высокая степень критичности. Топ-10 уязвимостей, наиболее часто встречающихся при проведении ASV-сканирований в компаниях№ п.п.Название уязвимостиКритичность уязвимости по шкале CVSS*Как часто встречается у заказчиков1. SSL Server Supports Weak Encryption Vulnerability 9,0032%2.Internet Information Services Could Allow Elevation of Privilege (CVE-2009-1122)7,6032%3.Microsoft Outlook Web Access Redirection Weaknesses (CVE-2005-0420, CVE-2008-1547)7,5029%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,8025%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,8025%6.Weak IPsec Encryption Settings6,4025%7.X.509 Certificate MD5 Signature Collision Vulnerability (CVE-2004-2761) 5,0021%8.Account Brute Force Possible Through IIS NTLM Authentication Scheme (CVE-2002-0419)5,0014%9.DNS Zone Transfer Enabled on Internet Facing Interface5,0014%10.Windows Remote Desktop Protocol Weak Encryption Method Allowed 4,7011% Источник: «Информзащита» «В целом значительная часть уязвимостей (даже с высоким показателем 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 компании. «Нередки случаи, когда при проведении повторного сканирования “вчерашний” отчет со статусом Pass на следующий день приобретает статус Fail. Причина кроется в том, что разработчики сканеров пытаются обновлять свои базы уязвимостей в кратчайшие сроки после появления информации о выходе новой уязвимости. Поэтому, если заказчик действительно заинтересован в защищенности своих публично-доступных ресурсов, не следует подходить к реализации процесса управления уязвимостями формально», — заключили в компании «Информзащита». Ссылка на источник