AnywhereUSB with PoE

Vendor: Digi International.

Product: AnywhereUSB Ethernet USB hub

Feature Small Description.
AnywhereUSB Ethernet hub allows you to connect USB devises via Ethernet.

Problem description.
Each AnywhereUSB hub has its own power unit.

Enhancement description.
Enable AnywhereUSB hub to support PoE.

Log Collector on Trunk

Vendor: Cisco Systems

Product: Cisco Security Monitoring, Analysis and Response System (MARS)

Feature small description.
Cisco MARS is appliance that is capable to collect logs from different sources, somehow correlate them and respond, even actively (i.e. shutdown port) in case of Cisco equipment. It has two physical interfaces: one for management and another - for log collection. Actually you can collect logs via both interfaces but it's not good idea because you need guaranteed management access that is not possible if both interfaces are overwhelmed by logs.

Problem description.
Log sources are deployed in different VLANs and it's desired to collect logs right from VLAN there they are generated. This is not possible because MARS has only one interface for log collection.

Enhancement description.
Enable MARS to understand 802.1q trunks. This allows us to configure multiple virtual interfaces on one physical, so we can collect logs simultaneously from different VLANs.

Scanner on Trunk

Vendor: IBM ISS.

Product: Proventia Network Enterprise Scanner

Feature small description.
Model ES1500 has five scanning interfaces. This means that it can scan from five network segments simultaneously.

Problem description.
In case you don't want scan one VLAN from another VLAN you can scan only five different VLANs.

Enhancement description.
Enable ES to understand 802.1q trunks. This allows us to configure multiple virtual interfaces on one physical, so we can create as more interfaces as we need and scan each host from its VLAN.

Obstacles.
May be this is marketing. In case with trunk you can make 100 virtual interfaces and scan 100 VLANs simultaneously by one scanner. In current situation to scan 100 VLANs you need 20 different ES1500. But I think this is rather joke then reality.

Hope, this small enhancement will be added soon.

Temporary Group Membership

Vendor: Microsoft Corp.

Product: Active Directory.

Feature small Description.
AD group membership allows you to map privileges to account by adding account into group. You can revoke privileges removing account from group.

Problem description.
During account life cycle many different rights are granted and revoked. In most cases it's possible to specify time period for which account needs specified privileges. In general, I think, all privileges should be granted only for the period of time and then, may be, prolonged if needed. In "Windows World" the most convenient way to grant privileges to account is to map these privileges to AD group and then add user account to that group. Unfortunately AD does not allow you to add account for a time period, i.e. after that period account automatically loose group membership.


Enhancement Description.
AD should have mechanisms for temporary group membership.
Actually, to my mind, this feature is even more important than account expiration date. Account itself is about Authentication and account's groups is about Authorization. As far as I understand Authorization, i.e. resources account can access, is more important, because if account is authenticated (user proved that she is actual account's owner) but not authorized (account is not member of any group, so doesn't have any privileges) resources are still secure.

Logevidence response in RealSecure Network/Gigabit Sensor

Software vendors advertise everywhere that they appreciate customers' requirements and encourage them to write letters describing their needs to include them in future releases. Me as a customer has written a lot of suggestions to vendors of products I use but most of things are still the same. May be I'm not the right person to write such demands for enhancements, may be I use incorrect media to deliver my needs... So, I decided to use this blog to tell audience about desired features and, may be, this somehow enforce the process. Starting with this post (unfortunately available only in Russian and I feel lazy to translate it) I introduced new label Enhancements - all posts of this kind will be written with this label.

Vendor: IBM ISS.

Product: RealSecure Network 10/100 and Gigabit

Feature small description.
Logevidence is one of the possible signature responses in ISS' NIDS. It forces the sensor to dump packet which contains signature to file specified in sensor configuration file.

Problem description.
1. Sensor dumps only one packet per signature.
2. All logevidence packets are dumped to the same file and to find something in it is very difficult.

Enhancement description.
1. We know that ISS produce good stateful NIDSs. This means that to find signature sensor analyzes not just one packet (in this case fragmentation will easily deceive it) but whole data stream (session, which is more than one packet). As far as I understand idea of Logevidense, it is for further manually analysis. In this case one packet is not enough. So, my first part of this enhancement here is to dump the whole session, not just one packet.
2. Dump packets (sessions) not only to one file but to special folders structure. For example, like this:
[Signature Name]/[Source IP]/[Destination IP]/[Date & Time].cap
Of cource ability to configure neded path and file name for logevidence is welcome!

Данные и Конфигурация

Очевидным вещам будет посвящен этот пост, и я бы никогда не написал его, если бы не наболело...

Существует масса систем представляющие собой front-end в виде некого сервера приложения и back-end, в роли которого, как правило, выступает база данных. Практически всегда все записи в базе данных можно подразделить, как минимум, на два класса: Даные и Конфигурации. Под Конфигурациями я здесь понимаю набор данных, записей базы данных, необходимых для функционирования приложения и выполнения им поставленных перед ним задач с заданными параметрами качества, производительности и т.п. Под Данными я понимаю те записи базы данных для обработки и хранения которых, собственно, была разработанна система. Т.е, чтобы совсем все упростить, Конфигурация - нужна Системе, чтобы работать так, как это требует пользователь, Данные - нужны пользователю.

Возьмем, для примера, систему управления сенсорами IDS. Здесь Конфигурацией будут данные, представляющие собой, в частности, политики обнаружения сенсоров, их параметры работы (какой интерфейс используется для мониторинга трафика, какой для управления, какие у них IP-адреса, пр), пользовательские оповещения с системы управления (кому, от кого и через что слать почту, куда слать трапы SNMP), пр. К данным мы отнесем журналы, которые генерят сенсоры и складывают в базу, чтобы потом пользователь в них что-то искал и строил причудливые отчеты. По подобному принципу построена масса систем: системы Web-фильтрации, Антивирусные комплексы предприятия, различные системы контроля доступа к чему-либо, пр.

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

1. Основное. Раздельное хранение Данных и Конфигурации позволит выполнять быстрое резервное копирование и восстановление Конфигурации в случае сбоя. Очевидно, что в системах сбора и анализа логов Конфигураций в тысячи раз меньше чем Данных, и в случае, если потеря Данных значительно менее критичное событие, чем потеря системы (ну например, система используется, главным образом, как средство оперативной готовности, а не как система для долгого архивирования и хранения Данных), куда более разумно выполнять резервное копирование только Конфигурации, что значительно быстрее и занимает меньше места.

2. Развивая далее идею различных требований к Конфигурации и Данным, в случае, если данных очень много и они маловажны, - их можно хранить, например, на RAID0, тогда как Конфигурации - на RAID1. Это позволит обеспечивать требования к Системе и, вместе с тем, экономно использовать дисковое пространство.

3. Раздельное хранение позволит выполнять быстрое удаление Данных, если их количество вышло из-под контроля. Всем известно, что TRUNCATE TABLE работает значительно быстрее чем обычный DELETE, а в совсем тяжелом случае можно и DROP TABLE.

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

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

6. ... и т.д. Есть хорошее правило: разделять данные, требования (не важно какие: конфиденциальность, целостность, доступность или все вместе) к которым различны. К Данным и Конфигурации в большинстве случаев требования сильно различны.

Вообще, во всех книжках по IIS написано, что не надо располагать файлы Web-приложений на системном диске (где стоит Windows), в книжках по СУБД упоминается, что файлы данных также не стоит хранить на системном диске... Проблема одна и та же: разделение Конфигурации от Данных. Но почему практически никто из производителей не хранит Конфигурации и Данные в разных базах данных. Может, на то есть неведомые мне причины?
В случае хранения Конфигурации и Данных в разных базах данных, можно пойти дальше и хранить их и в разных СУБД, что значительно повысит надежность системы, простоту ее восстановления и обслуживания.