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

Очень важно осознавать, что зачастую ключевой характеристикой проекта (под проектом я здесь буду понимать любую деятельность по превращению чего-нибудь менее пригодного, во что-нибудь более пригодное) является скорость появления результата. Современные условия бизнеса таковы, что результат нужен как можно скорее - действительно, ложка хороша к обеду, - никто не готов ждать вечно, поскольку никакое качество результата не покроет столь продолжительное ожидание, причем, далеко не нулева вероятность, что к моменту окончания ожидания уже нужно будет не то, что изначально планировалось, а может и вовсе не нужно. Поэтому я противник мега-коплексных подходов и как-следствие долгих проработок. Проект изначально надо продумать так, чтобы он как можно быстрее давал как можно больше 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 - словарь.

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

Фантазии на тему практики СТО БР ИББС-2.2-2009

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

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


Любопытно, что в документе пример дается исключительно про классификацию по конфиденциальности (ограниченная, открытая), однако свойства предлагаются все (КЦД) :-). Поэтому разумно в классификации учитывать эти свойства, скажем:
- информация, критичная к нарушению конфиденциальности,
- информация, не конфиденциальная, но где должна быть прогарантирована целостность и доступность,
и т.п. 
2. Определяется перечень типов объектов среды для каждого информационного актива. По сути - это те места/контейнеры, где располагаются информационные активы, примеры:
- сети передачи данных,
- серверы,
- файлы, 
- т.п.
Исчерпывающий, на мой взгляд, список приведен в разделе 4.5. документа.
3. Для каждого объекта среды определяются источники угроз и свойство ИБ на которое он воздействует. Перечень источников угроз приведен в приложении 1, необходима очень развитая фантазия, чтобы туда что-то добавить - надо брать за основу.
4. Определяются два ключевых момента:
- степень возможности реализации угрозы (СВР), что по сути является вероятностью того, что выявленный источник угрозы будет негативно воздействовать на объект среды,
Рекомендуемая шкала оценки СВР:
-- нереализуемая,
-- минимальная,
-- средняя,
-- высокая,
-- критическая,
-  степень тяжести последствий (СТП) от потери свойств ИБ, что фактически является ущербом.
Рекомендуемая шкала для СТП:

-- минимальная,
-- средняя,
-- высокая,
-- критическая,

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

Основное волшебство заключается в определение СВР и СТП. Надо помнить, что анализ рисков делается не просто чтобы определить стоимость риска, а также придумать контроли, как эти риски снижать до приемлемого уровня, причем, чтобы стоимость контролей была экономически оправдана (для этого я написал надо(*) ). Поэтому важно понять, на что мы можем влиять.

А влиять мы можем:
1. полностью на СВР, поскольку накручивая базовые контроли безопасности - требования к обеспечению безопасности сетевого периметра, требования по безопасной конфигурации стандартных подсистем (ОС, СУБД, сервера приложений, сетевое оборудование, т.п.), требования к типовым операционным сервисам (управление изменениями, управление патчами, т.п.), требования к проектированию информационных систем (чтобы  уже сразу при проектировании проектировалась и безопасность, что сделает ее интегрированной, а следовательно, более эффективной) - мы уже значительно снижаем наши СВР для тех или иных источников угроз. Тут, как мне кажется, на N+1-ом случае фиксации одного и того же риска следует задуматься о реализации соответствующего контроля на уровне базовых контролей ИБ. В конечном счете надо стремиться к тому, что под анализ рисков попадают только специфичные для данной системы контроли ИБ, - не надо всякий раз указывать баяны и изобретать велосипед. Отсюда следствие, что так или иначе все "стандартные" контроли рано или поздно выдавятся в инфраструктуру, а для анализа останется тот "сухой остаток", сильно специфичный для системы.
2. на СТП - в части стоимости восстановления после инцидента (ликвидации последствия нарушения ИБ, - как это указано в документе). Если превентивных контролей ИБ (априорные защитные меры, как это указано в документе) недостаточно или они нерентабельны, то можно посмотреть в сторону реактивных контролей (апостериорные защитные меры, как это называется в документе) - т.е. заняться вопросами DRP&BCP. Опять же надо следить за рентабельностью контролей.

Подытожим план:
1. Проанализировать циркулирующую информацию, критичность ее по основным свойствам, источники угроз, выявить СВР и СТП на текущий момент. Определить контроли.
2. Понять, какие контроли постоянно востребованы и унести их инфраструктуру и базовое ИТ.
3. Всякий раз при оценке рисков анализировать что можно унести в инфраструктуру, чтобы сконцентрировать процесс анализа рисков максимально на специфических для системы рисках и контролях, которые нерентабельно реализовывать глобально в базовом ИТ.

Сертифицированное на несертифицированном 2

В продолжение поста Сергея:
Повышаем привелегии в системе при помощи ViPNet Client или уязвимость CVE-2013-3496

Харденинг win7

Речь пойдет об отключении для Мира двух любимых портов Microsoft - 135/TCP и 445/TCP/UDP.

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

445
Тушится остановкой двух сервисов:

• Server
• TCP/IP NetBIOS Helper

и переводом их в "Disabled".
После перезагрузки 445 не будет слушаться.

Отличный вариант предложил Citrix (http://support.citrix.com/article/CTX118386) , однако он не работает в 7, но прекрасно рабоатет в XP.

135
Просто косить службу Remote Procedure Call (RPC) - плохо - привычное поведение Windows будет весело удивлять новыми особенностями :) - когда вам будет грустно, играясь этим можно испрвить себе настроение. Не даром это нельзя сделать через интерфейс, но, безусловно, можно подправить в реестре. 
 Более работоспособным представляется вариант завешивания 135 на лупбэк (127.0.0.1). Очевидно, что MSRPC жизненно важный сервис (в этом можно убедиться поупражняясь его отключением через реестр), - понятия не имею почем MS не повесил его на лупбэк в дефолтной конфигурации, это же безопаснее.... но, видимо, безопасность, - не важная цель для MS, поэтому на протяжении уже скоро 20 лет, 135 доступен для подключения для Мира, прослушиваясь на всех интерфейсах ОС.
Для привязки 135 к 127.0.0.1 надо создать ключик реестра, файл .reg выглядит так:
C:\>type rpc-svs.reg
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Rpc]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Rpc\Linkage]
"Bind"=hex:49,50,76,34,01,00,00,00,01,00,00,00,7f,00,00,00


C:\>

Импортировав это, и перегразившись мы увидим, что 135 слушается на лупбэке. Выглядит это так:
C:\>netstat -ano | find ":135"
  TCP    127.0.0.1:135          0.0.0.0:0              LISTENING       732

C:\>tasklist |find "732"
svchost.exe                    732 Services                   0      5 652 K

C:\>

Update 2013-07-01
Опыт применения в корп. сети показал низкую работоспособность такой безопасной конфигурации:
1. При остановке служб перестает работать DFS
2. Служба Print Spooler зависит от RPC, при завешенном 135 на лупбэке служба падает при попытке распечатать документ, как утверждает Win7 в своих логах "неожиданно".

При возвращении "обратно" (подъем служб и удалении соданной ветки реестра) - все начинает работать.

Мотивация Демотивация

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

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

Тем не менее, до сих пор еще встречаются случаи, когда мотивация реализуется через "кнут", а не через "пряник" - "провинившихся" штрафуют на % вознаграждения, вероятно, в предположении, что это простимулирует их не делать ошибок. Причем, фактура показывает, что речь не идет о злостных нарушителях, напротив, - это люди проявляющие инициативу, старающиеся что-то сделать, ну и, как нередко бывает, у людей, которые делают, допустивших ошибку. Что происходит дальше? "Оштрафованные" понимаю давнюю "истину", что для того, чтобы ни за что не быть наказанным, надо просто ничего не делать - тот, кто ничего не делает, ошибок не допускает, соответственно, он не может быть наказан. С пониманием этой "истины", сотрудник переключает все свои усилия на недопущение попадания под какую-либо ответственность, постоянно доказывая, что то или иное дело вне зоны его ответственности\должностных обязанностей. Способствует ли это повышению эффективности Компании? Ну конечно, нет!
Очевидно, что мотивировать отбирая - невозможно, необходимо мотивировать давая. Итак, мотивационная программа по пунктам:
1. необходимо поощрять достижения, должны премироваться лидеры.
2. должно для всех быть очевидно, что такое "достижение", каковы его критерии, необходимо, чтобы все понимали, как надо работать, что надо достигать, чтобы быть поощренным.
3. при реализации "поощряемых" достижений не должна страдать основная работа, выполняемая за зарплату. Т.е. критерии оценки "достижений" должны учитывать операционную эффективность в отношении прямых обязанностей.
4. каждое "достижение" - предмет для обсуждения с коллективом. Для коллектива должно быть очевидно, почему вот это является достижением, достойным поощрения, должно быть понятно каждому, почему не он достоин поощрения, и он должен иметь возможность сделать выводы, как ему надо работать, чтобы тоже заслужить поощрение.

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