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

Кроме того, вполне возможно, что эксперты регистрируют инциденты, которые описаны достаточно подробно - с указанием компаний, причины утечек, числа украденных записей и других сопутствующих данных, поля для которых присутствуют в базе. В то же время большинство сообщений об утечках предельно неконкретны. Например, "Роскомнадзор" любит в своих новостях указывать о наложении штрафов за несоблюдение требований закона ФЗ-152 тем или иным сайтом. При этом не всегда понятно была ли при этом утечка или защищаемые данные и так ни кому не нужны.

В самом подходе анализа только медийных утечек есть определенные проблемы. Например, утечка в компании Microsoft привлечёт больше внимание прессы, чем аналогичный по всем остальным параметрам случай в городской поликлинике Нижневартовская. Последняя может вообще не попасть в поле зрения InfoWatch. Таким образом, качество отчёта сильно зависит от выбора источника сведений об утечках, но в отчёте компания вообще не приводит о них ни каких сведений. А интересно было бы узнать мониторит ли компания региональную прессу или сообщения на экзотических языках, типа китайского или санскрита.

Собственно, сами составители отчёта признают, что в их поле зрения попало примерно 1% утечек, при этом они утверждают, что выборка репрезентативна. Конечно социологи поступают примерно также - опрашивают не всех жителей страны, но только определённых её представителей, однако они стараются хотя бы соблюсти социально-демографическое распределение. Что именно является подобным распределением для утечек не совсем понятно, однако очевидно, что анализ только крупных инцидентов в привлекательных для СМИ компаниях описанных на популярных языках общей картины по всему миру не даёт, ибо в небольших компаниях, которых по количеству значительно больше, ситуация может сильно отличаться.

Аналогичная проблема относится и к интерпретации статистики о типах утекаемых данных. В соответствии с отчётом 89,4% утёкших в 2012 году данных - это персональные. Однако на практике это просто требование законов разных стран об обязательном разглашения фактов таких утечек. Поскольку в промышленной и других типах тайн таких требований практически нет, то и публикаций на этот счёт меньше. Поскольку утечка информации отрицательно сказывается на репутации компании, то компании не торопятся раскрывать сведения об утечках. Сведения просачиваются в прессу только в случае судебного преследования нарушителя. Кроме того, компании не всегда знают о произошедшей утечке данных. При плохом уровне защиты в компании, что характерно для небольших фирм, они могут и не заметить утечки.

При этом очевидно, что компания больше ориентирована на американский рынок - замеченных утечек в американских компаних больше половины. Проскольку о источниках сведений ни чего не сказано, то создаётся ощущение, что эксперты InfoWatch просто любят читать американские газеты, в то время как публикации об утечках на санскрите, скорее всего, просто прошли мимо них. Это же относится и к российским утечкам, которых зарегистрировано в 2012 году всего 76. Могу заметить, что сайт Incidets.ru, который ведёт скурпулёзный учёт утечек в России зафиксировал такое число утечек только в первые два с половиной месяца.

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

Таким образом, из отчёта наибольшую ценность представляют данные о каналах утечек. Аналитика данных по путям ухода данных из компаний пусть даже для публичных компаний, которые, возможно, заботятся о предотвращении утечек,является показательным для отрасли в целом. По нему можно сказать, что вендоры просто не могут предложить решение для бумажных документов, защиты резервных копий и также серверов, но для других каналов утечки найдены вполне адекватные технические решения..

Компания Positive Technologies выпустила свой отчёт по анализу уязимостей в системах SCADA. Хотя я и не люблю анализ уязвимостей, по причинам, о которых уже рассказывал, однако тема уязвимостей в АСУ ТП новая и интересная. Она стала популярна после истории с Stuxnet - и это хорошо видно по материалам отчёта. Активность по поиску уязвимостей возросла как раз в 2010 году, когда, собственно, Stuxnet и был обнаружен. Причем компания Siemens, на продукцию которой был нацелен этот вредонос, даже организовала специальное подразделение, которое занимается поиском и устранением уязвимостей. В результате, именно в продукции этой компании было найдено больше уязвимостей, чем во всех остальных. Но означает ли это, что все остальные решения более безопасны?

Команда Positive Technologies проделала всесторонний анализ данных, используя в качестве первоисточников базу вакансий hh.ru для изучения популярности тех или иных компонент АСУ ТП на российском рынке, исходя из предположения, что если ищут специалиста по то или иной системе, то она, скорее всего, у данного клиента установлена. Понятно, что подход не без изъяна, ибо поиск такими образом ведется по наиболее популярным продуктам, специалистов по которым можно найти на открытом рынке. Но с другой стороны, самопальные системы, на обслуживание которых набирают простых программистов, вряд ли выставляют в Интернет, поэтому пока они не сильно повлияют на общие цифры - их оценкой безопасности можно пренебречь.

Второй первоисточник информации о распространении АСУ ТП - Google и другие поисковые системы. С их помощью сотрудники Positive обнаруживали открытые интерфейсы SCADA-приложений, доступных из Интернет. Делалось это, скорее всего, с помощью поиска характерных для встроенных веб-серверов страниц. Понятно, что метод неточен - множество серверов таким способом не нашлось. Собственно, выставлять веб-сервера промышленных контроллеров в Интернет является не очень хорошим тоном - скорее всего это делали компании, которые не задумывались о безопасности, но больше о удобстве обслуживания. Поэтому и результаты такого исследования также несколько хуже, чем в целом по отрасли.

Стоит отметить, что тот же Stuxnet атаковал АСУ ТП не напрямую из Интернет, но с помощью целевой атаки с засылкой вредоносных сообщений и установки троянской программы. Оценить сколько таких потенциальных жертв представленный отчёт не позволяет. Скорее его можно использовать для оценки того, насколько предприятия заботятся о безопасности своих АСУ ТП. К сожалению, про средства защиты для АСУ ТП в отчёте сказано вскользь - только, что они начали появляться. В то же время не совсем понятно почему нельзя для защиты этих систем использовать стандартные межсетевые экраны, системы управления обновлениями и корпоративные антивирусы. В чём состоит особенность этих специальных продуктов - также в отчёте не сказано.

В целом же отчёт достаточно полезен - видна проделанная специалистами Positive работа, есть информация к размышлению. Да и сами выводы достаточно корректны. Особенно понравилось то, что авторы не только проанализировали уязвимости по их критичности, но также оценили их риск с учетом наличия обновлений от производителя и доступности эксплойтов. Также были проанализированы не только уязвимости в наиболее популярных продуктах, но и проведен инструментальный анализ уязвимости найденных с помощью Google по всему миру компонент АСУ ТП с выяснением того, какого типа уязвимости в них присутствуют. Например, было обнаружено, что в 36% случаев ошибки были связаны с неправильным конфигурированием продуктов. Кроме того, результаты исследования были представлены в Siemens, по результатам чего компания исправила несколько своих ошибок. Таким образом, проведённая компанией работа явно сделала АСУ ТП более защищенными.

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

1. Инвентаризация авторизованных и неавторизованных устройств. Программное обеспечение обнаруживает устройства, пдключаемые к корпоративной сети, причем как санкционированно, так и без разрешения. Инструмент относится к категории базовых, без внедрения которого обеспечение безопасности вообще невозможно. Выделяют два типа таких приложений: просто инвентаризация устройств и управление  их защищенностью и контроль доступа к сети (NAP). Из предложенных на плакате подуктов  в России доступны Nmap (Open Source), QualysGuard (Qualys), ISE (Cisco).
   
2. Инвентаризация авторизованного и неавторизованного программного обеспечения. Инструмент необходим для определения установленного программного обеспечения, причём как разрешенного, так и запрещённого. Это также базовый инструмент, без внедрения которого сложно говорить о защите корпоративной среды. Здесь также выделено два уровня реализации: учёт с установкой обновлений и инструменыт для удаления неразрешённого ПО. Институт предлагает следующие продукты этого класса: Tivoli Endpoint Manager (IBM), System Center (Microsoft), QualysGuard Policy Compliance Module (Qualys), SolidCore (McAfee).
   
3. Безопасное управление конфигурациями для мобильных компьютеров, рабочих станций и серверов. Эта категория продуктов относится к классу инструментов системного управления, но только с повышенными требованиями к безопасности этого процесса. Продукты этой категории позволяют централизованно управлять защитой мобильных компьютеров, рабочих станций и серверов. Они обеспечивают изменение конфигураций для улучшения защищённости и выявляют несанкционированные изменения. К этой категории относятся Tivoli Endpoint Manager (IBM), System Center (Microsoft), QualysGuard (Qualys), CSP (Symantec), Configuration Manager (VMware).
   
4. Управление уязвимостями и конфигурациями. Продукты этой категории предназначены для постоянного поиска дефектов безопасности и небезопасных конфигураций. Его наличие необходимо для обеспечения безопасного развития информационной среды предприятия. SANS к таким инструментам поиска уязвимостей предъявляет требование по поиску и устранению дефектов в течении 48 часов. В качестве производителей институт предлагает использовать Vulnarability Managment Services (Dell), Vulnarability & Remediation Manager (McAfee), OpenVAS (Open Source), QualysGuard (Qualys), CCS (Symantec). В России к этому классу можно отнести продукт Max Patrol компании Positive Software.
   
5. Защита от вредоносного ПО. Механизмы этого класса обеспечивают работу в операционной системе только безопасных программ, которые полезны как отдельным сотрудникам, так и предприятию в целом. Выделяется два типа таких инструментов: защита от вредоносных программ и контроль установленных приложений. На плакат попали только продукты, которые позволяют работать с крупными информационными системами. В частности, к ним относятся Admin Kit ("Лаборатория Касперского"), ePolicy Orchestrator (McAfee), Forefront и System Center (Microsoft), Endpoint Protection (Sophos), SEP (Symantec), Control Manager (Trend Micro), SolidCore (McAfee).
   
6. Инструменты для тестирования ПО. Эти инструменты предназначены для определения безопасности того или иного программного обеспечения, которое может быть сделано методом статического или динамического анализа. Обычно эти инструменты используются для сертификации программ, однако в случае использования в компании продуктов заказной разработки, эти инструменты также необходимы для контроля качества представленного разработчиком кода. К этим инструментам относятся следующие продукты: Managed Web App Firewall и Web Application Testing (Dell), Fortify 360 и WebInspect (HP), Ounce Labs Core и Appscan (IBM), QualysGuard WAS (Qualys).
   
7. Контроль беспроводных устройств. Это продукты для контроля корпоративной беспроводной сети - блокирование посторонних устройств в сети и предотвращение попыток вторжения через неё. В России этой темой практически не занимаются, просто выделяя беспроводной сегмент во внешнюю сеть. Поэтому и из доступных продуктов есть только aWIPS и CleanAir компании Cisco.
   
8. Безопасное управление сетевыми устройствами.Это продукты, которые обеспечивают безопасное управление корпоративными маршрутизаторами, коммутаторами и межсетевыми экранами. Они должны не просто управлять конфигурацией устройства, но и контролировать насколько получившаяся конфигурация соответствует корпоративной политике безопасности. Из приведённого на плакате списка в России не присутствует ни один продукт.
   
9. Инструменты для контроля сетевых портов, протоколов и сервисов. Это программное обеспечение занимается проверкой сетевой конфигурации, наличия открытых портов и использования посторонних протоколов взаимодействия. Здесь выделяется два типа продуктов: сканеры, обнаруживающие нарушения в сетевой конфигурации, и экраны уровня приложений, которые блокируют посторонние протоколы и сервисы. Из списка можно привести BSA Visibility и FoundScan (McAfee), QualysGuard (Qualys), CSS (Symantec), 2200 (CheckPoint), ASA (Cisco), SonicWall (Dell), FortiGate (Fortinet), SRX и vGW (Juniper), Polo Alto NGFW (Polo Alto Network).
   
10. Контроль административных привилегий. Администраторы информационных систем часто имеют достаточно широкие полномочия и получают возможность вольно или невольно нарушать правила информационной безопасности. Поэтому в компании должны быть механизмы, которые с одной стороны позволяли бы контролировать действия администраторов, а с другой не давали администраторам возможность нарушить работу средств защиты. Для решения этой проблемы SANS предлагает следующие продукты: eDMZ (Dell), ArcSight ESM и ArcSight Itentify View (HP), System Center и Active Directory (Microsoft), CCS (Symantec).
    
11. Защита периметра. Это шлюзовые устройства, которые обеспечивают защиту от внешних атак через сетевые соединения. Разделяются два класса подобных устройств: межсетвой экран, который обеспечивает проверку статических коммуникаций по портам и протоколам, и система предотвращения вторжений. Собственно, сейчас устройства второго типа называют ещё межсетевыми экранами нового покаления. SANS предлагает пользоваться устройствами 2200 ( Check Point), ASA (Cisco), SonicWall (Dell), ForiGate (Fortinet), SRX и vGW (Juniper), Polo Alto NGFW (Polo Alto), XPS (Fidelis), TippingPoint (HP), Network IPS (IBM), Network Security Platform (McAfee), Snort (Open Source).
    

Этот список содержит только основные элементы защиты. Причем, первые пять относятся к первому уровню внедрения, которые должны быть установлены для обеспечения работы более высокоуровневых средств защиты. В частности, шестая  и седьмая категория относится ко второму уровню, восьмая и девятая к третьему, а остальные - к четвертому. Приведённый список явно неполон - я выбирал только те названия, которые сам знал. Кроме того, в России есть и свои продукты для каждой категории - было бы интересно узнать какие.

Компания Digital Security выпустила отчёт, в котором привела результаты своего исследования мобильных клиентов российских банков. Причём исследовались только бесплатные клиенты, которые работают под управлением операционных систем iOS и Android. Таких клиентов набралось 40, и для них были реализации для обоих операционных систем. Хотелось бы несколько слов сказать о используемой в отчёте терминологии - она, по моему мнению, не соответствует тому, что специалисты компании сделали.

В пояснении сказано, что проводился статистически анализ методом чёрного ящика. Этот термин нужно пояснить, поскольку в практике исследования метод исследования чёрного ящика предусматривает, что на вход изучаемого объекта подаются определённые сигналы, а по полученным реакциям делается вывод о свойствах объекта. Понятно, что такой анализ может быть только динамическим - исследуемый объект должен отреагировать на воздействие. В то же время в практике пентестов исследование методом чёрного ящика означает, что исследователь ни чего заранее не знает о объекте тестирования - все данные получаются в процессе тестирования. Конечно, для специалистов по проведению пентестов такой термин кажется вполне понятным, но для ИТ-специалистов в "статистическом анализе методом чёрного ящика" есть определенные противоречия.

Интереснее другой аспект - методика тестирования, приведенная в отчёте, подразумевает следующее: приложение изучили на предмет наличия в нём небезопасных компонент, и за каждую небезопасную библиотеку назначали штрафные очки. При этом совсем не сказано о том, проводилось ли реальное исследование возможности эксплуатации этой уязвимости. Наиболее показательным примером является наличие в клиенте встроенной базы SQLite. В отчёте явно предполагается, что если эта база используется, то приложение уязвимо для SQL-инъекций, хотя для того, чтобы внедрить свой код злоумышленник должен как минимум перехватить сессию связи и навязать клиентскому приложению свои данные. Понятно, что такая атака блокируется, например, использованием SSL с взаимной аутентификацией или хотя бы контролем целостности передаваемых сервером данных. В отчёте же совершенно нет сведений о том, какой процент из использующих SQLite не использует при этом SSL. В то же время указывается, что по меньшей мере 26 продукта шифруют канал связи.

Те же претензии можно предъявить к уязвимости доступа к файлам - если хранятся локальные данные, то получить к ним доступ может другое приложение. Однако не говорится о том насколько критичные данные хранятся в этих файлах. К тому же данные в них вполне могут шифроваться - исследования на этот счёт также явно не проводилось. Аналогично, и защита SSL - в отчёте явно предполагается, что если этот протокол не используется, то злоумышленник может вмешаться в работу системы, однако вполне возможно, что данные по открытому каналу передаются в шифрованном виде с криптографическим контролем целостности - вмешаться в такой сеанс не намного проще, чем в стандартный SSL. Такая же ситуация с уязвимостью XXE - внедрение посторонних XML-объектов в сеанс. Создаётся ощущение, что любое мобильное приложение, которое использует для обмена с сервером формат XML уже уязвимо, хотя обмен данными, вполне возможно, также был прикрыт SSL или другим механизмом контроля целостности - у злоумышленника просто не было возможности встроить свой XML в сеанс общения сайта с сервером.

Тем не менее, отчёт в целом полезен для отрасли. Хотя он и не выясняет конкретных уязвимостей, но только указывает разработчикам на отклонение от лучших практик: правильное использование SSL, контроль целостности передаваемой информации, использование правильных методов межпроцессорного взаимодействия, проверка на взлом защиты устройства, фильтрация посторонней информации в XML и ответах сервера. Хотя конкретных уязвимостей там не опубликовано, но есть стимул для разработчиков подобных мобильных клиентов позаботиться о использовании лучших практик по защите своего мобильного банкинга до того, как им заинтересуются профессиональные мошенники - тогда это будет делать уже поздно.