Sunday, April 1, 2018

Сила действия равна противодействию

...во многой мудрости много печали; и кто умножает познания, умножает скорбь
(Екк. 1:18)
Сумасшедшим жить легко
(Пилот)


Я неплохо учился в институте, отчего остались различные приятные артефакты, позволяющие с улыбкой вспомнить прошедшее счастливое студенчество, поностальгировать... Однако, как бы это не странно звучало, весьма неплохие знания по предмету, отнюдь не позволяли мне просто и быстро сдавать экзамены и зачеты по ряду дисциплин. Экзамены у Алексея Евгеньевича я сдавал долго, так как по мере решения задачек, со словами что-то типа: "О, вы и это знаете?!", он давал новые, более сложные... Несмотря на кажущуюся нелогичность подхода, он абсолютно правильный: с ответственных больше спрос, а мучить нечего не знающего смысла никакого нет.
Другим воспоминанием из детства является выбор вида спорта после окончания музыкальной школы. Тогда мне казалось, что привлекательным была бы какая-то борьба, что позволит улучшить навыки самозащиты и защиты всего остального, что я считаю важным. Отец был против, аргументируя это тем, что если ты не профессиональный боец, тебя просто выключат, и быстрая потеря сознания, возможно, спасет тебе жизнь, однако, если ты будешь пытаться эффективно сопротивляться, тебя точно убьют. Мне искренне близка и сейчас мораль наших предков викингов, о том что лучшая смерть для мужчины - на поле боя, но в итоге я был отправлен на плавание...

Этот же принцип работает и в корпоративной защите. Атакующий всегда будет действовать по пути наименьшего сопротивления, с наименьшими затратами для себя. Нет никакого смысла применять сложные техники и разрабатывать продвинутый инструментарий для компании с низким уровнем ИБ. Напротив, для зрелого в части ИБ предприятия, атака будет сложной. Практически наверняка первичная компрометация закончится успехом, первоначальная мотивация заставит ребят возвращаться к вам снова и снова, а расследование инцидентов займет основную роль в вашем SecOps. Чем более продвинутой будет атака, тем сложнее будет ее обнаружить и остановить. Может сложиться так, что обнаружить атакующего можно будет только если он допустит ошибку, но, если он достаточно профессионален, вероятность, что он ошибется - невелика.
Получается, что совершенствуя защитные механизмы, мы провоцируем появление атак, которые сами же не сможем обнаружить. Если бы мы вообще ничего не делали по ИБ, нас бы примитивно ломали, что давало бы нам, в свою очередь, не напрягаясь справляться с этими взломами.
В этом случае весь SecOps можно свести к быстрому восстановлению (помните жидкого терминатора и как он здорово ожил потом). Только если уровень безопасности у нас низкий, то и атаки на нас будут простые, а поэтому расследовать и реагировать на них просто (== дешевле), так как проще решить много маленьких задачек, чем одну большую. Получаем, что помимо того. что мы вовсе не тратимся на безопасность, мы имеем еще дешевый респонс.

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

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

Tuesday, March 27, 2018

Функциональная и географическая этапность

Divide et impera! (лат)

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

Проблематика тривиальна. Если вы разрабатываете и внедряете сложную систему, то логично этот процесс построить так, чтобы эффект появился как можно быстрее и насколько возможно больший. Я верю в принцип Парето, поскольку ни раз сталкивался с его подтверждениями на практике. Исходя из него, вполне можно выделить 20% функционала системы, который даст 80% успеха. А раз так, пускай этот первичный набор "quick win-ов" и будет вашим первым функциональным этапом.
На второй функциональный этап можно отнести то, что не вошло в первый этап. Вроде бы тоже очень важные функции, но реализация их дорога и/или долга, т.е. это не будет "quick", или же, эффект от внедрения этих функций не будет столь искрометным по сравнению с другими, т.е. они не представляют собой "win".
Помня о том, что совершенство - недостижимо и можно вечно потчевать свой перфекционизм, мы получаем некоторую операционную историю постоянного совершенствования. Сюда же попадает развитие продукта, адресующее изменения в конъюнктуре рынка, вызовы времени и пр. факторы, требующие от продукта продолжать решать поставленные перед ним задачи с наилучшими показателями effectiveness и efficiency не смотря ни на что. Все это, и многое другое, включая плохо просматривающиеся, плохо понимаемые фичи, суть которых станет очевидней после появления практики использования функционала первых двух этапов, - можно отнести на третий этап, практически бесшовно переходящий в Operations.

Аналогичный подход можно применить и в географическом отношении, если вам надо внедрить проект во многих сотнях предприятий, расположенных во многих десятках регионах страны и Мира. Пусть первым этапом будут Пилоты - предприятия/регионы на которых можно собрать все возможные грабли и шишки с минимальными рисками. Скорее всего, внедрение вашей системы на предприятии будет отличаться в зависимости от особенностей предприятия (его технологической инфраструктуры, зрелости operations и т.п.). Поэтому, обычно выделяют "типовые площадки", отражающие все возможные сценарии внедрения/интеграции. Важно, чтобы в этап Пилотов попали площадки каждого типа.
Если в корпорации много дочерних предприятий, то, скорее всего, есть некий рейтинг, составленный по важным для бизнеса корпорации критериям. Это может быть прибыль, имидж, стратегический приоритет - да что угодно, важно, что сливками этого рейтинга являются Ключевые предприятия. Собрав все шишки на Пилотах и тем самым отработав порядок внедрения, можно рассматривать внедрение на Ключевых предприятиях следующим этапом, поскольку окучив их можно получить наибольший эффект от проекта в масштабах всей корпорации. Важно, однако, понимать, что характер разрабатываемой и внедряемой системы может определять внедрение на каких предприятиях даст больший корпоративный эффект. Поэтому, может сложиться так, что вторым приоритетом после Пилотов пойдут и не ключевые предприятия, но это как раз и есть тот самый контекст корпорации, с которым должна работать проектная команда, добиваясь как можно большего эффекта как можно скорее.
Отработав проблемы на Пилотах и добившись наибольшего корпоративного успеха на ключевых (или максимально релевантных проекту) предприятиях, оставшиеся предприятия - третий географический этап.

Имея функциональные и географические этапы, проект можно организовать как представлено на рисунке, выполняя параллельно работы по разным направлениям в разных географических локациях.
Что изображено на картинке?
I. Внедрение функционала первого приоритета в пилотных регионах/предприятиях.
II. Тираж функционала первого приоритета на Ключевые регионы/предприятия
III. Внедрение функционала второго приоритета там где, внедрен первичный. В остальных регионах/предприятиях – тираж функционала первого приоритета.
IV. В пилотных регионах/предприятиях – внедрение остального функционала. В остальных регионах – тираж функционала второго приоритета
V. Тираж остального функционала во всех оставшихся регионах

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

Thursday, March 15, 2018

Время материализовать облака

Мы рождены, чтоб сказку сделать былью
("Марш авиаторов", Герман-Хайт)

Спешите порадоваться спуску с горы, ибо далее придется тащить на себе санки
(Личный опыт из детства)

Абстрагируемся на время чтения этой заметки от того, что любая автоматизация всегда ведет к увеличению операционных затрат, - как бы там ни было, автоматизация - явление правильное и полезное, выводящее наши процессы на новый уровень. Разумно желание концентрироваться на основном бизнесе и не отвлекаться на различные инфраструктурные задачи, которые, собственно, и ведут к увеличению OpEx-ов, снижение которых - подтверждение эффективности разрабатываемых и обеспечиваемых нами бизнес-процессов. Однако, История держит свой путь по спирали и, несмотря на необратимость времени, мы с синусоидальной периодичностью приходим все в те же ситуации, то отвергая, то принимая вновь уже ранее обдуманные понцепты: железным инфраструктурам пришли на смену облачные, затем - гибридные, и сейчас мы становимся свидетелями балканизации, что снова нас возвращает к полностью on premise решениям, но уже на новом витке времени и понимания причин.

По моему субъективному мнению (лишний раз отмечу, что все статьи этого блога заключают в себе исключительно субъективное мнение) текущая кристаллизация on-prem из облаков создает удобную тенденцию создания хороших корпоративных продуктов из решений, ранее доступных только из облака. Посудите сами: огромная часть продуктовой инфраструктуры скрыта от глаз потребителя в облаке, что позволяет экономить на целом ряде вещей, малозначительных с точки зрения функционала, но принципиальных для on-prem решений: пользовательских интерфейсах, оптимизации аппаратных мощностей, алгоритмах обработки данных... - в целом, облачное решение даже может быть менее зрелым в функциональном плане, и все его недостатки могут быть скомпенсированы архитектурой бизнес-процессов, избытком инфраструктуры, дополнительными расходами на обслуживание. Говоря проще, - если интерфейс неудобный и требуется больше времени на решение каких-то задач - это можно скомпенсировать увеличенным количеством людей, если решение нестабильно - это можно скомпенсировать как многократным резервированием, так и усиленной ИТ-поддержкой, если код плохо оптимизирован - можно взять мощнее железо и т.д. Кроме того, в облаке можно делать полноценный Agile разработки - функционал можно расширять максимально быстро, так как связанные с этим риски можно временно скомпенсировать теми же немного завышенными расходами на людей и железо. И вот уже когда решение в облаке достигло требуемой зрелости, его можно материализовать в коробочный продукт, отвязанный от инфраструктуры вендора. Собрав все шишки и грабли в облаке, уже можно построить стабильное, красивое, удобное решение on premise, воплотившее в себе весь опыт облачного использования, решение, основанное на практике, обкатанное в "боевых" условиях. При этом, облачная инфраструктура по-прежнему останется логичной исследовательско-тестовой лабораторией для нового функционала on-prem решения, где все по тому же сценарию вызревшие в облачной эксплуатации фичи можно с минимальными рисками переносить в изолированные корпоративные инфраструктуры.

Обратный путь, - от on-prem к облаку, - нелогичен, так как несравненно сложнее, поскольку на первом же этапе надо обеспечить стабильность на миллионе комбинаций возможных инфраструктур Заказчика, с непредсказуемым operations и квалификацией персонала, более того, эти сложнейшие инфраструктурные проблемы не позволят как следует сконцентрироваться на функционале, отнеся эти, с точки зрения конечного потребителя, более важные задачи на второй план (действительно, когда там думать об удобстве пользования лопатой, если она рассыпается как только пользователь берет ее в руки!)... Поэтому правильным стратегическим решением сейчас может быть инвестирование в продуктивизацию до состояния качественного on-prem ранее исключительно облачных предложений со всеми сопутствующими артефактами успеха: обучением, документацией, сервисом продуктовой поддержки и поддержки на уровне бизнес-логики, а также процессами создания, отработки/вызревания нового функционала в облаке с последующим переносом его в изолированные корпоративные инфраструктуры. Спешите "оседлать" балканизацию, быть может, скоро спираль Истории изменит свое направление и вместо спуска по синусоиде, придется карабкаться в нее...

Saturday, February 3, 2018

Антивирусы и Песочницы

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

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

Anti-malware (АМ) движки - напротив, представляют собой реальную среду исполнения ВПО и поэтому дают максимально достоверные сведения об исполнении ПО в фактическом окружении. Реальные рабочие станции предоставляют более достоверную информацию для анализа. Но, поскольку реальные системы должны выполнять реальные задачи, а не функцию исследовательской инфраструктуры, возможно наличие ресурсных ограничений, не позволяющих "дотянуться" до всех интересующих компонентов. Ну и, конечно, ни о каких нестабильных перехватах речи идти не может.

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

Thursday, January 25, 2018

Истина по косвенным признакам

По плодам их узнаете их
(Матф.7:16)

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

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

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

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

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





Saturday, January 13, 2018

Пробы

Вероятно оттого, что много лет своей практики я потратил на сетевой мониторинг, я верю в IDS, И после того, как они стали вытесняться IPS, и сейчас, когда пропали и последние, войдя в понятия NG-FW, WAF, App-level-FW и т.п.

Аргументы, которыми маркетанты препарируют IDS не состоятельны так же, как не состоятельна и вера в абсолютную эффективность превентивных средств защиты, поскольку у них есть, как минимум, одна большая проблема: если вероятность фолсы (false positive) более 0% существует риск остановить продуктивный сервис, и в этом случае ущерб возможен выше, чем от пропуска атаки (false negative). Поддерживая концепцию эшелонирования подходов: 1) предотвратить, 2) если нельзя - обнаружить, 3) если нельзя - искать и находить, - получаем, что наличие IPS не отменяет необходимости IDS (в общем-то, они обе нужны), тем более не отменяет необходимость IDS наличие *-FW или любой другой пакетной фильтрации (понятно, что технически это может быть как угодно: IDS на RSPAN-е, IPS в разрыве или *-FW с активированными не только блокирующими правилами, но детектирующими (как раз для сбора информации, фингерпринтинга хостов в сети и фолсящих сигнатур, - сюда же всякие ML - не думаю, что кто-то доверит ML\DL что-либо блокировать автоматически)  - это не предмет данной заметки). При генерации грамотных логов, IDS можно использовать и для Threat hunting-а, так как доступна, как минимум, следующая информация:

  • пассивный фингерпринтинг хостов в сети (версии ОС, версии приложений, известные уязвимости), 
  • по каким протоколам трафик ходит между какими хостами в каком объеме, поскольку разбирается трафик приложений, IDS может видеть пересылаемые файлы (некоторые могут эти файлы выкусывать и складывать),
  • всевозможные аномалии: 
    • отклонения от RFC, 
    • потери пакетов и обращения к несуществующим адресам или закрытым портам - пробы (причем, с контекстом: соединение отвалилось по таймауту, прилетел RST или ICMP unreachable), 
    • всевозможные сканирования (причем, нормальная IDS будет определять тип сканирования и в некоторых случаях сканер), бруты, фаззинги,
  • пролетающие по сети эксплоиты и нагрузки, в общем случае - все сетевые атаки.
Если даже у вас заблокирован доступ в подсеть, согласитесь, полезно знать кто туда хотел, но не смог, попасть по каким портам - отличный повод с этим поразбираться. Если на какой-то хост вы вдруг стали наблюдать кучу проб, это может означать, что на нем отъехала служба или до нее пропала сетевая доступность, Любопытно видеть попытки подключения к несуществующим хостам или закрытым портам... Тем более интересно видеть попытки отправить туда эксплоит. 

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

"Шумность" IDS хорошо профилируется (можете называть это ML, но я о статистике - любой современный SIEM это умеет), поэтому обращать внимание в общем случае нужно на отклонения. Все остальные события (aka "шум") будут крайне полезны при сетевой форенсике, расследовании инцидента.


Sunday, December 3, 2017

Аккумуляция опыта или боты на последней линии

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

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