Thursday, December 18, 2008

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

  1. Если абстрагироваться от нарушения и посмотреть на все это глазами сотрудника\компании? Человек пытается сделать свою работу, он перегружен, в условиях "типо-кризиса" он пытается сделать все от него зависящее, чтобы сохранить рабочее место.
  2. Ведет ли это к появлению новых рисков? Да. Но так ли велики эти риски? Должен ли бизнес жертвовать производительностью работы работников, ради того, чтобы конфиденциальные документы оставались внутри охраняемого периметра, который и является основной целью при планировании кражи информации.
  3. Может быть правильнее создать свод правил и предоставить сотрудникам, нуждающимся в возможности работы на дому технические средства, которые бы позволили ему работать дома без создания новых рисков для компании?
  4. Почему мы закрываем глаза на топов и лиц близких к ним, которые незаменимы на ограниченном промежутке времени и так или иначе работают на личных\общественных компьютерах находясь на больничном или в отпуске?
  5. Решает ли возможность удалённого доступа к сети компании все проблемы? Ведь наличие удалённого доступа значительно больший риск, чем обработка конкретного документа на конкретном компьютере в конкретном промежутке времени.
  6. Если мы позволяем сотруднику обработать документ\документы дома, как сделать процедуру разрешения такой работы быстрой и простой, чтобы заявка на это дело не ходила неделями между службами, в которых сотрудники жуя карандаши принимают рандомное решение?
Как Вы боретесь с этим? Что используете? Какие регламенты, программные продукты и тп.

Tuesday, December 16, 2008

ИТ, ИБ и Бизнес. Кто с кем?

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

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

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

Monday, December 15, 2008

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.

Friday, December 12, 2008

Кредит доверия пентестеру

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

1. Насколько они компетентны? Первый вопрос, на который хочется иметь ответ при выборе подрядчика. В крупной компании, как правило, в тендере побеждает тот, кто предложил минимальную стоимость при заданном качестве, а "заданное качество" в данном вопросе описать очень сложно. Одно дело просто пройтись сканером безопасности и распечатать его отчет в итоговый документ, другое дело, используя имеющийся опыт и собственные средства провести глубокий анализ каждой возможной зацепки, что, бесспорно, не выполнить автоматизированными средствами, доступными любому script kiddie. Соответственно, ценовое преимущество здесь на стороне Детей.
Что же можно с этим поделать? На мой взгляд хорошим отличительным признаком Профессионалов является наличие собственной исследовательской лаборатории доказательства существования которой должны масштабно присутствовать в Интернет в виде подтверждений производителей ПО о существовании уязвимостей, обнаруженных нашими Профессионалами (Security advisory). Причем, чем больше уязвимостей обнаружили наши Профессионалы в "свободное от работы время" тем выше их уровень как в методологии, так и на практике, тем больше у них опыта, и, самое главное, они в курсе всех современных тенденций в безопасности.

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

3. Показали ли они все? Вопрос еще более сложный чем предыдущий. Понимаю, что он имеет этическую составляющую. Но, к сожалению, в мире бизнеса все меньше места этике. Возможен следующий сценарий, назовем его мелкое мошенничество. Нормальной практикой является проведения двух аудитов: первый обнаруживает уязвимости, второй - подтверждает, что обнаруженные уязвимости были успешно закрыты. Есть риск, что беспринципный пентестер может умолчать о ряде уязвимостей, обнаруженных в первый аудит, чтобы показать свою "высокую эффективность" во втором. Ситуация еще более удобная, если второй пентест проводится не по мотивам предыдущего (т.е. проверяются только обнаруженные ранее проблемы, а новые не ищутся), а вновь полноценный аудит, аналогичный первому.
Немелкое мошенничество
в нашем случае - когда целью умалчивания уязвимостей является, скажем, их последующее корыстное использование. Ужасно! Это звучит несколько жестоко, но тут дело даже не в компании-консультанте вцелом, речь идет о людях. Ребята-хакеры - это прежде всего люди и даже при условии работы моего излюбленного принципа, что нет плохих людей, а есть обстоятельства, заставляющие людей поступать нехорошо, одному Богу известно в какой жизненной ситуации суждено им побывать, и никакие NDA здесь не спасут.
Противостоять этому можно множеством способов, но не один не дает гарантии. Прежде всего, надо мотивировать аудитора "выкладывать все". Очевидно, что лучшая мотивация - это $, поэтому здесь поможет какая-либо привязка вознаграждения за аудит к количеству обнаруженных проблем. Причем, чтобы не работало мелкое мошенничество, вознаграждение за первый аудит должно быть немного больше.
Веской контрмерой может быть имидж консультанта, например, я бы никогда не доверился вот этим парням. Ну и, российская специфика, - личные взаимоотношения
, безусловно, влияющие на внутреннее мнение заказчика о предполагаемом консультанте.

4. Закрыли ли мы все?
Вопрос очень тонкий, так как закрывать уязвимости можно по-разному. Как минимум, можно закрывать конкретную дырку, а можно закрывать сразу целый класс однотипных уязвимостей. Можно поступить еще более эффективно - сделать уязвимость невозможной. Чтобы было понятно, приведу пример: обнаружена уязвимость - на всех серверах UNIX пароль root простой и одинаковый, как следствие был подобран и серверы были компрометированы. Здесь закрытие конкретной уязвимости - смена пароля на более сложный на всех серверах UNIX, закрытие класса уязвимостей "простые пароли" - переход на централизованную систему аутентификации с заданной политикой сложности паролей, сделать уязвимость невозможной - запретить сетевой вход пользователем root (и прочими критичными учетными записями) вообще или по пролю (оставив, например, возможность аутентификации по ключу SSH).
Более того, чтобы проверять качество закрытия уязвимостей, как правило, нужна квалификация не ниже квалификации пентестера, откуда следует необходимость повторного освидетельствования, обладающая всеми перечсленными рисками. Замкнутый круг.

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

Thursday, December 11, 2008

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!

Tuesday, December 9, 2008

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

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

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

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

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

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

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

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

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

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

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

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


Monday, December 1, 2008

Обманчивый Virustotal.com

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

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

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

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

В подтверждение выдвинутой здесь гипотезы приведу два отчета с virustotal относящиеся к одному и тому же файлу. Файл был отловлен в сети системами обнаружения вторжения как содержащий эксплоит (
PDF_JavaScript_Exploit) для ридера Adobe Acrobat.
"Счет" на первом отчете - 22.23%, на втором - 37.84%.
Разница между отчетами - приблизительно 20 дней.
Приношу извинения за качество картинок (я не планировал писать этот пост когда их делал)
Первый отчет:


Второй отчет:


Wednesday, November 26, 2008

Да поможет нам PA-DSS!

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

Многим известно о существовании стандарта PCI DSS. О нем много пишут, производители различного оборудования и ПО проводят семинары о том, как их оборудование помогает соответствовать этому стандарту и т.п. От себя хочу заметить, что лично мое отношение к данному стандарту более чем положительное, поскольку я люблю конкретность. В данном стандарте весьма четко прописано, вплоть до указания конкретных технологий, что надо сделать, чтобы ему соответствовать, что делает его сильно отличимым от прочих, например ISO. Подобная конкретность может быть использована в случае, когда перед специалистом по ИБ стоит задача "сделать безопасность" в чистом поле, и, понятное дело, разумный вопрос: "Что делать-то?". Ну да, сначала надо определить бизнес-процессы, оценить риски, определить контрмеры, написать политику по ИБ.... в общем, это бумагомарательство займет продолжительное время, прежде чем приведет к тому же, что предписано сделать в PCI DSS. В общем, мое мнение заключается в том, что можно сразу взять PCI DSS и начать "делать безопасность" как там требуют, а обращивать эти системы соответствующими документальными обоснованиями можно по ходу дела.

Но тема наша - PA-DSS, и я не ошибся, написав "PA" вместо "PCI". Как мне кажется он незаслуженно пребывает в тени своего собрата с префиксом "PCI" и тоже может быть использован специалистом по ИБ в своей работе.

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

Чтобы не быть голословным, приведу ряд требований, которые мне показались наиболее интересными (т.е. если бы я писал требования из головы или из имеющихся у меня на сейчас справочников, я бы вряд ли догадался их указать, а они важны), в [квадратных скобках] я буду указывать соответствующий раздел PA-DSS.
1. В рамках требований - только приложение, не ОС, не СУБД [Scope of PA-DSS]. Это важно, поскольку в конкретном проекте нельзя решить проблемы безопасности ОС или СУБД, поскольку это - "коробочные" продукты, но можно решить проблемы приложения и это надо указать.
2. Разработчик вместе с приложением разрабатывает документ "Implementation Guide", который показывает, как надо настроить и использовать его ПО, чтобы выполнялись требования ИБ [Roles and Responsibilities. Software vendors].
3. Даны условия, когда не стоит натягивать требования ИБ на аппаратные терминалы [PA-DSS Applicability to Hardware Terminals].
4. Указано важное обстоятельство, что недостаточно, чтобы только приложение удовлетворяло требованиям ИБ, но важно чтобы еще и окружение соответствовало этим требованиям [
Roles and Responsibilities. Customers].
5. Дано необходимое содержание запроса на подтверждение соответствия (Report on Validation, RV) [Instructions and Content for Report on Validation]. Многие из вопросов освещенных в RV нужно требовать в документах на систему: сетевая диаграмма, требования к ОС и СУБД, схема потоков данных (dataflow), пр.
6. Использование шифрования информации не отменяет использование логических механизмов контроля доступа [PA-DSS Requirements and Security Assessment Procedures, 2.4].
7. Журналлированию подлежат все доступы к данным [
PA-DSS Requirements and Security Assessment Procedures, 4].
8. Актуальные данные продуктивных систем не используются в системах тестирования и разработки [
PA-DSS Requirements and Security Assessment Procedures, 5.1.4].
9. Все Web-приложения должны разрабатываться с использованием руководств по безопасному программированию Open Web Application Security Project Guide [
PA-DSS Requirements and Security Assessment Procedures, 5.2]
10. Приложение должно быть совместимо с используемыми в Компании системами безопасности [
PA-DSS Requirements and Security Assessment Procedures, 8.1]
11. Сервер БД должен быть разделен с Web-сервером, причем сервер баз данных не должен располагаться в ДМЗ [
PA-DSS Requirements and Security Assessment Procedures, 9.1]
12. Приложение должно быть совместимо с системами многофакторной аутентификации [
PA-DSS Requirements and Security Assessment Procedures, 11.1]

Надеюсь, уважаемые читатели, стандарт PA-DSS покажется вам тоже полезным.


Friday, November 21, 2008

Продать Безопасность

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

Т имеет в своем составе подразделения ИБ, которые должны отвечать за "свою часть", причем "своя часть" тоже формально детерминирована как набор сервисов ИБ, определены метрики по этим сервисам.

Х представляет собой набор отдельных предприятий. Предприятия разбросаны по разным частям мира - регионам. Каждое предприятие контрактуется с Т отдельно на определенный перечень ИТ-услуг.

Корпоративная безопасность представлена либо в виде представителя на предприятии, либо представителем в регионе. В его обязанности, помимо всего прочего, входит обеспечение соблюдения корпоративных стандартов уровня холдинга, в том числе и в области ИБ.

Найти.
Необходимо найти эффективный способ продажи услуг безопасности.

Проблема.
Сложность заключается в том, что продать услуги ИБ предприятию в "чистом виде" (с использованием прямых договоров на обеспечение ИБ между Т и Х, как это делается в случае сервисов ИТ) достаточно проблематично по ряду причин:

1. Сложно объяснить руководству предприятия необходимость обеспечения "заданного уровня" ИБ. ИБ - это затраты, как и ИТ. Логично желание любого предприятия сократить непрофильные затраты. Но с ИТ еще более или менее понятно: надо чтобы компьютер работал, rbc.ru открывался, телефон дозванивался... А вот необходимость ИБ надо объяснять, рассказывая о том, как ИБ предотвращает утечки данных и т.п. Согласитесь, такой ликбез - не функция подрядчика Т, но, вместе с тем, логично, что это - функция регионального представителя.

1'. "Заданный уровень ИБ" приходит из корпоративного центра Х, но объяснить это из подрядной организации практически невозможно. Тут аналогия такая, - например, вы приходите к парикмахеру и заказываете стрижку в Н рублей, а парикмахер вам отвечает, что вам, уважаемый, нужна стрижка за К рублей (К > Н) и прибавляет: "Мне ваше начальство сказало". Разумно возмущение с вашей стороны, мол, почему ваше руководство не сказало это вам, но сказало парикмахеру?!

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

3. Безопасность сама по себе не имеет смысла. Это - сугубо прикладная деятельность. Т.е. она всегда предполагает, что есть некий бизнес-процесс, безопасность которого обеспечивается. Бизнес-процсс можно рассматривать как некий множитель безопасности. Если множитель - 0, то и эффект от безопасности - тоже нулевой. Безопасность ради безопасности - пустая трата денег.

Решение.
Учитывая все вышесказанное, разумным представляется продажа услуг/компонент ИБ внутри услуг ИТ. Это, на мой взгляд, абсолютно логично, так как каждый процесс ИТ имеет составляющую ИБ, и не надо пытаться ее вырезать и продавать отдельно. В итоге Т будет продавать услуги ИТ, обеспечивая "заданный уровень ИБ", спущенный из корпоративного центра Х.

Thursday, November 20, 2008

На "Информационная безопасность и бизнес-стратегия фирмы"

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

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

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

1. "Без эффективного менеджмента и понимания бизнес-стратегии компании на подразделения ИБ будут смотреть как на подразделения, не приносящие доход. Управление ИБ на среднем уровне позволяет окупать расходы, а при хорошем менеджменте -приносить доход и делать бизнес еще эффективнее."
Классная красивая фраза, но, беря во внимание реалии жизни, я с трудом понимаю, как подразделение ИБ может приносить доход для компании, где ИБ - непрофильное подразделение. Бесспорно ИБ может повышать эффективность, снижать расходы, но вряд ли приносить доход. ИБ - это сервис бизнеса, который стоит денег. Можно говорить о ROI и TCO, но это TCO не может быть отрицательным числом. Ну а с тем, что менеджмент должен быть эффективным я, конечно, согласен.

2. "В свою очередь представитель отдела информационной безопасности должен быть включен в работу над "не ИТ-проек-тами". Это поможет ответить на вопросы: "Как организовать обмен информацией между клиентом и компанией?", "Как предотвратить утечку информации о клиенте?", "Как сделать так, чтобы о новой рекламной акции никто не узнал раньше времени?" и т.п."

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

Далее к статье идет комментарий Николая Ионова, эксперта Группы компаний "Антивирусный центр", который меня еще больше не порадовал.
1.
"Информационная безопасность имеет развитую техническую компоненту, и именно поэтому многие не видят ее второй составляющей: организации управления. Соответственно вопросы защиты корпоративных данных зачастую пытаются переложить исключительно на плечи ИТ-службы."
Тут надо немного разобраться - вопрос уходит корнями в долгие бесконечные дебаты относительно того где разделяются полномочия ИТ и ИБ. Лично я для себя определился, что рутинные работы по обеспечению ИБ, связанные с поддержанием заданного уровня безопасности, обслуживанием систем безопасности - функция ИТ, тогда как планирование и развитие этих систем - задача ИБ. Попробую объяснить все одной фразой. Если безопасность - это процесс, то поддержание должного заданного качества этого процесса - функция ИТ, а управление этим процессом и его контроль - функция ИБ. В этой связи я считаю абсолютно нормальным, что ИТ обеспечивает защиту корпоративных данных. Можно рассматривать ИБ, как компоненту каждого процесса ИТ. Выделить эту компоненту сложно и, скорее всего, неправильно. Замечу также, что производители ИТ-систем в последнее время все плотнее интегрируют в свои системы и решения по ИБ. Если администраторы ИТ и ИБ - разные люди, кто обслуживает, например, межсетевой экран, который с т.з. ИТ - маршрутизатор, а с т.з. ИБ - пакетный фильтр?
2. "Поэтому ни в коем случае нельзя смешивать функции ИТ-отдела и отдела безопасности, более того, эти отделы не должны находиться в дружественных отношениях. У них изначально должны быть разные задачи и разные подходы к организации информационной безопасности."
Вообще бред. Я вспомнил басню Крылова: "Однажды Лебедь, Рак да Щука...". А как же общие задача по соответствию общей стратегии бизнеса? У меня нет слов, чтобы это прокомментировать, скажу лишь несколько фраз:
а) нельзя защититься от админа;
б) сервисы ИБ по-любому базируются на базовых сервисах ИТ, таких как сетевая инфраструктура, служба каталога, пр.

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

Thursday, November 13, 2008

Частичная компрометация WPA - новая эра беспроводной безопасности

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


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


Самой разумной контрмерой, как мне кажется является отказ от использования WPA (TKIP) и планировать переход на WPA2 (AES-CCMP).


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

  • сократить время жизни ключа TKIP; в документе говорится о 120 секундах или меньше,
  • отключить оповещение клиента о неправильной сумме Michael MIC (MIC failure report frame).
  • начать планировать миграцию на WPA2/802.11i, ибо данный взлом показывает, что TKIP невольно наследует проблемы WEP и стоит ожидать что горячие головы будут развивать эту тему.

Дополнительная информация:

Верить нельзя доверять

Когда проводишь работы по аудиту, никогда не уверен в том, как выполнишь работу, оценивают которую обычно, увы, не по качеству отчета и полноте охвата анализа ИС заказчика, а по результатам теста на проникновение (когда его купил клиент).
Но речь ниже пойдет не о полезности тех или иных видов аудита, а о повышении вероятности проникновения в сеть заказчика.
Итак, выезжаем к клиенту, сеть которого является неприступной. Бьемся о бесчисленные системы блокировок и ограничений и ничего не можем сделать - объем мозга недостаточен. Самое время заняться социальной инженерией. Разного рода забавы в стиле "инженер техподдержки" и "новый администратор" оставим на совсем черный день. Попробуем что-нибудь околотехническое.
Давайте не будем возить на аудиты свою флешку. Многие люди будут недоумевать, когда узнают об ее отсутствии и... начнут приносить материалы на своих носителях. Естественно, в 99% случаев это usb-брелоки и еще в 80%, носители принадлежащие техническому персоналу.
Работы будем выполнять под Linux с работающим udev.
Немного подкорректируем файл настроек подсистемы:
/etc/udev/local.rules
-----------
KERNEL=="sd*", BUS=="usb", ACTION=="add", SYMLINK="usbdevices/usbflash"
KERNEL=="sd*", BUS=="usb", ACTION=="add", RUN+="/bin/sh -c '/bin/dd if=/dev/usbdevices/usbflash of=/tmp/`date +%F_%R`_dump'"
-----------
Перезагрузим демон.
#/etc/init.d/udev restart

Благдаря этому нехитрому файлику, носители, которые клиенты доверчиво "суют" в компьютер чужаку, в бакграунде побитно копируются на ноутбук в директорию /tmp в формате год-месяц-день_час:минута_dump. Пока аудитор из под кривой ОС руками смонтирует флешку, пока скопирует файл в жутком mc, на диске сохраняется образ флешки, включающий в себя, в том числе, удаленные ранее файлы, среди которых могут оказаться так нужные для проведния пентеста данные.

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

Tuesday, November 11, 2008

Социальная инженерия? Гослотерея!

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

Я обратил внимание на огромное количество рекламы новой
Государственной лотереи. В принципе, ничего необычного, государство решило подзаработать, если бы не экономический кризис....

Король Франции Франциск I еще в 16-м веке (в 1539 году, если быть точным), переняв идею лотерей у итальянцев, использовал государственные лотереи всякий раз, когда казна нуждалась в пополнении....

Не хочется думать, что у России аналогичная причина, а запуск проекта "Гослото" просто совпал с кризисом. С другой стороны вполне нормально проявить патриторизм и помочь Государству средствами, - ведь кто если не мы? Только хочется, все-таки, чтобы истинные причины тоже доводились до населения, - как-никак
Гласность.

Saturday, November 1, 2008

Где разместить IDS/IPS, в аналогиях

Я принимаю участие в проекте по построению безопасного шлюза в Интернет. Шлюз состоит из межсетевого экрана (МЭ), системы фильтрации Web-трафика с функцией кеширования (прокси-сервер) и системы IPS или IDS. Что касается того, где разместить прокси-сервер, то здесь вопросов не возникало: всем интуитивно понятно, что проси надо размещать за межсетевым экраном со стороны внутренней сети, а вот местоположение IDS/IPS почему-то не для всех является так очевидным. Вообще, вещи, о которых тут пойдет речь кажутся более чем понятными интуитивно, поэтому, для кого нет секретов в местоположении точки включения IDS/IPS в схеме безопасного шлюза в Интернет, – не тратьте время на чтение этого поста.


Традиционный МЭ, как правило, не «заглядывает» в сетевые пакеты выше уровня 4 модели OSI: он выполняет пакетную фильтрацию с контролем состояний (stateful) по IP-адресам и портам TCP/UDP. Да, последнее время популярны МЭ с тонкой фильтрацией до уровня приложения и встроенным IPS, – так называемые, UTM, но это – совсем другая история, не наш случай (да и вообще, мне кажется, неразумным хранить все яйца в одной корзине). Прокси–сервер уровня приложения, обычно, знает несколько протоколов, которые он проксирует. Он, как правило, не знает о существовании сетевых атак, не проводит анализ поведения, не выявляет отклонения от RFC (хотя, иногда можно, настроить прокси так, чтобы он проксил только соответствующий RFC трафик) и прочие аномалии.


IPS. Если очень поверхностно, то IPS – система прецизионной фильтрации сетевого трафика. Она анализирует не только все уровни модели OSI – до уровня приложения включительно, но еще, как минимум, может смотреть отклонения от RFC (или прочих стандартов) известных ей протоколов, блокировать известные сетевые атаки на основании сигнатурного анализа, вести статистический учет сетевого трафика на основании разнообразных метрик, проводить анализ поведения объектов в сети и на его основе различным образом реагировать. В этой связи IPS можно сравнить с системой тончайшей очистки… Представьте себе водоочистную станцию, состоящую из ряда фильтров: фильтр грубой механической очистки, фильтр тонкой очистки и фильтр тончайшей очистки. Разумное расположение этих фильтров таково, что из водозабора грязная вода сначала проходит фильтр грубой механической очистки, где очищается все то, что не стоит пить: камни, песок, крупные примеси. Затем логично поставить фильтр тонкой очистки, который превратит воду в практически питьевую, но только, скажем, после кипячения. Непосредственно перед потребителем имеет смысл поставить фильтр тончайшей очистки, который сделает из «практически» питьевой воды, просто питьевую, которую не надо будет дополнительно для этого обрабатывать, удалив все известные на сегодня бактерии и прочие отклонения от нормы. Если «подставить слагаемые»: МЭ – грубая очистка, Прокси – тонкая, IPS – тончайшая, то логично, на мой взгляд, IPS ставить ближе к защищаемому объекту, потребителю, следовательно, схема подключения будет такая Пользовательские рабочие станции – IPS – прокси – МЭ – Интернет.


IDS может определять все то же самое, что и IPS, но отличается возможностями по реагированию. IDS, в случае обнаружения чего-либо будет ругаться, но активно что-то предпринять не сможет, тогда как IPS, включенная в разрыв (Inline) может сразу и заблокировать обнаруженное Зло. Здесь IDS можно сравнить с неким индикатором состояния, термометром…. Представьте себе тело человека, зима. На человеке одета куртка, защищающая его, скажем от осадков, свитер, не пропускающий холод. Где мы будем мерить температуру тела человека? Между курткой и улицей? Наверно нет. А может, между курткой и свитером? Скорее всего, тоже нет. Логично располагать градусник ближе к телу, мы же его состояние хотим проанализировать. Следовательно, ситуация с IDS ровно такая же как и с IPS – точку съема трафика располагаем между рабочими станциями пользователей и Прокси.


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


Надеюсь, что это чтиво не было для Вас утомительным, и, также как у меня, у Вас на лице была улыбка.


Wednesday, October 8, 2008

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

В родной компании провел небольшой эксперимент – привлек к созданию документа “Инструкция пользователя” самих пользователей. Для этого использовался внутренний ресурс (форум) на котором зарегистрировано порядка 10% пользователей информационной системы.
Идея эксперемента выросла из того, что документ “Инструкция пользователя” должен быть написан понятным пользователям языком и не вызывать отторжения.
Предмет обсуждения был заранее подготовлен и выложен на форуме.
Структура документа следующая:
- вводная, термины
- основная часть инструкции
- памятка пользователя
- выдержки из законодательства
Особое внимание было уделено разделу “памятка пользователя”. В нем на одной странице было необходимо разместить информацию, которая покроет все положения инструкции, будет написана на понятном и простом языке и может быть прочитана за 3-4 минуты.
Первая рекация пользователей – пустая критика – инструкция пишется для галочки, инструкция будет основанием нас наказать и так далее. Позже пошли конструктивные предложения, в частности:
были исправлены слишком расплывчатые формулировки;
были конкретизированы некоторые ограничения;
исправлена достаточно серьезная ошибка связанная с использованием устаревших материалов при ссылках на законодательство.
Результат.
За 1.5 дня интенсивного обсуждения документ стал неплохим примером инструкции пользователя. В данный момент, документ находится на утверждении у руководства.
Выявлено желание пользователей формализовать использование программного обеспечения в компании, что будет сделано чуть позже.
Если появятся проблемы в процессе использования инструкции, сообщу дополнительно. :)

Friday, August 29, 2008

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:

Friday, August 22, 2008

На "Маленькая Безопасность"

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

  1. Мне практически не известны системы эффективные на 100%. Как следствие, имеющийся риск, как правило, не закрывается контролем на 100%. Обычно говорят о допустимых уровнях.
  2. Снижение эффективности связано с желанием большей гибкости, ибо абсолютно негибкие решения зачастую неприменимы (тут надо помнить, что безопасность - средство, а не цель, и, помимо того, что быть безопасным, бизнесу еще надо как-то работать)
  3. Не всегда есть возможность реализовывать превентивные меры, а так как оставаться совсем голым еще хуже - реалзиуем детективные: пусть нас можно атаковать, но мы об этом узнаем как только, так сразу, и это 100% лучше, чем не узнаем вообще!
  4. Считай что оценка рисков - выбор компромисса. Всегда, когда мы решаем проблему безопасности, мы вынуждены искать компромисс - это и есть оценка рисков, и она есть всегда, независимо от размера компании, шатата админов, критичности данных - все это влияет уже лишь на внутренюю организацию процесса оценки рисков. Но, как класс ативностей, он есть, возможно немного вырожденный или видоизмененный.
  5. Обучение пользователей. Ввиду того, что невозможно разных людей заставить думать одинаково, особенно в области, где они не специалисты, куда более эффективно придумать свод праил "что можно, а что нельзя". Это и есть те самые политики и стандарты. Да, они будут не такие пафосные, как в крупной компании, но как класс они неизбежно будут существовать, и о них будет разговор на awareness training-е для пользователей.
  6. На рынке есть решения и для SMB.

маленькая безопасность

Рынок безопасности бурно развивается и компании срывают с него сливки – крупные контракты, мощные системы, шифрование данных огромных объемов на огромных скоростях. Но, к сожалению, никто не обращает внимания на маленькие компании, в которых установлено от 2 до 100 рабочих мест, скоммутированных на неуправляемых коммутаторах или стареньких хабах, ведущих базу договоров и небольшую бухгалтерию. Зачастую такие компании даже не могут позволить нанять себе системного администратора, а если и нанимают, то это студент, который, в лучшем случае, учится по ходу работы.
Ну бог с ним, с российским рынком, тут своя специфика, но почему прозорливые компании с мировым именем не обращают внимания на этот сегмент?
Вы можете сказать, что дело в доходах. А вдруг нет? Вдруг дело в том, что вся информационная безопасность, в том виде, в котором она активно обсуждается на страницах глянцевых (!) журналов, становится очевидно-бесполезной в рамках небольших компаний? Нужны примеры? Пожалуйста:
1. Создание документов, в том числе высокого уровня (политики) не имеет смысла для компании, где личные связи между сотрудниками значат больше нежели приказы руководства;
2. Оценка рисков, инвентаризация активов теряют смысл из-за несоизмеримости затрат на выполнение работ и их практической ценности;
3. Системы мониторинга не работают из-за совмещения функций сотрудниками и элементами системы;
4. Эпидемии вредоносного ПО покрывают 100% парка, из-за тесных связей между сотрудниками.
Что выходит на первый план в таких системах? Думаю следующее:
1. Система должна быть защищена по-умолчанию. Возможно в ущерб функциональности.
2. На первый план выходят превентивные системы, такие как резервное копирование, снижение привилегий пользователей, ограничения на доступ к информационным системам. Все должно работать «из коробки».
3. Системы, эффективность которых значительно ниже 100% (значительно можно заменить на 90%) , отметаются как неэффективные. К ним относятся – системы обнаружения атак, антивирусы, системы фильтрации контента и почты.
4. Обучение пользователей, но не формальное, «для галочки», а то, что будет понятно людям и принято ими как правило.

Monday, August 11, 2008

Too Many Signatures Enabled

Recently I had a funny e-mail correspondence with ISS support centre. The problem was that suddenly one of Proventia GX IPS stopped passing traffic through it. It was at least strange for me because that IPS have to be fail-open (i.e. pass traffic through when fails). I ran Provinfo (it's a special script that collects information about device's configuration and recent logs that should help support engineers to figure out what was the problem) and sent resulting archive...

... and received an answer: "I took a closer look at your ProvInfo and noticed that you have too many signatures enabled. I am afraid you will have to tune your policy.

At this moment, when you have a lot of traffic, the Proventia G will just be overwhelmed because he needs to check for too many signatures, attack and audit".

Well this proposal sounds to me so strange that I even can't find right words to comment it. In addition it should be mentioned that Proventia has something called 'software bypass' that allows it to pass traffic without analysis in case of high load and this can't case devise to go down.

Tuesday, August 5, 2008

Трафик на 404.adatoms.com

Анализ журналов Web-прокси показал огромное количество трафика (5Гб, 92% всего трафика данного пользователя за неделю) от одного пользователя на сайт 404.adatoms.com. Вот фрагмент лога:

10.xx.xxx.xxx - "-" [04/Aug/2008:14:32:43 +0400] "GET http://404.adatoms.com/?client=MyCentriaIB%26ver=1.8%26wmid=81%26scheme=MYC2%26uid=FU4BEZLWRR56W%26lt=1217849565%26url=http%3A%2F%2Fwww%2Esj4%2Eru%2Fcgi%2Dbin%2Fiframe%2Fntv%3F929351%26code=403 HTTP/1.1" 403 1735 340 "" "MyCentria72" "wa, it" 10 text/html" "default" 0.215 "-"

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

Интернет-поиск не дал ничего, кроме этой публикации.

Примечательно, что после отработки антивируса активность прекратилась. Антивирус (McAfee) успешно удалил файл с названием XPEHOMOP.exe, распознав его как New Malware.n (Trojan).

Tuesday, July 29, 2008

Write Once Read Many

During preparation to some of the certification exams I encountered the term WORM - Write Once Read Many media. Surely I knew at least one example of it - CD-R or DVD-R discs - but the term was used in a way, that CD-R and DVD-R media can not support. For example, log files could be stored on such a media so that attacker is not able to tamper with them (again - CD-R would not fit this use as you can not write logs directly to CD so there always will be a lag between actual logs and what is stored on the CD). And I knew no WORM-type media that would fit such usage, until yesterday, when SanDisk announced their WORM flash memory. I really think this would be useful for forensics purposes and look forward to hearing actual uses of the technology. Hopefully you will really not be able to erase/modify the data through some undocumented feature :)

О вере в чудо: продолжение

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

Наверняка многие заметили, что наше понимание окружающего нас мира сильно субъективно. Этот субъективизм является следствием наборов готовых шаблонов восприятия, которые мы набрали в ходе нашей жизни. Под шаблоном восприятия я понимаю некий элемент действительности однозначно воспринимаемый субъектом. Сложновато, но далее я постараюсь приложить все усилия, чтобы стало понятнее. Имея определенного рода набор (багаж) таких шаблонов восприятия, процесс понимания действительности сводится к обычному сравнению созерцаемого процесса с имеющимися в багаже шаблонами. Это очень просто: для того, чтобы понять, что стена длинная или короткая, мы ее сравниваем с известным отрезком, например в 1 метр или с аналогичной стеной которую мы видели ранее, и она считалась «длинной» или «короткой». Зачастую нужных шаблонов не находится, в этом случае выполняется своего рода «подгонка» под имеющийся набор шаблонов. С такой подгонкой связаны явления упрощения действительности до удобного для восприятия состояния, а также всякого рода поговорки вроде той, что каждый видит мир в «меру своей испорченности», «через призму своего восприятия», или «каждый видит то, что он хочет увидеть». То что это, скорее всего, верно очень просто проверить на примере – действительно, когда мы ищем нечто, о чем имеем полное представление, поиски длятся достаточно недолго, но искать то, что мы никогда не видели (следовательно, у нас нет шаблонов) – практически невозможно.

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

Поговорим о шаблонах. Как я отмечал они берутся из жизненного опыта. Здесь, на мой взгляд, очень простая закономерность – чем больше в жизни человек видел и знает, тем больше у него шаблонов, тем более многогранно его понимание действительности, тем оно более объективно, а, следовательно, ближе к реальности. Большое количество шаблонов позволяет описывать процессы разными их наборами, т.е. объяснять действительность с разных точек зрения, тогда как людям с ограниченным числом шаблонов понятна только одна «сторона медали». Аналогия очень простая – см. рисунок, на всех из них изображен куб, но только последнее изображение позволяет это более или менее понять.



Теперь – главное, к чему я все это говорю. Различные люди имеют различные наборы шаблонов, как следствие – различные люди объясняют действительность по-разному. Нет «глупых» и «умных», а есть различные люди с различными наборами шаблонов. Понимание о глупых и умных связано с тем, что общество за годы существования приобрело некий набор «планок», на основании которых мы, знакомые с этими «правилами приличия», строим свои суждения о других. Вообще, «правила приличия», о их значимости для самовыживания общества, и о их происхождении – тема другого разговора, поэтому не буду на этом останавливаться. Но кто сказал, что эти «планки», созданные «цивилизованным обществом» верны? Многолетняя история? Мы уверены, что мы не ошибаемся? Лично я не уверен.

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

Monday, July 28, 2008

Пословицы и правда жизни: о вере в чудо

Начал использовать решения Microsoft, - учись верить в чудо!



Данное правило я сформировал для себя достаточно давно, в период одного из общений по поводу Инцидента , когда инженер поддержки буквально сказал: "Здесь вам не Linux, здесь все взаимосвязано!". Как это не кажется странным, он был 100% прав: зачастую весьма странные действия приводят и устранению еще более странных проблем.

Wednesday, July 23, 2008

Конвергенция контроля доступа к периферийным устройствам и антивирусного ПО

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

Для ограничения и контроля доступа к периферийным устройствам (съемные накопители USB, CD/DVD-приводы, пр.) мы используем соответствующее, специально для этого предназначенное, ПО. Функциями этого ПО (далее Система) являются: предоставление доступа к устройствам в соответствии с политикой использования, назначенной для конкретного пользователя/группы пользователей (система полностью интегрируется с MS Active Directory) и централизованное ведение журналов – т.е. имеется некий интерфейс из которого администратор Системы может посмотреть какие файлы были успешно или неуспешно записаны с или на устройство, а также, какой процесс операционной системы это сделал.

Последние время мы наблюдаем огромное количество различного вредоносного ПО, распространяющегося через автозапуск со съемных носителей и, соответственно, заражающие другие съемные носители. Приведу несколько примеров, далеко не все, – W32/Autorun-AK, PWS-LegMir.gen.k, PWS-WoW, Troj/Shuckbot-A, W32/Autorun.worm.u, пр. К сожалению, наш антивирус, развернутый на рабочих станциях пользователей не всегда успешно обнаруживает и лечит эти вирусы (обновления антивирусных баз жестоко отстают). Здесь и приходит на помощь анализ журналов Системы контроля доступа к периферийным устройствам. Алгоритм такой:

  • Формируем отчет по записи файлов .exe, .com на носитель,
  • Анализируем отчет: ищем записи файлов с подозрительными именами в корень носителя (в некоторых случаях ситуация совсем смешная – «процесс kesha.exe записал файл E:\ kesha.exe»). Понимание того, что такое «подозрительное» имя приходит с опытом, по началу, можно просто обращать внимание на файлы, записанные в корень тома. Опыт показывает, что бывают легитимные (не вирусы) файлы .exe, со странными именами, записанные в корень, но не попадался ни один легитимный файл .com, не являющийся вирусом.
  • Подозрительные имена просто проверяем в Интернет. Пример для Recycler.exe. Полезно то, что Система регистрирует не только имя файла, но и его размер, что позволяет его проверять.
  • Убедившись, что данный подозрительный файл, вероятнее всего вирус – включаем на антивирусе забирать файл в карантин по имени (вообще, система обладает функцией теневого копирования, что позволяет настроить забор файлов и на самой системе, но мы ее не используем, поскольку теневое копирование не работает для данного имени файла). Конечно, лучше забирать в карантин и по имени и по сумме MD5 (сумма берется из описаний, найденных в Интернете), но, например, наш антивирус умеет забирать только по имени – что ж, все лучше, чем ничего.
  • Пойманный вирус анализируется альтернативными движками, например - http://www.virustotal.com/ . Такая проверка должна увеличить уверенность, что данный образец – действительно нежелательное ПО.
  • Если опасения подтвердились – направляем отчет с http://www.virustotal.com/ и образец файла-вируса (взятого из карантина) в поддержку антивируса.

По опыту поддержка антивируса выпускает патч в этот же день. Остается только применить его по всем рабочим станциям пользователей.