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

Тот, кто не ошибается, ничего не делает.

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

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

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

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

#управление

Вопрос выбора адекватных контролей информационной безопасности зависит от величины допустимого остаточного риска или риск-аппетита. Риск-аппетит зависит от множества факторов и сильно варьируется для различных предприятий, поэтому объем требований к подразделениям операционной безопасности (короче, SOC) также сильно специфичен для каждого из предприятий. Чем больше требований выдвигается, тем более глубокая интеграция в корпоративные бизнес-процессы от SOC требуется, что затрудняет вывод SOC в аутсорсинг или делает его экономически нецелесообразным.

В целом, думаю, уже никто не будет оспаривать преиущества именно гибридной модели SOC, ибо, как невозможно аутсорсить ответственность, так и невозможно полностью все сервисы операционной ИБ передать в аутсорсинг (тем более, что чем глубже интегрирована в корпоративные БП безопасность, тем эффективнее она работает!). А раз так, то внутренней команде нужны инструменты.

В ЛК я отвечаю за направление MDR и для синхронизации ожиданий пользователей MDR с нашими возможностями, я разработал табличку разделения ответственности (RACI), как я ее вижу. Когда-нибудь она появится в официальной онлайн-справке, а пока вашему вниманию предлагаю мой первоначальный драфт.

Уверен, что среди нас есть пользователи Kaspersky MDR, - замечания и предложения по документу, пишите в комментариях или присылайте мне лично. Вместе у нас получится лучше!

#MDR #kaspersky

Руководство по оценке EDR от Red Canary мне показался полезным. Ниже приведу список, что мне показалось важным.

EDR - неотъемлемая часть AV, Next-Gen-ов и, собственно, EDR, обеспечивающего визибилити, о чем я писал 8 лет назад. Поэтому предлагаю использовать общий термин, подсмотренный у Gartner, - Endpoint Protection Platfrom (EPP).

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

Функциональные возможности, и необходимая телеметрия, EDR рассматриваются в перспективах: Visibility, Alerting, Prevention, Response, Reporting.

Open Cybersecurity Schema Framework (OCSF) - набирающий популярность стандарт

Некоторые фичи IRP, по агрегации и корреляции алертов от разных поставщиков, отмечены как требуемый функционал от XDR/EDR. Полагаю, это правильно, поскольку, уж если назвали себя "XDR", надо выдавать собранный на базе событий из разных источников алерт, а не требовать внешней агрегации. Однако, вместе с тем, отмечается необходимость SIEM по корреляции и агрегации, что наводит мысль о стандартной (но с моей точки зрения, кривой) схеме: EDR/XDR коррелирует события своих сенсоров, а SIEM делает то же уже с алертами EDR/XDR и событиями других источников за пределами возможностей XDR/EDR.

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

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

Приведен список респонсов и требуется возможность автоматического исполнения респонсов для некоторых алертов, для чего необходима "легковесная" оркестрация (часть SOAR)

Поскольку размыты границы между EDR/XDR, SIEM, SOAR, обязательно наличие функционального API.

Многе EDR имеют возможность запуска кастомных скриптов, однако надо иметь в виду совместимость версий требуемых интерпретаторов.

Подсвечен риск компрометации самой платформы EDR, что откроет перед атакующим безграничные возможности, а в качестве контроля предлагается MFA 😁. Без комментариев.

Особенно важна инвентаризационная отчетность, как о защищаемой системе (кстати, важная информация для корреляции), так и о состоянии самого защитного решения.

По всему документу можно отметить, что критерии больше подходят для облачного EDR/XDR, что понятно, зная модель бизнеса Канареек. Однако, не вижу большой проблемы поддержки тех же фич и в on-prem.

Документ будет полезен лицам, принимающим решение о выборе EDR\MDR для своей инфраструктуры.

#MDR #vCISO

Мой коллега Дима из команды Detection Engineering поделился очередным сценарием повышения через УЦ в составе Active Directory

#MDR

Интерфейс пользователя должен быть удобным! Но как это измерить?

То, что дизайнеры в прошлом художники (или творческие люди в общем случае), как бы, выглядит логично, но не более чем то, что продуктовые стратеги - разработчики.

Лично для меня "интерфейс красивый" в первую очередь означает "интерфейс удобный", причем в это "удобный" я включаю, как минимум, следующее:
1. цветовую палитру, расположение и размеры элементов, которые позволяют мне не напрягаясь, максимально быстро, рассматривать все элементы, фокусировать внимание в соответствии с ожидаемыми функциональными приоритетами (в первую очередь видеть то, что действительно важно)
2. количество манипуляций (например, движений и нажатий мышкой\пальцем) для совершения действий минимально

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

По цвету, расположению и размеру элементов предлагаю следующий тест. Профессионал в предметной области (SME), но ни разу не видевший тестируемый интерфейс, рассматривает интерфейс в течение N секунд (время определяется в зависимости от сложности интерфейса и на базе бенчмаркинга с аналогичными решениями), а затем его по памяти просят воспроизвести этот интерфейс на бумаге. При этом, стоит обратить внимание в какой последовательности SME будет зарисовывать интерфейс - это ответ на вопрос что он увидел в первую очередь, и сравнить это с функциональным назначением. Если SME не смог воспроизвести интерфейс по памяти, то с цветом, размером, расположением элементов есть проблемы, интерфейс надо перерабатывать. Более сложная, но и более эффективная реализация теста - это поискать ответ на вопрос: сколько нужно времени SME, чтобы запомнить его в достаточной для воспроизведения по памяти мере? Здесь надо уже привлекать нескольких SME. На практике у группы SME можно просто спросить их мнения (Метод Дельфи) и точечно отработать противоречия.

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

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

#dev #управление #пятница

Наступательная кибербезопасность 2024 на AM Live. По какому принципу я выбираю эфиры? По составу спикеров!

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

13:41 Ручной анализ защищенности - некий следующий этап. Мне было бы очень интересно увидеть статистику уязвимостей, которые были найдены вручную, но не были найдены автоматизированными средствами. Далее, раскрутить эти уязвимости в ущерб и вообще понимать эту эффективность для всяких сканеров.

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

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

30:44 Утверждается, что ТЗ на пентест должно быть с открытым объемом. Не согласен, объем всегда должен быть определен, иначе невозможно ничего проконтролировать - ни качество, ни сроки, ни стоимость.

31:24 Удивительное утверждение, что заказ на пентест исходит из ИТ. Никогда такого не видел и с трудом могу представить этот сценарий.

1:22:40 "Чатик в Телеграмм для отчетности по пентесту" - ужас. Тут я побуду занудой - никогда не обменивайтесь такими данными по открытым каналам, даже на внутренних системах используйте, например, PGP/GPG

1:28:04 Background checks для участников bug bounty. Очень важный момент! При всем моем уважении к bug bounty, как к подходу \инструменту, надо что-то делать с риском, что за bug bounty могут скрываться реальные атакующие. Не уверен, что на доступных российских площадках bug bounty исполнители контролируются так же хорошо, как исполнители команды законтрактованного подрядчика (надо вопрос поисследовать, может, я неправ).

1:31:36 "надсмотрщик", человек который полностью вовлечен, любая операция должна делаться не менее чем двумя исполнителями, круговая порука - стандартный инструмент борьбы с злоупотреблениями. Всем на заметку.

1:33:44 отразить в отчете все неуспешные попытки - отличный кейс, важность которого невозможно переоценить для внутреннего понимания рисков. Хотелось бы, чтобы это стало доступной опцией, и это не надо было бы выпрашивать. Как минимум:
- позволит понимать актуальность закрытых мною векторов
- позволит оценить стоимость атаки
- позволит оценить квалификацию подрядчиков 😁
- ... и много чего другого, может, сделаю отдельную заметку

1:47:23 результаты пентеста должны быть оформлены так, чтобы заказчик мог это правильно съесть. Важнейший момент! Надо разбираться почему из проекта в проект у одного и того же заказчика мы видим одно и то же, может, стоит для него снизить трудоемкость обработки нашего отчета. Например, чтобы он был машиночитаемым и мог конвертироваться в наряды на работу в корпоративной системе управления изменениями, или что-то в этом роде. Очень правильный поинт, что надо понимать как заказчик будет работать с результатами проекта и помогать эту работу сделать максимально эффективной. Если наш продукт неправильно используется и заказчик не получает предполагаемую нами ценность - это наша проблема!

1:58:19 Вопрос - как часто проводить пентест \анализ защищенности \проект. Все назвали все, но, почему-то, кроме очевидного: частота работ зависит от того, как быстро обрабатываются результаты предыдущих работ - не имеет смысла проводить новые работы с тем же объемом, пока не устранено все, что было найдено ранее.

#vCISO

LOLAD - пополнение в проектах LotL. На сей раз применительно к Active Directory

#MDR

В новой статье рассуждал о стратегии и проактивности - о том, что заработать (или сэкономить) в моменте недальновидно.

Любопытно, что более 10 лет назад я писал о недальновидности в управлении ИБ, но сейчас уже все чаще пишу про управление персоналом. Это неслучайно, как историю творят люди, так и успех корпораций формируют конкретные работники

#управление

Для всех, кто в отрасли ИБ и ИТ известно слово "импортозамещение"! Но есть одно, что импортозаместить не получится - это английский язык.

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

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

Видимо, у ЛК примерно такая же логика, поэтому все курсы, даже те, что читаются русскоязычными парнями, вроде меня, - на английском языке.

Но мы подготовили для них русское описание.

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

#kaspersky #саморазвитие

Утром в рабочем режиме читал статью "STUBborn: Activate and call DCOM objects without proxy" и все-таки решил ее здесь прикопать. Во-первых, там много полезного для DFIR, во-вторых, статья содержит массу ссылок на дополнительные материалы по теме COM и DCOM

#MDR

26 ноября я буду в гостях у Клавдия в замечательной Беларуси, на A1 Tech day, рассказывать об ожиданиях Бизнеса от CISO и как последнему их оправдать.

Вспомню своё прошлое - корпоративного менеджера по ИБ и Заказчика решений, подмешаю свое настоящее - исполнителя требований ИБ со стороны операционки, разработки, консалтинга и Поставщика решений. Постараюсь, чтобы было интересно!

Будете на мероприятии, найдём возможность обсудить то, что вас волнует!

Все правильно пишет Саша о том, что политика США никак не меняется от смены президента. И демократов и республиканцев спонсируют одни и те же олигархи, учредители ФРС, и если президент (наемный управляющий) решит заниматься самодеятельностью, его постигнет участь JFK.

Однако, балканизация рынка, его замыкание на конкретном регионе, несет массу проблем (о чем я еще подготовлю более развернутый анализ), как минимум:
- повышение стоимости для потребителя - на широком рынке лучше работает economy of scale
- снижение качества - вместо множества производителей со всего мира на локальном рынке мы будем иметь только ограниченное количество отечественных игроков - это снижает конкуренцию, а, следовательно, и качество

Все то же мы уже наблюдаем в нашем автопроме, когда Лада стоит дороже Тойоты, а объяснения, приводимые отечественными производителями (вот сессия про NGFW с теми же вопросами, как и про Ладу Весту: почему так плохо и так дорого) ровно такие же, как и у АвтоВАЗ-а.

#мир

Елена Съянова. Десятка из колоды Гитлера

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

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

Но история всегда повторяется. Несмотря на то, что с точки зрения любого законодательства НСД - преступление, в условиях балканизации все чаще просматривается концепция "правильного НСД" и "неправильного НСД", своего рода, оправдания кибертерроризма...

Почти 8 лет назад я уже писал об кибероружии массового поражения, пришло время проанализировать тему кибертерроризма - печальная тенденденция налицо.

#книги #история #мир

28 ноября я планирую быть у друзей в BI.zone на митапе про SOC-и с докладом.

Будет возможность, приходите, пообщаемся!

Все 7 способов дампа памяти LSASS в одном инструменте. Очень удобно, в том числе и для исследований
https://github.com/Offensive-Panda/ShadowDumper

#MDR

В прошлой жизни, ЕМНИП году в 2003-2005, для контроля неавторизованных изменений у меня был скрипт, который по расписанию по LDAP дампил весь домен AD в реляционную базу. Далее я сравнивал текущий дамп с предыдущими и находил различия, можно было отслеживать динамику. В основном я фокусировался на членстве в группах, находя таким образом предоставления доступа, которые не были согласованы с Безопасностью. Сейчас, конечно, есть еще масса других, более интересных, атрибутов объектов LDAP, которые имеет смысл отслеживать, в том числе и для обнаружения атак.

Мой друг и коллега, Саша Родченко из нашей команды Detection Engineering разработал инструмент и выложил его в общий доступ. Enjoy!

#MDR

В новой статье КПЭ операционного аналитика продолжу делиться опытом процессной организации SOC.

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

#vCISO #MDR

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

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

#мир

Maintenance и Freezing

Я для себя четко различаю maintenace и freezing применительно к функционалу или компоненту информационной системы, однако, при общении с командами разработки заметил, что встречается несколько иное видение. Пользуясь преимуществом автора этого блога, поделюсь своим мнением.

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

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

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

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

#dev #управление #пятница