Инструкция по применению

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

Любые инструменты появляются под потребность, т.е. сначала возникает какая-то проблема, затем появляется решение, затем - инструменты, где придуманное решение уже реализуется. Если решаемая проблема понятна, то достаточно обойтись исключительно инструкцией по применению инструмента. Например, проблематика, адресуемая лопатой - понятна, поэтому исключительно инструкции ( шутка, :) ) - достаточно.

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

Для передачи этой истории про правильное использование инструмента хороши все методы:
- гора печатных документов,
- доступ к вендорской базе знаний, где рассмотрены типовые сценарии,
- сиквел из коротких полумаркетинговых роликов продолжительностью не более 5 минут о том, как с помощью данного инструмента решать какие-то конкретные (лучше те, что на слуху) задачи,
- тренинги и сертификации,
- открытые community форумы\конферении\вебинары (да и любые другие мероприятия как физические, так и виртуальные), где потребители делятся своим опытом использования инструмента.

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

API для гибкой интеграции в коммерческих продуктах

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

(Ассоциация)

На секции Сбербанка SOC-Форума 2017 единодушным пожеланием пользователей производителям систем ИБ было наличие открытых API с целью максимально гибкой адаптации решения под свои нужды. А нужно ли это? Если вы - не технологическая компания, то, скорее, нет.

1. Не надо распыляться. Если вы работаете в производственной компании, в реальном секторе экономики, то ваш ключевой бизнес - не ИТ, тем более, не ИБ, а ИБ для вас - операционные косты, которые всячески стремятся снижать. А раз так, то и менеджеру ИБ в этом случае следует приоритезироваться на наиболее важные задачи. Здесь не до перфекционизма, не до построения стратегии ИБ на 10 лет в течение года, не до многолетних проектов построения супер-эффективной СУИБ, не до "допиливания" коммерческих продуктов до соответствия какому-то ощущению прекрасного, - правильно взять готовое решение и, по-максимуму используя его возможности из коробки, с минимальными затратами на адаптацию насколько возможно быстро начать его использовать.
2. Не надо желать от коммерческого продукта свойств opensource. Если вы хотите бесконечные возможности по доработке - возьмите opensource - зачастую это хороший компромисс между коммерческой коробкой и собственной разработкой. Не надо требовать от коммерческого продукта гибкости opensource - это невозможно, так как чем больше возможностей вендоры вам предоставляют, тем больше их риск получить от вас конфигурацию, которая будет несовместима со стабильностью\надежностью\функциональностью продукта, которые вендоры должны поддерживать. Производители ПО не могут и не должны отвечать за то, что полет вашей фантазии сломает их продукт, поэтому они вынуждены ограничивать вас в возможностях.
3. Коммерческая компания всегда имеет задачу заработать. Незначительно, но все же здесь прослеживается и коммерческая составляющая: вендоры лучше интегрируются со своими продуктами или с продуктами своих партнеров, чтобы мотивировать потребителя приобретать их продукты, и иметь возможность продемонстрировать, что ценность интегрированного комплексного решения превышает ценность суммы составных частей.
4. Чем больше инвестируете в решение, тем меньше шансов сменить вендора. Чем больше вы инвестируете в кастомизацию дефолтного функционала, тем меньше шансов, что вы когда-нибудь уйдете с этого вендора и\или партнера. Действительно, неразумно вложить столько в подготовительные работы, потратив на них N лет, а затем - сменить решение. И вот тут-то из вас все соки деньги и выдавят. Причем, чем глубже вы влезете, тем сложнее будет спрыгнуть, поэтому, вендору\партнеру выгодно подсадить вас на эту иглу с которой вы уже не спрыгнете.
5. Инвестиции в "обвес" увеличивают OpEx, а их надо снижать + куча других "неожиданностей". Не стоит забывать о законе сохранения, о гибкости и сложности, и о том, что глубокая кастомизация может очень близко граничить с заказной разработкой. Вы уверены, что вы этого хотите?

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

Требования к продуктовому стратегу

О комфорте транспорта лучше спросить пассажиров, а не конструкторов, тем более, не технологов

Изучая спрос на рынке труда обнаружил, что требование №1 к позиции, отвечающей за продуктовую стратегию - огромный опыт разработки (звучать может примерно так "N+ years of experience in software engineering"), Причем, это - повсеместная практика (есть ощущение, что компании Job description списывают друг у друга), и именно поэтому хочется на этом остановиться в заметке.

Основной задачей продуктовой стратегии является придумывание продуктов, которые будут востребованы на рынке. Чтобы этим заниматься нужно очень хорошо понимать целевого потребителя, а самой простой способ этого достичь - быть самому опытным потребителем. А раз так, то, например, для стратега корпоративных продуктов безопасности требованием №1 должен быть опыт работы в корпоративной безопасности, а не "software engineering", так как человек, который всегда занимался разработкой софта и никогда им не пользовался не способен определить потребности пользователя. Да и вообще, разработка ПО или даже разработка алгоритмов\моделей\схем\архитектуры ПО едва ли могут относиться к стратегии, где больше оперируют концепциями и не углубляются в детали проектирования и реализации.

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

Mcafee VIrusScan Console password recovery

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

В статье товарища Ремко Вежнена написано, что пароль хранится в ключе UIP ветки реестра HKLM\Software\McAfee\DesktopProtection в виде Unicode-строки закрытой с помощью MD5. Собственно все это правда, не смотря на то, что статья написана 2 года назад.

Не вся правда заключается в том, что декодировать такой MD5 сложно и что проще поправить ключи реестра, чтобы сбросить пароль.

Современный, правильно настроенный McAfee, не позволяет редактировать нужные нам ключи, в этом вторая засада.

Но первая оказалась не такой страшной - подбор unicode-строки на сегодня не представляет сложности.

Итак. начнем. Даже не имея административных прав, читаем ключ UIP ветки HKLM\Software\McAfee\DesktopProtection.

Допустим это значение b081dbe85e1ec3ffc3d4e7d0227400cd (взято из вышеуказанной статьи).

Формируем файл (например, /tmp/mcafee) содержащий строку:

b081dbe85e1ec3ffc3d4e7d0227400cd:

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

Пока мы редактируем файл, качаем утилиту oclHashcat-plus, которая, с помощью хорошей видеокарты, очень весело умеет работать с хешами.

Запускаем подбор пароля строкой:

./cudaHashcat-xxx -m 40 /tmp/mcafee rockyou.txt,

где rockyou.txt - словарь.

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

Разработчик ПО - безопасник

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

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

Из опыта (возможно плохого и неправильного с т.з. высокой науки планирования программных решений) могу сказать, что на момент начала кодирования далеко не все мелочи продуманы и даже некоторые запланированные фрагменты основного алгоритма по ходу реализации могут значительно изменяться. Причин таких изменений "по ходу реализации" может быть великое множество и я бы не хотел их тут подробно разбирать, может быть, когда-нибудь потом. Когда такие изменения некуда эскалировать, я сам и разработчик, и архитектор, и главный идейный генератор, я уже перехожу в разряд "творцов" и программирование для меня из механики (буквально перевод на язык программирования == переводчик) в что-то вроде, не побоюсь этого, творчества (== художник, писатель). Очевидно, что при тврочестве у меня уже нет возможности (да и я сам не рекомендовал бы распыляться!) мне уже некогда обращать внимание на правильность и точность механических действий (приведу не очень удачный пример: когда я увлеченно говорю на неродном для себя языке, я допускаю грамматические ошибки, поскольку я не могу в момент увлеченности жестко контролировать технику механики, собственно, речи: грамматику, произношение и т.п. Пример не очень удачен, ввиду того, что если я имею достаточно большую практику, я буду механически говорить правильно не напрягаясь. Но такая "привычка делать правильно" не может развиться при кодировании). Т.е. когда я творю, я, скорее всего, не думаю о безопасности моего кода, я концентрируюсь на функционале. Как следствие, я не проверяю входные параметры (поскольку такие проверки, при отсутствии стандартных функций сильно напрягают мозг), я не использую "безопасные" варианты функций и много чего еще не делаю, что надо бы, но не хочется отвлекаться, чтобы не потерять мысль.

Решением данной проблемы мне видится появление (а может уже где есть) специального класса "программистов-безопасников", которые потом будут вычитывать исходные коды за "творцами" и исправлять потенциально небезопасные реализации. Этот процесс, как мне кажется, можно достаточно хорошо поставить на поток, поскольку есть масса матерала о том, как надо писать на том или ином языке, и как не надо. Можно все эти "рекомендации" собрать, систематизировать и использовать. Можно даже что-то проверять, наверно, автоматизированными средствами, которые смогут выискивать потенциально небезопасные конструкции.

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

Еще один возможный камень в огород моего предложения - не будет решена проблема архитектурных уязвимостей. Но, кто будет спорить с необходимостью привлечения безопасности на всех этапах SDLC!? Мой (на сей раз уже значительный) опыт участия в проектах в качестве того самого безопасника-эксперта показывает, что не только в разных проектах нужен безопасник разной специализации (думаю, это очевидно, не буду объяснять), но и на разных этапах нужен также профессионал в соответствующей области. А слово "профессионал" в моем, возможно, извращенном представлении, никак не ассоциируется с уточнением "широкого профиля" - нельзя быть профессионалом во всем.

Напомню, что здесь на ваш суд я обозначил потребность в программисте-безопаснике. Традиционно, любые мысли приветствуются.

nmap подумает за нас

Достаточно давно в сканере портов nmap ввели функционал скриптов, которые выполняют высокоуровневые проверки в процессе сканирования портов. Многие не используют данную замечательную возможность, так как считают, что при этом нужно знать названия скриптов.
В случае готовности отступить на шаг назад и не требовать от nmap'а детального анализа, можно выполнять сканирование в режиме "проверить все". При этом оставаясь script-kiddie мы чувствуем себя like hacker.
Если для Вас не важно, как будут чувствовать себя сервисы в аудируемом сегменте сканируйте следующей командой:
nmap -A -PN --script=all --reason
Если же Вам жаль проверяемого и Вы хотите исключить потенциально опасные скрипты:
nmap -A -PN --script=default --reason
или
nmap -A -PN -sC --reason
Есть еще варианты, но стоит ли засорять ими мозг? Разом ударить из всех орудий - что может быть проще и громче?!

Liberty Shredder

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

Организационные процедуры.
1. Руководитель сотрудника, мониторинг которого будет проводиться, либо специалист службы безопасности отдела\филиала\дочернего общества пишут служебную записку на руководителя службы безопасности с просьбой организовать мониторинг работы сотрудника с даты1 до даты2.
2. Запрос рассматривается, в случае утверждения...
3. В службу технической поддержки передается запрос на добавление в группу локальных администраторов компьютера сотрудника учетной записи для выполнения работ по мониторингу.
4. Запускается мониторинг.
5. Мониторинг приостанавливаем, результаты передаем креатору служебной записки для анализа.
Недостатком можно считать участие большого количества людей в процедуре организации мониторинга, но с другой стороны это позволяет минимизировать вероятность самоуправства со стороны сотрудников службы безопасности предприятия.

Но как быть с тем, что у нас нет денег на приобретение программного обеспечения?!
Решим это через использование свободного программного обеспечения. Устанавливаем любимый вариант свободной операционной системы на компьютер. Учитывая особенности задачи, это не обязательно должен быть сервер за несколько тысяч долларов. Хватит исправного компьютера, обреченного на списание.

Обязательным к установке программным обеспечением являются:
1. Пакет, содержащий утилиту smbclient (обычно это одноименный пакет, либо пакет samba);
2. Пакет, содержащий утилиту convert (обычно это пакет imagemagic);
3. Устанавливаем на сервер утилиту winexe. Самый простой вариант, установить статически-скомпилированный бинарный файл. Внимание! Утилита должна лежать в каталоге, входящем в переменную окружение PATH, либо лежать в каталоге, где будут лежать файлы конфигурации. Предпочтительным считаю второй вариант, дабы соблюсти чистоту дистрибутива.
4. Собственно утилиту для выполнения нужной нам работы boxcutter-fs. У нее есть старший брат, boxcutter, который отличается большей функциональностью и информативностью. Есть аналог screenshot-cmd, но он был вторым кандидатом, до которого очередь не дошла. Утилиту так же кладем в каталог с файлами конфигурации.

Сервер готов. Приступаем к настройке, предполагая, что рабочим каталогом является /usr/local/LS. LS расшифровываем как "liberty shredder", hol's der teufel!

1. В рабочем каталоге размещаем скрипт. Имя не важно. Мне нравится run (скрипты "готовящие" солянку из разных утилит).
---------------
#!/usr/bin/bash

BASE=/usr/local/LS
OUTPUT=$BASE/output
INPUT=$BASE/users.ip
PASS=$BASE/passwd
BIN_BASE="$BASE/bin"
BIN="boxcutter-fs.exe" #можно переименовать во что-нибудь вроде svchosts.exe

filename=`date +%d%m%y-%H%M.jpg`

if [ ! -d $OUTPUT ] ; then mkdir $OUTPUT; fi

for i in `cat $INPUT`; do
if [ ! -d $OUTPUT/$i ]; then mkdir $OUTPUT/$i; fi
smbclient -A $PASS //$i/admin$ -c "put $BIN_BASE/$BIN $BIN"
$BIN_BASE/winexe --system --interactive=1 -A $PASS //$i "$BIN c:\windows\temp\ASPNETSetup.log"
smbclient -A $PASS //$i/admin$ -c "get temp\ASPNETSetup.log $BASE/tmp.bmp; del $BIN; del temp\ASPNETSetup.log"
convert -quality 20 $BASE/tmp.bmp $OUTPUT/$i/$filename #-quality 20 помогает снизив качество уменьшить размер файла.
rm $BASE/tmp.bmp
done

2. В каталоге /usr/local/LS создаем подкаталог bin. Копируем в него утилиты boxcutter-fs.exe и winexe.

3. В каталоге /usr/local/LS создаем файлы:

• passwd для аутентификации на наблюдаемом компьютере в формате
  username =
  password =
  domain =
  
• users.ip, содержащий в строках ip-адреса компьютеров, на которых работают пользователи.
  

4. В /etc/crontab вносим запись вида:
*/5 * * * * /usr/local/LS/run, где */5 частота изготовления копий экрана, в данном случае каждые 5 минут. - имя локальной учетной записи, от которой запускается наш скрипт.

Все. Начиная с ближайшей круглой минуты, без остатка делящейся на 5,в каталоге /usr/local/LS/output/ мы можем найти файлы, содержащие копии экранов сотрудников.

PS. Не забывайте постоянно напоминать пользователям, что компания имеет право следить за тем, чем они занимаются в рабочее время. Постоянно и ненавязчиво.

PSS. Экран размером 1280х1024 порождает файлы размером от 28кб до 165 кб, средний размер 97кб

Итог: Задача выполнена. Финансирование не понадобилось, дополнительный сотрудник не понадобился, руководство удовлетворено.

Желаю Вам, чтобы Ваш файл users.ip всегда был пустым.

Бизнес для Бизнеса

Мы часто слышим упоминания о том, что большинство проблем в безопасности тех или иных программных продуктов так или иначе связаны с недочетами, допущенными при разработке. Действительно, многочисленные уязвимости, закрываемые бесконечными заплатками, по сути своей являются в большинстве случаев попросту ошибками программистов. Не стоит забывать и об архитектурных просчетах, которые уже простым патчем не поправить и, как следствие, такого рода ошибки исправляются новыми релизами ПО.

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

Разработчик? - Нет. Предположим гипотетически, что кто-то разработал ПО, которое не нуждается в постоянных обновлениях (исправлении ошибок), выпуске новых релизов (добавление новых возможностей и исправление архитектурных просчетов). Такой разработчик сможет заработать только однажды, продав право пользования своим ПО. Целый пласт доходов, связанных необходимостью поддержки, будет недоступен.
Еще один момент, который стоит учесть - это то, что есть некая зависимость количества программых ошибок от объема кода. В двух словах: чем больше кода, тем больше в нем ошибок. Как мне кажется, без ущерба для смысла, можно сказать и так: чем меньше ошибок, тем меньше кода. Наш разрабочик написал код с примерно нулевым количеством ошибок, значит его код невелик, а, следовательно, не велика и функциональность его кода. Поскольку, как правило, потребитель хочет "таблетку от всех болезней", не функциональный продукт будет плохо продаваться, дешево стоить, - в общем, доход от его продаж будет невелик, что не выгодно разработчику. Итого, как это не прискорбно, разработчик будет писать большой многофункциональный код, с большим количеством багов, которые потом будет исправлять во время всего жизненного цикла своего детища. При этом, безусловно, зарабатывая на этом.

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

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

Я писал применительно к программногому обеспечению, но, в целом, как это не прискорбно, принцип работает практически везде: АвтоВАЗ делает плохие машины и при этом еще зарабатывает на сервисе и запчастях, ресурс которых значительно ниже чем у кого бы то ни было, как, собственно, и самого автомобиля; средняя выслуга современной стиральной машины, из собственного опыта, не более 5 лет, тогда как у меня есть знакомые, которые покупали стиральную машину 15 лет назад (!) и она до сих пор исправно работет - действительно, производителю выгодно, чтобы я покупал его продукт каждые 5 лет, а не раз на всю жизнь.

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

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

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

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

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

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

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

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

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

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

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

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

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

Skype Security Risks

What are the risks of Skype in an enterprise environment? Is it good or bad? To me there is no definite answer. Let's consider different factors and see why:

• Skype uses peer-to-peer (P2P) architecture. Many companies are very cautious about P2P, but is it really a problem in case of Skype? Not quite. It doesn't have information sharing capabilities, which is major contribution to the level of risk. And in most corporate environment it will not work as P2P due to the presence of firewall.
  
• Data confidentiality matters - Skype encrypts all the traffic, and although the encryption scheme is not open (hence no public analysis has been performed), it uses standard encryption algorithms as AES, not proprietary ones.
  
• There is definitely a risk of data leakage. This is always the case with any new data transmission channel. It can be controlled to some degree - for example by using Skype for Business and disabling file transfer feature.
  
• Skype can be used by malware (through its API) as a covert data transmission or control channel. Again, API can be disabled in business version.
  
• There is a risk of overloading Internet link. What can contribute to this - usage of video capabilities and super nodes (if one of your clients becomes a super node). Later is unlikely in an enterprise (firewalled) environment and in any case can be avoided again by using a proper configured business version. Voice traffic uses about 5 KB/sec, which is about 25 simultaneous calls for 1M line.
  
• Usage of Skype is most likely undesirable in regulated environments (like financial institutions), where communication recording (logs, contents) is required.
  
• Not really a risk, but support costs may contribute to the picture.

My opinion is that risks of using Skype are sometimes exaggerated. In fact in many environments usage of Skype can bring more benefits than drawbacks, provided that it is used in a controlled manner. So before  about high risks and banning Skype I would suggest a following analysis process:

• Identify, what are the business objectives of using Skype?
  
• Analyze, which of those objectives can and which can not be achieved using already available corporate tools.
• Analyze and present what are other options to solve those business objectives and do a high-level comparison if feasible.
• Present a list of risks of using Skype, but do it in business terms. I.e. not "Skype is risky because it utilizes P2P architecture", but "Skype increases a risk of data leakage that can not be detected". Also, information about impact on Internet bandwidth and maintenance costs would be useful here.
• Given all this information it would be possible to come to an optimal decision. One more thing that needs to be stressed is that if you are going to implement new technology (Skype or whatever), it should be done in a controlled manner - like disabling functions that are not part of initial business requirements (for Skype think about things file transfer and API) and meeting any other existing corporate IT/IT security policies and standards.
• If business decides to go with Skype, insist on business version and formation of a technical working group to implement proper settings/policy before going live.

One more important point I wanted to raise here is if you go with prohibiting Skype, don't just do it declaratively. Utilize combination of detection and blocking to actually enforce the policy: Possible options would be:

• Detection of Skype software update traffic. Skype uses distinguishable UserAgent header in such requests ("User-Agent: Skype 1.3", for example) and connects to ui.skype.com.
  
• Skype generates TCP probes as part of normal work.
• Skype can be blocked by blocking CONNECT on the proxy server. This is not feasible in most environments, however.
• Skype can be detected by searching for "skype.exe" process running on users' workstations.
• Skype installations can be detected with software inventory tool, like Microsoft SMS.
• In some cases Skype can be detected by analyzing amount of https (CONNECT) Internet traffic.
• Skype generates UDP and TCP packets to port 33033 during login process.

As a conclusion: every environment is different, but issues presented in this article can be used to conduct a risk assessment that is applicable in your case. Use the process outlined above, or Schneier's five-step risk assessment process, or any other method relative to your company. It is important that in many cases Skype can provide a cheap and secure option for VoIP and IM.

Useful links:

• Skype for Business features: http://www.skype.com/business/features/
• Skype for Business security: http://www.skype.com/business/security/
• Skype Network Administrator's Guide: http://skype.com/security/network-admin-guide-version2.2.pdf
• Skype security evaluation: http://www.skype.com/security/files/2005-031%20security%20evaluation.pdf
• Information about Skype: http://www1.cs.columbia.edu/~salman/skype/index.html
• Analysis of Skype protocol: http://www1.cs.columbia.edu/~salman/publications/skype1_4.pdf
• "Skype Trojan" (see page 22): http://www.csnc.ch/static/download/misc/2006_skype_trojaner_v1.1.pdf
• Skype plugins (may pose more threats): https://extras.skype.com/categories/all/good
• "Skype, hidden threat" (in Russian): http://www.xakep.ru/post/38543/default.asp

Browser security

Recently I mentioned here (unfortunately available only in Russian) that number of discovered vulnerabilities does not indicate level of security. It is a rather strange assertion that Windows is more secure than Linux because it has less discovered faults during specified period of time than Linux.
Here are facts that show that situation actually is reverse.

On figure 6 we can see charts for Remote code execution vulnerabilities in IE, Firefox and Opera. Using Microsoft's logic IE should be safer... But unfortunately things are not so simple - see figure 7. If the idea is not obvious - read text between these figures:

... As shown in Figure 7, these input URLs that resulted in a 0.5735% of successful compromises of Internet Explorer 6 SP2 did not cause a single successful attack on Firefox 1.5.0 or Opera 8.0.0...

Понять очевидное: безопасность Microsoft

Посещая различные конференции по ИБ я неоднократно слышал одно и то же утверждение представителей Microsoft о том, что ОС Windows Vista куда более безопаснее, чем Linux, а MS SQL Server 2005 чем любая другая СУБД. В качестве аргумента приводилась статистика по опубликованным уязвимостям соответственно для Windows/Linux и SQL Server 2005/Oracle.

Не смог удержаться, чтобы не пооспаривать подобные утверждения. Вот аргументы:

1. неверно сравнивать ПО с открытым и закрытым кодом. По-моему очевидно: насколько хорошо сделан ремонт в квартире значительно проще понять просто зайдя туда, вместо того, чтобы пытаться догадаться об этом через закрытую дверь;
2. все-таки суждения о безопасности ПО необходимо строить в отношении к количеству инсталляций. Тут приходит на ум хорошая аналогия с криптографией: правильным считается выбирать проверенные временем решения, а не только что придуманные новинки; к тому же это подтверждается, например, в отчетах Symantec: Windows Vista Network Attack Surface Analysis и Security Implications of Windows Vista . Пользователи логично опасаются ставить новинки, что замедляет исследования в области безопасности (неуловимый Джо потому и неуловим, что он никому не нужен).
3. (совсем странное умозаключение) если исходить из того, что количество уязвимостей конечно, то чем больше их обнаружили, тем меньше их осталось. Понятно, что можно возразить, типа, каждый фикс приносит новые проблемы, и что это утверждение работает только в случае, если ПО не развивается (т.е. в нем не появляются новые функции вообще). Но я здесь имею в виду как раз то, что называется "зрелостью" ПО, то, к чему уже более неприменимо понятие "сырое".

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