В последнее время наши клиенты демонстрируют активный интерес к оборудованию компании Huawei. Наиболее популярные среди них вопросы касаются соответствия оборудования Huawei заявленным производителем характеристикам и его совместимость с оборудованием других производителей, распространенных на российском рынке.

Отвечая на участившиеся запросы, мы запустили ряд программ по тестированию оборудования Huawei в собственной лаборатории, по итогам которых будем публиковать отчеты, экспертные записки и оценки. Первой ласточкой в этом направлении стал отчет о тестировании линейки оборудования (коммутаторов и маршрутизаторов Huawei), позиционируемой Huawei для применения в корпоративных сетях передачи данных, который мы предлагаем вашему вниманию сегодня.

Обобщенный вывод из проведенных тестов:

• функционал протестированного оборудования полностью соответствует заявленному;
• оборудование совместимо с устройствами других производителей.

Подробный же отчет, подготовленный в июле 2014г., с описанием тестов, схемами и результатами приведен ниже. Надеемся, что он поможет всем желающим получить ответы на основную массу вопросов о линейке оборудования компании Huawei, позиционируемой для корпоративных сетей передачи данных, а также сэкономит время на исследование данного вопроса.

В рамках корпоративного блога хотелось бы запустить цикл статей о нашем молодом (но, тем не менее, очень ярком) начинании в сфере информационной безопасности – JSOC (Jet Security Operation Center) − коммерческом центре по мониторингу и реагированию на инциденты. В статьях я постараюсь поменьше заниматься саморекламой и большее внимание уделить практике: нашему опыту и принципами построения услуги. Тем не менее, это мой первый «хабро-опыт», и потому не судите строго.

SOC − предпосылки

Рассказывать, зачем вообще крупной российской компании нужен SOC, не очень хочется (уж слишком много различных статей и исследований по этому поводу написано). А вот статистика – совсем другое дело, и о ней грех не вспомнить. Так, например:

• в компании численностью от 1 до 5 тыс. человек в течение года фиксируется:
  
  • 90 млн. событий ИБ;
  • 16 865 событий с подозрением на инцидент;
  • 109 реальных инцидентов ИБ ;
• общий объем потерь от инцидентов ИБ в 2013 году составил $ 25 млрд. ;
• в крупной компании используется не менее 15 разнородных средств защиты, не более чем в 7 из них проводится активный анализ журналов для выявления инцидентов .

Если же добавить к этому еще 3−4 новостных заголовка по соответствующей теме, то абсолютно логичной и понятной становится идея о том, что за безопасностью необходимо следить, а инциденты ИБ − выявлять и анализировать.

Те, кто уже пробовал выбрать для себя подходящее IdM-решение, знают, что это не такое простое дело, как кажется на первый взгляд. При общем рассмотрении у всех IdM-систем примерно одинаковый набор функций – одни и те же «ролевая модель», «модули интеграции» и «согласование заявок». Однако при более подробном рассмотрении IdM-решений выясняется большое количество деталей, которые, будучи не принятыми во внимание, могут серьезно испортить жизнь будущим пользователям. Например, не все IdM-решения «умеют» группировать (склеивать) заявки по согласующим лицам. И это чревато возникновением таких ситуаций, когда, скажем, для 10 сотрудников запрашиваются 10 ролей, у которых один единственный владелец, и последний при этом вместо одной заявки получает 100 – по одной на каждую запрошенную роль для каждого сотрудника. И его работа, которая, казалось бы, с внедрением IdM должна упроститься, превращается в сущий ад.

Критичным аспектом в контексте информационной защищенности пользовательских данных является конфиденциальность передаваемых данных в процессе взаимодействия защищаемого приложения с веб-сервисами. Например, утрата конфиденциальности в приложениях, манипулирующих номером банковской карты и кодом аутентификации CVV2/CVC2, представляется уязвимостью критичной степени важности. Одной из распространенных ошибок при разработке защищенных приложений для мобильной платформы iOS, приводящих к частичной или полной утрате конфиденциальности передаваемых данных, является чрезмерное кэширование межсетевых запросов.

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

Подобно кэшированию запросов динамической памяти или условных переходов в микропроцессорах, интерфейсы классов, кэширующих HTTP-запросы, являются прозрачными для разработчика и осуществляют кэширование на фоне. Продолжая аналогию с функциональным блоком кэширования в процессоре, можно отметить, что отсутствие представлений о внутреннем устройстве механизма кэширования зачастую приводит к грубым ошибкам программирования. В контексте мобильных приложений, неправильное использование кэша HTTP-запросов приводит к падению производительности приложения и частичной либо полной утрате конфиденциальности. Примером распространенной ошибки, приводящей к падению производительности, является повторное кэширование запросов приложением (Double caching).

Разработчики мобильных приложений зачастую сталкиваются с необходимостью хранить конфиденциальные данные пользователя на пользовательском устройстве. Это могут быть, например, номер кредитной карточки или аутентификационные данные. В этой статье мы поговорим о типичных ошибках реализации хранения конфиденциальных данных с точки зрения информационной безопасности на примере мобильной платформы iOS.
Обычно настройки приложения хранятся в конфигурационных файлах. Библиотека Cocoa Touch, используемая при разработке приложений для мобильной платформы iOS, предоставляет слой абстракции для хранения настроек приложения в классе NSUserDefaults. Класс NSUserDefaults реализует нелюбимый многими шаблон проектирования «Одиночка» (более известный как Singleton), предоставляя доступ к интерфейсу над стандартным конфигурационным файлом приложения.
Стандартный файл конфигурации приложения располагается в его домашней директории по относительному адресу Library/Preferences/<your.company.name>.<app.name>.plist. Как и другие файлы, расположенные в «песочнице», он не доступен на чтение для других приложений пользовательского уровня. Исключения составляют устройства, подвергнутые модификациям политики безопасности системы (jailbroken-устройства).
Многие разработчики по достоинству оценили удобство работы с классом NSUserDefaults. Подавляющее число приложений используют его для хранения внутренних настроек и/или настроек пользователя. К сожалению, удобство использования редко коррелирует с безопасностью. Хранение конфиденциальных данных пользователя в стандартном файле настроек является типичной ошибкой разработчиков, приводящей к утечке пользовательской информации.
В результате исследования исходного кода Приложения А на наличие ошибок в контексте информационной безопасности было выявлено, что приложение сохраняет данные аутентификации пользователя в конфигурационном файле настроек. Загрузив Приложение А на iPad под управление оригинальной операционной системы iOS версии 6.1.3, мы прошли стадию аутентификации и принялись за исследование файла настроек приложения.


Рис. 1. Загрузка приложения на iPad