Корпоративные флешки

Многие системы (Lumension, Check Point) контроля доступа к съемным носителям имет следующий функционал: запись разрешена только на шифрованный носитель. При этом, зачастую этот шифрованный носитель может быть прочитан только с использованием этой системы, а на "чистом" компьютере выглядит как что-то непонятное и Виндовс предлагает его отформатировать. Такой механизм служит для запрета утечки конфиденциальных данных.
У меня в этом случае разрыв шаблона. Насколько я понимаю, передача данных между компьютерами через флешки необходимо только в случае передачи с корпоративного компьютера на некорпоративный или наоборот. Передача через флешки между корпоративными компьютерами не нужна (и вредит безопасности), так как на то есть сетевые ресурсы, которыми следует пользоваться. А описанный подход, когда запись данных возможна только на "авторизованную флешку", которая не прочитается на некорпоративном компьютере (иначе, будет утечка :-)), делает невозможным самый логичный сценарий использования съемных носителей вообще.

Что же делать?
1. Записывать данные на флешку шифрованными, но с возможностью расшифрования на некорпоративном компьютере без необходимости инсталляции какого-либо софта (это "волшебство", как правило, достигается записью программки расшифрования непосредственно на флешку.
2. Использовать какое-нибудь DLP, которое будет анализировать контент и более гибко разрешать и запрещать запись на флешку в зависимости от контента.
3. Возложить весь груз ответственности за компрометацию данных на пользователя, разрешив запись на флешку, но логгируя записанное и расследуя случаи предположительной утечки. Несмотря на то, что данный подход кажется самым "небезопасным", на мой взгляд, он все же неплох, поскольку никакая DLP не остановит мотивированного залоумышленника ввиду простого принципа: если я могу данные почитать, я всегда могу их скопировать, - я могу переписать карандашеком с экрана, я могу сделать скрин-шот, я могу сфотографировать телефоном, я могу прочитать написанное на диктофон (встроенный в тот же телефон), я могу перекодировать/модифицировать обратимым образом контент так, что DLP ничего не поймет, .... - вариантов слишком много, а внедрение мега-дорогих решений только с целью защиты "от дурака" надо еще оценить и хорошенько обдумать.

Снова о "на коленке"

Очень важно осознавать, что зачастую ключевой характеристикой проекта (под проектом я здесь буду понимать любую деятельность по превращению чего-нибудь менее пригодного, во что-нибудь более пригодное) является скорость появления результата. Современные условия бизнеса таковы, что результат нужен как можно скорее - действительно, ложка хороша к обеду, - никто не готов ждать вечно, поскольку никакое качество результата не покроет столь продолжительное ожидание, причем, далеко не нулева вероятность, что к моменту окончания ожидания уже нужно будет не то, что изначально планировалось, а может и вовсе не нужно. Поэтому я противник мега-коплексных подходов и как-следствие долгих проработок. Проект изначально надо продумать так, чтобы он как можно быстрее давал как можно больше Value, этакие "Quick wins", расположенные в правильном порядке для достижения максимального совокупного эффекта.
В этой связи я считаю вполне нормальным подход реализации решения по частям: сперава автоматизировать наиболее востребованный функционал (который наиболее трудоемок на сейчас, или который в текущей реализации производит наболее неготиное влияние) - такая "заплатка" уже сразу даст ощутемый результат, далее можно уже это решение "докручивать", дорабатывать, тиражировать, в общем, развивать.
Не надо заставлять бизнес ждать, пока вы придумаете супер-мега-комплексный подход\процесс, а затем спроктируете и внедрите решение, которое его полностью автоматизирует, при этом все сразу будет учтено и заработает как надо. Это - абсолютная утопия, так как:
1. все сразу учесть не получится, поскольку новый этап познания, открывает нам границы нашего незнания, иными словами, чтобы понять как оно там на крыше, нужно до крыши добраться, или, что аппетит приходит во время еды,
2. пока вы будете долго строить свое решение, окружение уже несколько раз поменяется, поэтому проекты продолжительностью более года имеют мало практического смысла (конкретно мое мнение, - 6 месяцев должно быть достаточно, чтобы "корова" начала приносить "молоко" - через 6 месяцев от начала проекта, должен появиться результат),
3. весь пост про то, что надо стремиться как можно быстрее давать результат, при таком мега-комплексном подходе, результат будет нескоро, а учитывая пп 1, 2 он может быть и не тот, что ожидали и не применим к новым условиям :)

Перегибы безопасности

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

Почему-то иногда считается, что безопасность можно обеспечить, если внедрить все контроли, которые можно придумать, а если их еще внедрить в наиболее жестком варианте, то будет еще круче, хотя это напрямую противоречит принципу компромиссности, отмеченному выше (следует также добавить, что в условиях крупной корпорации, критерий управляемости выходит на первый план, по сравнению с качеством продукта безопасности. Простой пример: прекрасный антивирус, с максимальным % корректного определения\лечения зловреда, но не управляемый удобно и надежно в сети из 6000+ рабочих станций не будет иметь шансов в крупной корпорации – обслуживать вручную столько инсталляций невозможно). Но, самое ужасное, что такие контроли приводят к «перегибам», что снижает безопасность, что я и попытаюсь передать в этом посте.

1. «Высокий уровень сетевой безопасности в локальной сети». Ситуация заключается в том, что локальная сеть сегментирована (что очень хорошо) и трафик между сегментами фильтруется (что тоже прекрасно)… но плохо то, что изменение политик фильтрации происходит по неочевидным и долгим процедурам. Неочевидные и долгие процедуры приводят к тому, что процедура конфигурирования информационных потоков между сетевыми сегментами не может обеспечить быстро изменяющиеся потребности бизнеса. Но бизнесу надо работать и он … переносит свои информационные потоки в Интернет. Сама ситуация абсурдна в том смысле, что прямое назначение ЛВС – транспортировка внутренних информационных потоков, однако формальная зарегулированность ЛВС не позволяет ее использовать в интересах бизнеса по прямому назначению. Очевидно, вынос трафика приложений в Интернет, даже с использованием VPN, снижает уровень безопасности.

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

А) Перенос данных в облачные сервисы – использование различных колоборативных сред внешних сервисов, типа группы Facebook или Google, внешние тематические форумы и т.п. Здесь также противоречие смыслу ЛВС, которая должна стать средой для хранения, обработки и передачи корпоративных данных, а проблемы безопасности – очевидны – выложенные данные в Интернет перестали быть корпоративными

Б) Системы растут «подпольно», как «сорняки» в режиме ad-hoc. Здесь проблемы безопасности в том, что «проектирование» и «внедрение» таких систем производится без какой-либо оглядки на безопасность или выполнения элементарных рекомендацией производителей по ИБ, но уже являются продуктивными (важно понимать, что де-факто система начинает быть продуктивной когда в ней появились продуктивные данные). Здесь важное фундаментальное следствие: когда внедрение чего-то в заданных рамках бюджета и сроков неизбежно, всяко лучше ввязаться в процесс и попытаться сделать в части безопасности все возможное, а не «закрывать глаза» на сорняки, прикрываясь тем, что их не должно быть.

3. Стремление буквального исполнения требований регуляторов. В РФ великое множество compliance-а. Следует признать, что технологическое отставание нас от них равно бесконечности (мне, очень больно это осознавать). Как следствие, используемые нами продукты не соответствуют требованиями наших регуляторов, так как соответствуют требованиям их регуляторов. Поэтому существует много заплаток\докруток\доработок или, что еще хуже, разработанные с нуля продукты, подходящие под наши требования. Качество этих продуктов оставляет желать лучшего. На причинах не буду останавливаться особо, они очевидны: отсутствие конкуренции, мизерный рынок сбыта и т.п. Поскольку «безопасность» - один из элементов качества, - с ней тоже беда, но еще большая беда с управляемость, удобством использования, совместимостью и пр. , что хоронит возможность их использования. Но хочется отметить позитивные сдвиги в области отечественного compliance в последние годы: он стал более современный, стал учитывать возможность его практического применения - так держать! буду надеяться, что когда-нибудь наш compliance превратиться из "риск несоответствия" в "удобный инструмент использования".

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

5. Защита от админа. Я люблю повторять, что «риск нелояльности админа не снижается исключительно техническими контролями». Это также очевидно, как очевидна необходимость доверия пассажиров пилоту самолета или водителю автобуса. Более того, безопасность только тогда эффективна, когда реализуется в том числе и руками администраторов, когда она пронизывает все процессы поддержки и сопровождения. Да, безусловно, необходимо мониторить работу админов, но не надо им мешать делать их работу. Не надо путать понятие «Segregation of duties» с банальным размыванием ответственности за доступность. Доступность – это характеристика безопасности, и если в час Х у пользователя пропадет сервис, а админ не сможет оперативно выполнить свою работу – пострадает и безопасность, будучи исключительно прикладной: нет сервиса пользователя => нет объекта применения безопасности => нет и безопасности.

В заключение (обобщая пп 1,2) хочется сказать, что контроли безопасности должны быть не напряжны для их исполнения, по возможности. Если контроли построены по принципу «чтобы всем замучились», обеспечить их исполнение будет невозможно. Даже в случае невысоких накладных расходов на реализацию контролей безопасности, обязательна работа с бизнесом (бизнес-пользователями и их руководителями), чтобы люди понимали «зачем все это», «почему оно так, а не иначе» - только в этом случае можно надеяться, что люди будут исполнять контроли безопасности обдуманно, что, безусловно, будет способствовать повышению уровня безопасности, который зависит не только от работы подразделения ИБ, но и от каждого пользователя в отдельности!

Mcafee VIrusScan Console password recovery

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

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

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

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

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

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

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

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

b081dbe85e1ec3ffc3d4e7d0227400cd:

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

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

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

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

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

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