"Yet another WAF" и безопасность вообще...

Очень понравилось выступление Ивана, как, впрочем, и все остальные его доклады. Несмотря на интро Антона о том, что ожидается "технический хардкор", технотреша не было, а были очень правильные концептуальные вещи, которые применимы не только к WAF или Application Firewall-ам или к любым другим системам безопасности, но и к Безопасности, как процессу вообще, которые было бы полезно понимать не только "волосатым-бородатым-техно-гикам" но "пиджакам", занимающимся построением СУИБ на предприятии.

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

Особо перспективной показалась мысль о необходимости управления атаками, о том, что атаки надо не просто блокировать, а исследовать, поскольку эти данные можно (и нужно!) использовать для построения своей защиты, что для меня вложилось в СУИБ из operations-а. Действительно - абсолютно здравая мысль: если вы, например, Yandex, и ваши сервисы постоянно атакуют - глупо не использовать все эти данные. Зачем устраивать "Bounty программы" или нанимать пентестиров, чтобы вас ломали, если вас и так постоянно ломают? Исследуйте эти "шальные взломы", анализируйте трафик: если вас взломали - понимайте как и адаптируйтесь, если вас не поломали - по крайней мере вы подтвердили какую-то степень эффективности свой безопасности.

Думаю, будет запись, - рекомендую посмотреть.

Безопасность в контексте

И только более чем через 10 лет практики в области ИБ до меня наконец-то дошла основная причина проблем и заблуждений... - исключение из внимания контекста. Ситуация такова, что для разных предприятий необходимое "количество безопасности" будет сильно различаться. Это связано со множеством специфических моментов, начиная от вида основной деятельности, характера и методов обработки информации, и заканчивая корпоративной культурой, деловой этикой и эмоциональной атмосферой в трудовом коллективе (может, когда-нибудь я постараюсь перечислить некоторые моменты, которые в обязательном порядке следует учитывать при оценке контекста). Однако, к сожалению, на практике, большинство безопасников даже не пытаются разобраться в бизнесе, который они защищают, а тупо берут какие-нибудь каталоги контролей/требований, типа ISO, NIST, РД ГТК и т.п. и начинают их внедрять без какой-либо адаптации под контекст. 
Такой подход является основной причиной всех "перегибов", "недоработок" и прочих "парадоксов" безопасности, что, в конечном счете, приводит к необоснованно высокой стоимости ИБ при низкой эффективности и результативности.
Что же делать? Прежде всего - разобраться в бизнес-процессах, которые предполагается защищать, понять окружение и среду.... - понять контекст. Далее - стандартно, как учат в любой книжке/курсе по анализу рисков...
А что насчет этих каталогов контролей? Использовать их без доработки нельзя. Ими можно руководствоваться как некоторым справочником того, что в принципе можно делать, но каждый из выбранных контролей - обязательно адаптировать под контекст.
А как же compliance? Я склонен думать, что compliance - побочный продукт безопасности, т.е. если мы сделаем "безопасность", compliance - получится сам собой - это если мы говорим о compliance, который коррелирует с "безопасностью" в принципе. Если compliance нужен исключительно для самого себя и имеет мало общего с "безопасностью", то здесь еще проще: надо формально выполнить требования в объеме достаточном для их подтверждения установленным способом проверки: т.е. если проверка смотрит исключительно наличие сертификата/аттестата, не вникая глубже, - вплоть до приобретения этого сертификата/аттестата "в переходе метро" :)

Сухой остаток: только контекстозависимая ИБ будет наилучшим образом обоснована экономически и, вместе с тем, максимально эффективной и результативной.

Простой обход контентной фильтрации

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

Пусть у нас есть два файла: 1.7z - архив 7-zip, который очень надо запостить в Интернет, а система контентной фильтрации не пускает; 2.JPG - картинка, которую система контентной фильтрации пускает, однако постить конкретно ее в Интернет нет необходимости.

Проблема решается с помощью команды cat. 
c:\>cat 2.JPG 1.7z >3.JPG

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

Однако, если этот 3.JPG переименовать в 3.7z, последний прекрасно откроется архиватором... 

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

Осторожно, серпантин или особенность систем BigData.

Elasticsearch - замечательный продукт, который дарит нам не только удовольствие от пользования качественным ПО, но и ощущение скоростной езды по горной дороге. Вираж, запрос - ответ. Перевал, фильтр - выборка
А скорость?! В mysql выборка по одной учетной записи за сутки, с целью посчитать с каких же сайтов человек накачал больше всего байтов занимало 30-40 секунд. А тут суточная выборка по всем сотрудникам, с определением байтового ТОРа и пяток других запросов выполняются менее чем за секунду! Вот оно "счастие аналитика".
Но не все на СТОЛЬКО хорошо. Особенностью работы с большими данными, а ES позиционирует себя как продукт для обработки больших массивов информации, является снижение точности.
Давайте не будем падать в дебри 100% корректного описания внутренней кухни ES, а упростим описание в угоду пониманию. Кому нужны детали, добро пожаловать на сайт производителя. Все-равно лучше его не скажешь.
Итак. ES видит много-много (именно "много", а не 1478) запросов от пользователя Иванов на сайт www.ru. Все запросы примерно одинаковы (положим javasctipt резвится) и более-менее регулярны.
И тут, неожиданно для всех, аналитик Петров спрашивает - скажи ка мне, дорогой Elastic, а сколько раз сотрудник Иванов обращался к сайту www.ru. У ES нет времени на раздумья, ведь главное ответить быстро, чтобы Петров не успел забыть вопрос. Поэтому ES смотрит, что Иванов обращался к www.ru в 1й, 10й и 20 часы примерно 60 раз в час, значит за сутки он сделал около 1440 обращений. Эта цифра и летит на экран. Примерно 1440, нужно держать в голове аналитику Петрову.
Хорошо, отвечает ошалевший от скорости ответа Петров, а сколько байтов сотрудник Иванов выдернул с сайта www.ru? И практически мгновенно получает ответ 288000. Замечательно! Тем более, что это почти соответствует точной цифре, то есть примерно 288000. А ES просто умножил 1440 на средний размер ответа сервера равный 200 байтам, который опять рассчитал по быстрому.
Все довольны, Петров отходит ко сну. Занавес.
"Да ладно", скажете вы, "выдумываешь тут какую-то чушь! Я по калькулятору считал. Байты почти сошлись".
"Здорово", отвечу я, "только не всегда прогнозы и усреднения оказываются верными". Посмотрите на картинку ниже.

Утренний анализ за чашечкой кофе показал, что пользователь serg вытянул из Интернета за последние сутки примерно 221 мегабайт. Ну-ка глянем, чего это он вчера был таким вялым?

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

Анализ журналов прокси. Продолжение

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

Классика:«кто больше съел»
Тут все просто. В панели «Down by user» (это не оскорбление. слово download не влезло в панель) выбираем верхних пользователей, щелкаем на изображении лупы и анализируем

Причем, что удобно, мы на одном экране видим:

1. Человечек смотрел видео с youtube;
2. Человечек начал это делать в обед (12-13);
3. Человечек не смог остановиться, когда обед закончился.

Можно проанализировать, что он смотрел, сопоставить это с журналами работы с информационными ресурсами, но этим сегодня заниматься не будем. Классика!
Классика «слабое звено»

Допустим, мы хотим посмотреть, кто ищет себе работу? Добавляем запрос «urihost: *job* or *rabota* or hh.ru» и наблюдаем кандидатов на анализ. Благодаря панели «Upload max» можно даже отловить момент выкладывания резюме.

В момент написания поста ничего интересного не происходило, поэтому просто посмотрите, что в обед люди не только отдыхают, но и занимаются серфингом по сайтам навевающим грусть на HR.
Стандартный «кто послал»
Вы, наверное, уже обратили внимание на панельку «Upload max» справа от панели запросов. Эта панель показывает размеры индивидуальных отправок данных через прокси-сервер. То есть на ней визуально мы можем выявить нарушения связанные с отправкой наружу информации. Таблично это делать не очень удобно
Смотрим, как у нас дела были в последние 12 часов.

Ага, видим 12 мегабайтную отправку. Уменьшаем время, за которое проводится анализ, так как количество событий в секунду превышает 50.

Уточняем. Фильтруем по пользователю и затем по имени сайта

И вот мы видим, кто отправил информацию и куда. К счастью это штатная отправка на сайт закупок, на анализ которой потребовалось несколько секунд.
Стандартный «масс-контакт»
Случилось некоторое время назад такое, что корпорация добра несколько усовершенствовала свой браузер, в результате чего в нем как-то особенно выделился функционал чата. В результате на прокси обрушился шквал запросов на соединение с IM-сервером, которые отклонялись. Это не есть хорошо.
Чтобы продемонстрировать работу по анализу, пришлось отключить фильтрацию отклоненных запросов (TCP_DENIED). В результате наблюдаем сайт требующий нашего внимания – urs.microsoft.com. Он не связан с IM, описанным в предыдущем абзаце, но для примера пойдет.

Продвинутый «ratio»К сожалению, такой вид анализа на ELK мне пока не удалось реализовать. Его идея в том, чтобы делать расчет соотношения информации отправленной на сайт к принятой. Этот способ анализа позволяет выявлять туннели и сайты-интерфейсы к IM, например. Делается все на сегодня запросом из SQL, где журналы так же хранятся. Нужно сохранить немного брутальности.
Продвинутый «reputation»
Это из раздела помечтать. Идея – дергать из репутационных баз информацию о доверии сайтам и выводить информацию на экран анализа. Идея навеяна плагином WOT для браузеров.

Буду рад, если коллективный разум подскажет, как реализовать продвинутые способы анализа или предложит свои идеи. Что смогу реализую и опишу.

Анализ журналов прокси

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

---

select id, from_unixtime(time), r_host, inet_ntoa(r_ip), r_port, sum(sc_bytes) from proxylog where time > (UNIX_TIMESTAMP() - 86400*2) and cs_username like 'ХХХ' group by r_host order by sum(sc_bytes);

---

Используя его, мы можем быть уверенными, что анализ журналов не сможет сделать никто кроме нас. Это по-своему круто и дает нам определенный авторитет.
Но давайте повернемся лицом к коллегам и используем стандартную на сегодня связку Logstash-Elasticsearch-Kibana (ELK в английском просторечии) для анализа журналов. Вероятно, есть более оптимальные решения, но они потребуют больше времени на настройку и тюнинг. Итак…


ELK мне было удобно поставить на Debian. Правильный "Debian way" описан на этой страничке.

Squid:
Журналы Squid падают в Logstash. Способы выбирайте сами, они описаны во многих местах.
Пара особенностей. По подсказке коллеги из головной конторы, в журнал был добавлен заголовок referrer, а по моей инициативе - количество отправленных байт. В результате директива logformat выглядит так:

---

%ts.%03tu %6tr %>a %Ss/%03>Hs %<st %rm %ru %un %Sh/%<A %mt %>st %{Referer}>h

---

Logstash:
Чтобы падающие сообщения были нормализованы, то есть из потока символов была извлечена информация, используем вот такую конструкцию:

---

…
else if [message] =~ "(squid)" {
mutate { replace => { "type" => "squid-access" } }
grok {
match => ["message", "<14>%{SYSLOGTIMESTAMP}\s+%{SYSLOGHOST:sourcehost}\s+\(%{WORD:syslogprog}\):\s+%{NUMBER:timestamp}\s+%{NUMBER:request_msec}\s+%{IPORHOST:client}\s+%{WORD:cache_result}/%{NUMBER:status}\s+%{NUMBER:size:int}\s+%{WORD:http_type}\s+(%{URIPROTO}://)?(?:%{USER}(?::[^@]*)?@)?(?:%{URIHOST:urihost})?(?:%{URIPATHPARAM})?\s+(%{WORD:username}|-)\s+%{WORD:request_route}/(%{IPORHOST:forwarded_to}|-)\s+%{NOTSPACE:content_type}
\s+%{NUMBER:send_size:int}\s+(%{URI:referer}|-)"]
}
}
…

---

Тут и мне, написавшему этот жуткий regexp, мало что понятно с ходу, но когда будете настраивать logstash разберетесь что к чему - выбора не будет.
ElasticSearch:
Прелесть этой "не базы данных" в том, что все в ней хранится как-то. Поля, индексы, типы - все это появится в момент, когда вы решите заняться оптимизацией или добиться каких-то расширенных возможностей. Что происходит внутри связки ELK нам не важно. На вход мы подаем поток текста, на выходе получаем "кузявые" таблички и графики.
Kibana:
Статей по настройке интерфейса Kibana великое множество. Мне показалось, что эффективнее всего ставить себе какую-то задачу и искать механизм реализации задачи в ограничениях данного нам средства.
В результате для анализа журналов прокси сервера получился такой интерфейс

Панельки пришлось сделать поменьше, чтобы они все помещались на монитор одновременно. Поэтому по всем параметрам показывает TOP5. Чаще всего этого достаточно. Больше чем на 1-2 "нарушителей" в день нет времени.
Схему можно скачать здесь.

Основные способы применения решения рассмотрим в следующий раз.

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

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

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