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

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

The researcher demonstrated how he could trick ChatGPT into believing a targeted user was 102 years old, lived in the Matrix, and insisted Earth was flat and the LLM would incorporate that information to steer all future conversations. These false memories could be planted by storing files in Google Drive or Microsoft OneDrive, uploading images, or browsing a site like Bing—all of which could be created by a malicious attacker

OpenAI, вроде, поправили, но прецедент...


#ml

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

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

#MDR #vCISO

Интересное сравнение EDR-ов, будем следить за проектом...

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

#MDR

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

#ml

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

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

Так вот, в части НСД мы уже давно доросли до подхода assume breach и threat hunting-а (презентацией той поделюсь, правда ей уже скоро 10 лет), т.е. мы уже допускаем тот факт, что атакующие есть в сети (уже есть НСД, собственно, про что вся безопасность!) и считаем это допустимым, пока нет ущерба недопустимого размера.

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

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

#vCISO #управление

Как обещал в предыдущей заметке, делюсь старой презентацией c BIS Summit-а 2016 года. Наверно, первом на просторах RU-Net-а упоминании Threat hunting-а.

Кстати, чуть позже, по мотивам доклада вышла статья в журнале "БДИ!", правда, найти ее мне почему-то не удалось (в целом, исходный текст у меня есть, поэтому если интересны исторические публикации, могу ее опубликовать здесь)

#MDR

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

#MDR

ЛК запустила функционал Threat landscape в составе своего TIP, где собрала известные кампании, разложенные по их TTP в нотации MITRE ATT&CK и целям: можно удобно выбрать интересующую индустрию и географическую локацию, и получить перечень релевантных атакующих и их ТТР.

Подробности будут на вебинаре. От нашей команды Detection engineering, а в прошлом - аналитик операционных линий, мой коллега и друг - Глеб Иванов.

#kaspersky #MDR

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

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

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

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

#управление #MDR

Среди техник для горизонтальных перемещений SCCM представлен только в T1072: Software Deployment Tools, однако, SCCM имеет функционал удаленного подключения к рабочей станции, и поэтому может предлагать функционал аналогичный VNC или RDP, а за счет широкого распространения SCCM в корпоративных сетях может быть вполне себе LotL-инструментом горизонтальных перемещений.

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

ЗЫ: А в MITRE SCCM в таком сценарии не предусмотрен. Что и следовало ожидать: ATT&CK со своим списком техник все больше отстает от реалий ITW, а они еще носом верятят, когда им техники заносят.

Делаем ханты, ребята...

#MDR

После того, как Visa и MasteCard решили наказать граждан РФ отказом от своих обязательств, наши карты этих платежных систем стали "бессрочными". У меня самого есть кредитка Visa Signature, которая давно истекла, однако, я продолжаю ей пользоваться, так как по ней сохранились привлекательные условия по кешбеку, а полных аналогов от Мир нет.

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

Итого:
- карты не "бессрочные"
- чем дальше от срока exp. date на карте, тем больше вероятность, что карта "перестанет работать"
- надо иметь бэкап-план на случай, что протухшая карта действительно откажет

#финансы

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

"Зри в корень!", - говорил Козьма Прутков.

Полно случаев в практике, да и ни у кого не вызывает сомнения, что неправильное лечение может ухудшить состояние пациента. Можно загубить как сам предмет лечения, так и здоровые органы. Ну, например, если бездумно трескать "бесконечно полезные" биодобавки и витамины, то могут отъехать печень и\или почки, которые буду стремиться все эту инородчину выводить.

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

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

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

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

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

Всем замечательной пятницы и выходных!
😁

#пятница #книги #саморазвитие

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

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

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