tgoop.com/soldatov_in_telegram/481
Last Update:
Наступательная кибербезопасность 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 результаты пентеста должны быть оформлены так, чтобы заказчик мог это правильно съесть. Важнейший момент! Надо разбираться почему из проекта в проект у одного и того же заказчика мы видим одно и то же, может, стоит для него снизить трудоемкость обработки нашего отчета. Например, чтобы он был машиночитаемым и мог конвертироваться в наряды на работу в корпоративной системе управления изменениями, или что-то в этом роде. Очень правильный поинт, что надо понимать как заказчик будет работать с результатами проекта и помогать эту работу сделать максимально эффективной. Если наш продукт неправильно используется и заказчик не получает предполагаемую нами ценность - это наша проблема!
BY Солдатов в Телеграм
Share with your friend now:
tgoop.com/soldatov_in_telegram/481