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

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

Как Вы боретесь с этим? Что используете? Какие регламенты, программные продукты и тп.

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

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

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

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

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.

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

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

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

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

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

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

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

Scanner on Trunk

Vendor: IBM ISS.

Product: Proventia Network Enterprise Scanner

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

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

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

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

Hope, this small enhancement will be added soon.

Temporary Group Membership

Vendor: Microsoft Corp.

Product: Active Directory.

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

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


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

Logevidence response in RealSecure Network/Gigabit Sensor

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

Vendor: IBM ISS.

Product: RealSecure Network 10/100 and Gigabit

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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