Big Brother watching you or mobile phone security issues

Lets talk about mobile phone security. You are well qualified security specialist and never install suspicious application on you handset, so, you think you are secure? Have you heard about OMA-DM technology? OMA-DM stands from Open Mobile Alliance Device Management. Within the Open Mobile Alliance Device Management the standard for firmware handset updates is known as the Firmware Update Management Object (FUMO) This standard permits Firmware Over the Air (FOTA) technology. How it works - here you can find short description. But it was only first step of implementing such technology on the market.

The second step is SCOMO - Software Component Management Object standard that permits Software Component Over the Air (SCOTA) technology. This technology was created for more granular and flexible management of each software components. With SCOTA, one or more piece of software could be changed without requiring update whole handset firmware. SCOTA is a best way to create phones' application stores, so, consumers can have access to the latest applications, without needing to replace devices.

The most interesting thing that all these technologies use http/https over IP and xml data format.

Sound cool, does it? But lets turn on our paranoia:

1. These technologies allow vendors, mobile or value added service providers (but not only them) to install or delete any application or data on your mobile phone.

2. This technology uses centralized management model , so, from the one management Center it's possible to legally control a huge botnet of mobile phones.

3. This technology could allow (or it could be already used) government to spy on citizens.

4. These system components could be penetrated by some "bad guys" and used for stealing your data or spying on you.

Talking about OMA-DM overall security conception - I' ve found only OMA Device Management Security Candidate Version 1.2 document. According to it OMA-DM protocol use to level of authentication: on transport layer (recommended to use TLS 1.0, SSL 3.0 ) and on application layer (OMA-DM use MD5 !).

Some useful information for Windows based smartphones you can find on msdn web site:

OMA Device Management Security Best Practice

OMA Device Management

How many phones support these technologies? There are two types of OMA-DM support: OMA-DM ready terminals (soft client already build-in) and terminals that need OMA-DM client to be installed by user to enable OMA-DM support. Some useful but a bit old information you can find here .

Big Brother is watching you! Stay secured!

Увеличения объема доступной виртуалке памяти в esxi3.5 или работа в esxi3.5 на хосте с 1 GB RAM

Куда нынче ИТ-безопаснику без виртуализации? А как быть при наличии старого железа?

Итак у нас есть физический сервер с 1 GB RAM и большое желание поднять на нем среду вируализации для запуска 1 виртуалки. (Вопрос зачем здесь виртуализация деликатно упустим: например для упрощения переноса системы или ее тестирования)

Итак какой гипервизор выбрать? Ответ прост esxi3.5 единственный из гипервизоров который согласиться работать на таком обеме памяти. esxi4 требует минимум 2 GB RAM. Итак установка прошла нормально. Виртуальный аплайнс смигрировал и вот теперь его нужно сконфигурить и запустить.

Только вот незадача ему не удаеться выделить более 256 М памяти! Казалось бы легкая и проворная esxi3.5 откушала более 700 метров. Итак как мы будем это бороть.

По умолчанию гипервизор резервирует 500 метров под управление WMами. Нам же с одной WMкой такого не нуно. Тюним: Идем в Configuration \ System Resource Allocation. Выбираем advanced находим VIM объект и ставим все параметры резервации на 256 метров

Затем переключаемся снова в простой режим из адванседа и правим системные ресурсы целиком, ограничивая их

и после всех этих танцев з бубном получаем столь необходимую нам память в общем размере 512 Мб и отдаем их виртуалке. вуаля

Security Configuration Guides

When auditors visit your company for checking overall information security level they usually shower you with questions about vulnerability and patch management process. And if you haven't one of these processes well established - I'm dead sure you will get serious deficiency in the audit results.

But what about system hardening process ( it could part of configuration management ) - do you have such process established? Do yo have security configuration standards for all yours OS, DB and application well developed and updated? If you will start doing this from a scratch you gonna waste hell of a lot time. To save your time I propose you list of links to the well known library of security configuration guides:

1. USA National Security Agency (NSA) - Security Configuration Guides
2. USA National Institute of Standards and Technology (NIST) - National Checklist Program Repository
3. USA Defense Information System Agency (DISA) - Security Technical Implementation Guides (STIGS)
4. Community: the Center of Internet Security (CIS) - CIS Benchmarks

Sure thing you can find a lot of such guides on vendors websites:

1. Apple Mac OS X Security Configuration Guide
2. Microsoft Security Configuration Guides and Wizards
3. Apache community Security Tips
4. Cisco IOS Security Configuration Guide

So, use it and stay secured!

PS. If you got more links and guides , pls add it in comments.

Using Google Alert for information security

So, we have spent hell of a lot of time and money installing different systems but how we can be sure that everything done good? Once in the morning you can find out that top today news is: your company has been hacked! I think, you must get worst news first. For this purpose you can write own web robot but from my point of view the simplest way is google alert service. How we can use it?

Create a search pattern like " my_company_name hacked OR compromised OR defaced " change option How often to as-it-happens, provide email and vuala - once google find something it gonna inform you.

More over you can use google alert service for checking your company web-resources for occasional leakage of confidential information. For this purpose create pattern like "site:my_company_web_site.com confidential OR secret OR internal use" or special pattern for documents that should not be published "site:my_company_web_site.com confidential filetype:doc OR filetype:cad". So, google will monitor your web sites instead of you and notify you.

Sure thing you can combine both methods for control of private data leakage over the internet, finding negative information about your company, advertisement about selling your protected data, etc.

Keep informed! :-)

Определение нагрузки на SPAN-порт

Глубокий анализ сетевого трафика, как правило, производится без потенциальной возможности влияния на сетевые сервисы. Исключением может быть использование систем предотвращения вторжений в режиме IPS (Intrusion Prevention Systems). В зависимости от поставленных задач, используется анализ полной копии всех пакетов либо информации о каждом установленном сетевом соединении или обмене. Полная копия пакетов, обрабатываемых управляемым коммутатором, направляется на выделенный «зеркалированный», или SPAN (switch port analyzer) порт, к которому подключается анализатор. В зависимости от производителя, версии аппаратной платформы и программного обеспечения коммутатора, возможно выборочное копирование входящих/исходящих пакетов определенных физических либо логических интерфейсов на SPAN-порт. Для эффективного анализа пропускная способность SPAN-порта и, соответственно, сетевого сенсора, должна быть не менее пиковой суммарной нагрузки на анализируемые интерфейсы.
Предположим, есть коммутатор с n интерфейсов, сетевой трафик с m из которых необходимо анализировать. Порты могут быть как физические, так и логические. Независимо от того, будет ли SPAN-сессия терминироваться на данном коммутаторе или на удаленном, соблюдается условие m ≤ n – 1, поскольку интерфейс, передающий копии пакетов на анализатор, не может подавать копию своей нагрузки на себя. В зависимости от поставленных задач и возможностей коммутатора по каждому из m интерфейсов анализируется входящий, исходящий, либо весь трафик. Обозначим за Rx пиковое значение загрузки (бит/с) интерфейса входящими данными, а за Tx – исходящими. Расчет пропускной способности SPAN-порта и, соответственно, сетевого сенсора (Bw), на который подается весь трафик с m интерфейсов, производится по формуле:

(1)




Если же представляют интерес пакеты либо входящие, либо исходящие, в зависимости от порта коммутатора и подключенного к нему оборудования, то для вычисления введем дополнительные параметры: t – количество интерфейсов, с которых будет копироваться исходящий трафик, r – количество портов, у которых будут анализироваться входящие данные. В этом случае соблюдаются условия: r ≤ m, t ≤ m. Требования к соотношению значений r и t определяются либо поставленными задачами для исследования, либо программно-аппаратными ограничениями коммутатора. Таким образом, формула (1) для вычисления пропускной способности Bw приобретает следующий вид:
(2)

Практическое применение результатов данных расчетов в сети предприятия, как правило, сводится к решению вопросов:
- Какой интерфейс выделить на «зеркалированный» порт – FastEthernet, GigabitEthernet или TenGigabitEthernet?
- Какой производительности необходим сетевой сенсор?

Сетевые сенсоры как источник информации

Распределение информации с сенсоров между подразделениями

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

- администраторы серверов;

- администраторы сети;

- администраторы рабочих станций пользователей;

- администраторы IT-безопасности;

- служба безопасности;

- маркетинг.

Сетевой трафик может генерироваться:

- пользователями;

- администраторами;

- серверным и сетевым оборудованием.

Посредством глубокого анализа данных, передаваемых по пакетной сети, возможно разграничить предоставление информации:

- нагрузки на сеть – администраторам сети и серверов, в компаниях-провайдерах связи подобная информация также может пригодиться маркетингу;

- наличия вирусов/троянов/червей – администраторам IT-безопасности, рабочих станций пользователей, серверов;

- неправомерных действий пользователей и администраторов – службе безопасности;

- некорректной конфигурации рабочих станций, серверов, активного сетевого оборудования – администраторам рабочих станций, сети, серверов, IT-безопасности.

Для каждого типа событий возможна настройка отсылки информации в виде трапов SNMP либо syslog (в зависимости от возможностей сенсора) на отдельный сервер мониторинга для полной изоляции доступа к событиям, необходимым для других подразделений.

Мониторинг состояния систем обнаружения вторжений

Многие администраторы систем безопасности не уделяют особого внимания мониторингу не только событий, которые отрабатывают системы обнаружения вторжений, но и состояния самих сенсоров. Применяя системы автоматизированного определения нагрузки и доступности сервисов не только к активному сетевому оборудованию, но и к системам обнаружения вторжений, при анализе загрузки процессоров, объеме и пакетности обрабатываемого трафика можно решить возникающие в ходе развития и эксплуатации сети проблемы:

- рациональности использования ресурсов;

Устройства разной мощности и/или пропускной способности имеют различную стоимость. Учитывая то, что решения корпоративного уровня или операторского класса стоят достаточно дорого, а стабильность работы инфраструктуры критична для обеспечения бизнес-процессов, необходимо четко знать, какие требования должны предъявляться к программно-аппаратным комплексам, устанавливаемым в разных сегментах сети. Очевидно, что установка недостаточно мощного устройства вызовет либо ухудшение параметров работы инфраструктуры, либо, если от устройства не зависит работа сети, то обрабатывать полностью необходимый объем данных оно не будет иметь технической возможности. Использование чрезмерно мощного устройства на менее загруженных сегментах инфраструктуры, где не планируется серьезное развитие в обозримом будущем, окажется напрасной тратой денежных средств.

- соответствия официально заявленных производителем параметров реальным данным;

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

- возможности распределения сенсоров различной мощности по разным участкам сети;

Как обсуждалось выше, параметры сетевых сенсоров могут не соответствовать требованиям данного сегмента сети. Если это не было учтено на этапе проектирования, возможно выявление несоответствий в ходе эксплуатации благодаря анализу загрузки сенсоров.

- необходимости снятия части нагрузки с детектора путем исключения из SPAN-сессии некоторых интерфейсов либо VLAN в случае высокой загрузки;

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

- возможности наращивания инспектируемого трафика в случае низкой нагрузки;

Подобная проблема может возникнуть как при запланированном росте инфраструктурного сегмента, так и при постепенном наращивании трафика, который подается на сетевой сенсор, добавляя мониторинг выбранных портов или VLAN.

- целесообразности подключения дополнительного детектора в коммутатор – в случае перегрузок;

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

- возможности агрегации SPAN-сессий из разных коммутаторов для инспектирования на одном сенсоре любого производителя – при наличии такой необходимости;

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

- дополнительная информация об изменениях сетевой активности;

На основании информации об изменениях сетевого трафика можно контролировать появление аномалий либо использование несогласованных сетевых приложений

- узнать о проведенных несогласованных работах по реорганизации сети либо о произошедшей аварии;

Зная нормальный уровень нагрузки каждого сетевого сегмента и сенсора в зависимости от времени, возможно определение проведенных работ по переносу нагрузки, реконфигурации активного сетевого оборудования. Также резкое изменение объема обрабатываемого трафика может свидетельствовать об аварии, отказе одного из элементов, перестроении таблиц маршрутизации, дерева коммутации и т. п.

- определить степень влияния работ на сервис для пользователей;

Резкое падение либо возрастание нагрузки, не характерное для данного временного интервала на определенном участке сети, может частично помочь в определении влияния проводимых работ либо произошедшей аварии на сервис для конечных пользователей.

- воздействие внешних факторов (температура, отключение штатного электропитания);

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

- программный/аппаратный сбой в работе сенсоров.

В данном случае по отсутствию возможности управления определяется сбой в работе устройств.