Thursday, December 19, 2013

Эшелонированная оборона

Издавна нас учили, что безопасность должна быть эшелонированной, т.е. чтобы добраться до корпоративных секретов, злоумышленнику надо сначала найти дуб в лесу из 108426062525234 деревьев, разглядеть там сундук, достать его, открыть, поймать вылетевшую утку, достать из нее яйцо, которое затем надо суметь разбить, а иголку из этого яйца также надо успешно сломать.
Требование эшелонированности как-то преобразовалось, и даже попало в некоторые отечественные рекомендации по ИБ (см. п. 7.5.5), в необходимость использования подряд нескольких антивирусов разных производителей.
За годы наблюдения различных вирусных атак и попыток борьбы с ними, могу с уверенностью сказать следующее:
1. Чисто антивирусы, как класс, мертвы. Обход антивируса - вполне решаемая задача.
2. Решения, занимающие лидирующие позиции, технологически примерно одинаковы. Поэтому заменять один антивирус на другой из соображений качества обнаружения смысла никакого. Это про движок.
3. Практически любой зловред в течение одного дня попадает ко всем вендорам в базу, поэтому базы также у всех примерно одинаковы.
4. .....
Поэтому ставить последовательно несколько антивирусов подряд смысла большого нет.

Так что же делать? Как же обеспечить эшелонированность? 
В современных условиях эшелонированность должна достигаться не за счет использования однотипных решений от разных производителей, а за счет использования различных технологий защиты. При этом мультивендорность или моновендорность на качество влияет весьма посредственно. Т.е. наряду с простым антивирусом на хосте имеет смысл рассмотреть возможность использования IPS, систем контроля целостности и контроля приложений, систем с модным названием DLP, в сети имеет смысл использовать IPS/IDS и системы профилирования трафика и анализа поведения, на шлюзах - системы фильтрации по различным признакам, безусловно, надо собирать все логи и успешно их анализировать. Использование разных технологий значительно повысит вероятность выявления и эффективной форенсики.

При этом надо помнить, что моновендорность имеет ощутимое преимущество перед мультивендорностью - это тупо дешевле.

Thursday, November 28, 2013

IDM как система мониторинга

В целом, достаточно занимательное занятие логгировать пролетающие через фаервол пакеты - обычно, почему-то, логгируют deny-и, хотя, наверно, любопытнее было бы смотреть на permit-ы. Также прикольно смотреть логи IDS\IPS... Но с точки зрения контроля доступа (а вся безопасность так или иначе может свестись к контролю доступа к защищаемым данным) куда более интересны события добавления\удаления роли\группы\полномочия. Безусловно любая продвинутая система умеет писать такие события в свои логи безопасности, соответстенно, их можно собрать в какой-нибудь SIEM и повесить на них какое-нибудь реагирование.
Однако тут есть некая философская проблема - такой инцидент не поднимется на бизнес-уровень самостоятельно и оператору мониторинга SIEM придется переводить технический отчет на язык понятный менеджерам. Делать такое "уточнение у бизнеса" скорее всего придется, поскольку далеко не всегда у оператора SIEM есть понимание насколько легитимно то или иное присвоение\удаление. 
Другим вариантом является - возложение вопроса аудита полномочий пользователей в системах на предмет соответствия поданным заявкам на подразделение контроля доступа, которое если и делает такие проверки то нечасто, что создает возможность преднамеренной атаки НСД остаться вообще не замеченной: несанкционированные добавления с последующим удалением полномочий проводятся между процедурмаи аудита прав.
Поэтому, обычно, на практике все-таки делают автоматическое оповещение об изменении полномочий, но для каких-то особых случаев, когда таких пользователей\ролей\полномочий не так много - как правило, какие-нибудь администраторы (Domain Admins, Enterprise Admins, Administrators, ....), казначеи и операторы систем ДБО и т.п.

Но все становится по-другому с появлением решений IDM\IAG (не буду тут много лить воды об их функционале и различиях - можно ознакомиться в Интернете). Практически все современные их представители имеют функционал аудита настроенных прав доступа в управляемой системе (системы, доступ к которым регулируется через IDM) на соответствие согласованным доступам в системе IDM. Найденные несоответствия могут обрабатываться по-разному, как правило, это настраиваемо. Мне нравится реакция в виде запуска workflow согласовния. Это позволяет автоматически вывести техническую проблему появления членства в лишней группе AD на бизнес-уровень - согласующие получат автоматически сгенеренные заявки по этому поводу на согласование. Если такой доступ был предоставлен в связи с реальной бизнес-потребностью, доступ останется и легализуется. Если такой доступ появился в результате каких-то неправильных позывов - он будет отобран IDM на основании отклоения поданной на этот доступ заявки. И вот тут уже прилетает оповещение в Безопасность, что был обнаружен и испрвлен факт НСД (так как заявка была отклонена Бизнесом). Принципиально здесь то, что решение об отъеме доступа принимается не оператором SIEM, у которого, безусловно, есть чем заняться (его любимые фаерволы и IDS\IPS генерят гигабайты логов в день, с которыми, раз уж собираем, надо хотя бы что-то делать), а бизес-согласующие по результатам отработки формального процесса согласования\отклонения доступа.

 

Tuesday, November 19, 2013

Наследование

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

Thursday, November 14, 2013

Проектирование и внедрение

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

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

Мне можно возразить, что в итоге (когда внедрять будут первые, проектанты) получается самая очевидная и рабочая схема, когда один проектирует и внедряет. Вот он один - на нем вся ответственность за результат, логично, поскольку проектирование, по большому счету, ему самому нужно, а мне, как заказчику, важнее результат (то, что будет после внедрения), а не то, как решение было спроектировано. Однако, подход с такой этапностью дает возможность на втором этапе победить некомпетентному исполнителю. Зачем самостоятельно создавать такой риск? Зачем все эти накладные расходы на двухэтапность, столько потерянного времени?..



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

Saturday, October 5, 2013

В транслит на C#

Решал тут как-то микро-задачу по поиску логинов пользователей в домене, где почему-то не учитывается ФИО по-русски. Понадобилась транслитерация, в соответствии с определенными правилами. Странно, но сообразил далеко не сразу, видимо, старею :-(

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

private static string Tr(string s)
{
    string ret = "";
    string[] rus = {"А","Б","В","Г","Д","Е","Ё","Ж", "З","И","Й","К","Л","М", "Н",
          "О","П","Р","С","Т","У","Ф","Х", "Ц", "Ч", "Ш", "Щ",   "Ъ", "Ы","Ь"
          "Э","Ю", "Я" };
    string[] eng = {"A","B","V","G","D","E","E","ZH","Z","I","Y","K","L","M","N",
          "O","P","R","S","T","U","F","KH","TS","CH","SH","SHCH",null,"Y",null,
          "E","YU","YA"};

    for (int j=0; j < s.Length; j++)
        for (int i = 0; i < rus.Length; i++)
            if (s.Substring(j, 1) == rus[i]) ret += eng[i];
     
    return ret;
}
 


Вариант, более быстрый на больших объемах (длинных строк транслитерации) и более щедящий к расходу памяти:
 
private static string Tr2(string s)
{
    StringBuilder ret = new StringBuilder();
    string[] rus = { "А", "Б", "В", "Г", "Д", "Е", "Ё", "Ж", "З", "И", "Й",
          "К", "Л", "М", "Н", "О", "П", "Р", "С", "Т", "У", "Ф", "Х", "Ц",   
          "Ч", "Ш", "Щ", "Ъ", "Ы", "Ь", "Э", "Ю", "Я" };
    string[] eng = { "A", "B", "V", "G", "D", "E", "E", "ZH", "Z", "I", "Y"
          "K", "L", "M", "N", "O", "P", "R", "S", "T", "U", "F", "KH", "TS",   
          "CH", "SH", "SHCH", null, "Y", null, "E", "YU", "YA" };

    for (int j = 0; j < s.Length; j++)
        for (int i = 0; i < rus.Length; i++)
            if (s.Substring(j, 1) == rus[i]) ret.Append(eng[i]);
    return ret.ToString();
}
        
Если есть у кого более прикольные варианты решения такой же задачи, пожалуйста, предлагайте.

Monday, September 30, 2013

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

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

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

Sunday, September 29, 2013

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

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

Thursday, September 19, 2013

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 - словарь.
Если Ваш словарь достаточно хорош, а пароль достаточно слаб, то через несколько секунд вы сможете редактировать настройки своего антивируса.



Wednesday, July 24, 2013

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

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

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


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

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

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

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

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

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






Friday, June 28, 2013

Харденинг 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 в своих логах "неожиданно".

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

Wednesday, May 29, 2013

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

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

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

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

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

Thursday, April 11, 2013

HITB2013AMS

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

Хочется сказать огромное спасибо моим друзьям, коллегам и близким, без помощи и поддержки которых все это было бы невозможно. Прежде всего Федору и Владимиру, которые наполнили контентом презентацию, снова Федору за ryocrawler, моему коллеге и другу Игорю за тестирование и допиливание рулей SEC-а, моему предыдущему работодателю, работая у которого у меня оставалось время писать и поддерживать update_macs и многие другие штуки (которые, немного спустя реально облегчали мне работу, а следовательно, делали ее более эффективной), здесь пока не доступные, моей супруе и детям, которые весьма терпеливо относились к моим ночным посиделкам в обнимку с ноутом, когда я выпиливал и допиливал proxy_analyzer и материал слайдов презентации, также доступной в GIT.

Несколько слов о структуре GIT-репозитория:
presentation/ - содержит презентацию.
proxy_analyzer/ - содержит скрипт proc_log_v07.pl и всяческие примеры конфигов. Чтобы понять, как там все работает, самое простое - посмотреть код, ничего волшебного там нет.
ryocrawler/ - содержит краулер URL к которому прикручены yara-правила. Соль краулера в том, что он перед тем как применять yara-правила делает деобфускацию java script-а jsunpack-ом.
SEC-rules/ - содержит примеры правил SEC-а, упомянутые (и не упомянутые) в презентации.
update_macs/ - содержит тул для корреляции IDs пользователя (login-ip-mac-switch-port) и отслеживания истории изменений (~ истории перемещений). Проблема этого тула, что он сильно кастомизируется под инфраструктуру => его настройка может занять очень продолжительное время. Другая, не менее важная проблема, что приведенные в update_macs/www/ cgi-ки не лишены всякого рода sqli (о чем я честно заметил в презентации, устно), поэтому используйте их с осторожностью, только с авторизацией.
lab/pcap/ - содержит дамп трафика, упомянутый в презентации.
lab/proc_logs/logs_samples.7z - примеры логов, которые можно попарсить скрптом proc_logs*.pl
lab/proc_logs/run_commands.txt - содержит примеры запуска
lab/proc_logs/proc_log_configs/ - содержит варианты конфигов для лабораторного запуска.
mlogparser/ - оболочка для logparser-а для складывания логов в базу.


Saturday, April 6, 2013

Все будет в Azure

Вот и Microsoft пошел в облака, - теперь фраза "все будет в Ажуре" приобретает смысл чудовищного пророчества.

Tuesday, January 29, 2013

Сертифицированное на несертифицированном, продолжение

В продолжение темы, был оставлен еще один эксперимент (та же версия Деловой почты).
1. Запускаем Деловую почту.
2. Успешно там аутентифицируемся, работаем там.
3. Закрываем деловую почту.
4. Час работаем как обычно.

В результате пп 1-3 процесса WMail.exe в Task Managere нет.

Берем другую утилитку - Windows Memeory Reader и дампим всю память, компьютера.
Опыт показывает, что оба варианта дают результат:
wmr.exe mdump.wmr
или
wmr.exe -p mdump-dd.wmr

Результат традиционно прогоняем через знакомый strings:
strings -n 9 mdump.wmr >mdump.strings
или
strings -n 9 mdump-dd.wmr >mdump-dd.strings

В результирующих файлах *.strings (в обоих) - находим свой пароль!

В целом, очевидно, что С-ная free\delete не очищает память, и претензий не было бы, если бы решение не было сертифицированным! В требованиях явно указано:

"должна осуществляться очистка (обнуление, обезличивание) освобождаемых областей оперативной памяти ЭВМ "

Практически это означает:
1. если я работал с Деловой почтой, а сейчас не работаю, и мой компьютер поимели, есть далеко ненулевая вероятность, что поимели и Деловую почту.
2. если кто-то получил мой файл hiberfil.sys (если я использую спящий режим) или pagefile.sys - там так же можно найти секрет Деловой почты. А раз так, то это вообще делает возможным следующий сценарий:
а) мне попал в руки десктоп, на котором кто-то работал с Деловой почтой.
б) стать на нем админом - вопрос техники.
в) достать пароль в Деловую почту - можно из файла подкачки или файла спящего режима.
г) если человек активно использует Деловую почту, вероятность успеха в) - далеко не нулевая.

В целом, к предыдущим выводам можно добавить:
3. Сама сертификация не подтверждает требования, по которым выполнена сертификация.

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


Monday, January 28, 2013

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

Есть такая компания - Infotecs, у нее есть продукт - VIPNet [Клиент] [Деловая почта]. Суть продукта в том, что он сертифицированным образом защищает конфиденциальную переписку: сообщения шифруются на ГОСТовой криптографии, да и сам продукт имеет сертификат ФСТЭК.

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

Обычно делают так: где-то хранится хеш пароля. Пользователь, аутентифицируясь вводит пароль в какую-то форму, форма его подхватывает, вычисляет хеш, сравнивает с хранимым: совпал - пускает, не совпал - не пускает. Пароль в открытом виде нигде не хранится - это много где требуется, в частности в NIST SP 800-53 (любая ревизия).

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

Проверяем:
1. Запускаем Деловую почту, успешно туда аутентифицируется. В эксперименте используется вот такая версия:

2. Смотрим PID у приложения WMail.exe.
3. Берем утилитку  pmdump.exe и дампим память процесса в файл:
pmdump.exe 5196 WMail.exe-2.pmdump
где 5196 - PID процесса WMail.exe в моем случае.
4. В дампе с ужасом находим свой пароль в открытом виде:
В целом этого достаточно, чтобы понять, что сделать mimikatz для Деловой почты - дело техники.
Если дамп большой, можно облегчить себе работу используя strings:
strings -n 9 WMail.exe-2.pmdump >WMail.exe-2.strings
Результат strings-а можно еще немного обработать, что сократит количество того, что может быть похоже на пароль (известно, что его длина ровно 9 символов, там нет цифр, пробелов, он состоит из начал русских слов, записанных в английской раскладке, используется только нижний регистр):
type WMail.exe-2.strings | proc.pl 1>stdout.txt 2>stderr.txt

Где proc.pl:

my $c=0;
my %r = ();

while(<STDIN>){
    s/^\s+//;s/\s+$//;
    
    if(/^\S+$/ && /^\D+$/ && (length($_)==9) 
        && /^[f,dult`;pbqrkvyjghcnea\[wxio\]sm'.z]+$/ #Russian word
        && $_ == lc($_) #No register
        ){
        print "$_\n";
        $r{$_}++;
        $c++;
    }
}

print STDERR "found $c lines\n";
foreach ( sort {$r{$b} <=> $r{$a}} keys %r){
    print STDERR "$_\t\t".$r{$_}."\n";
}

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


Thursday, January 3, 2013

Заплатки безопасности

Почему-то чем "старше" становлюсь, тем меньше верю в эффективность построения стройной системы управления информационной безопасностью (СУИБ) (подчеркнутое непонятное словосочетание следует понимать как то, что я, придя в поле, решил построить стройную, правильную в соответствии со всеми умными книжками СУИБ и, выполнив все как написано, в результате получил то, что действительно работает хорошо). Хотя, наверно, должно быть наоборот, - посещая какой-нибудь очередной курс про ISO, где обремененный знаниями формулировок слово-в-слово дядька увлеченно рассказывал про великий успех делания всего по стандарту, - я непременно должен  все сильнее и глубже поверить в то, что все дороги уже пройдены и все грабли наступлены, и нам осталось только брать этот набор "лучших практик" и реализовывать, а все беды человечества - от неправильной\неполной реализации требований стандартов. Да простят мне ISOведы и CobIT-о-ITIL-внедрятели.

Почему? Потому что я рассматриваю выходные данные своего operations-а как входные данные для своей СУИБ, в том числе. Поясню: я что-то намониторил, нарасследовал, навыявлял - в результате я получил какой-то "Lessons learned" который, в идеальном случае (а я этого и хочу), должен привести к тому, что вероятный ущерб от подобных инцидентов будет радикально ниже, как и ниже будут мои трудозатраты на возню с такими инцидентами. В целом, я могу не просто что-то ковырнуть в логоанализировалке или как-то поднастроить в фаерволе, я могу и радикально поменять подход к обеспечению безопасности: я могу изменить стратегию - уйти от перевнтивных мер в детективные, а нарушителей увольнять, или наоборот - все запретить и парализовать бизнес, могу вообще ничего не делать, а раз в год нанимать аудит и генерить предписания (при этом всем доказать, что качество моей работы характеризуется количеством выявленных недочетов и размером предписаний).... Я тут распинаюсь только чтобы объяснить одно: результат моего operations может полностью менять мою "СУИБ", ну или генерить массу заплаток на мою СУИБ, бесконечно ее изменяя во времени. Фактически моя СУИБ будет представлять собой набор заплаток, каждая из которых появилась как продукт Lessons learned из разбора какого-либо инцидента\проблемы или совокупности.

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

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

Что такое хороший operations? Мониторинг и аудит. Постройте мониторинг всего, что можно. Начните с периметра. Если с периметром закончили - смотрите все внутри. События коррелируйте и анализируйте, - расследуйте и разбирайтесь с любым что раньше не наблюдалось или что кажется странным - не должно быть в вашей сети, в ваших системах вещей, которые вы (ну конечно же вместе с админами) не можете объяснить. 

Аудит. Если вы уже наделали заплаток (называйте это вашей СУИБ!) - проверяйте что ваши заплатки работают как вы предполагали, что все настроено, как вы хотели, а люди делают правильные вещи правильно. 

Есть ли конец этой инциденто-расследовательно-заплаточной эпопее? Нет, так как безопасность - это процесс - мы вечно будем делать свою СУИБ (PDCA, Деминг и все такое), если хотим, чтобы она была эффективной (effective и efficient).