Комментарии 4
Спасибо за перевод! Исходя из содержания статьи, не совсем понятно различие между классическим пентестом и red teaming, в приведенном примере: recon --> веб-приложение --> xss -->… Следуя подобной логике, это классический пентест, согласно общепринятой методологии, пусть с элементами соц. инженерии и физ. проникновением, только в х10 раз дороже?) Мне все таки кажется, что основная цель Red Team тестирований — проверить и на практике убедиться, что результаты регулярных пентестов актуальны (типа XSSок нет!) и самое главное это тренировка навыков Blue Team! Поэтому, при выборе типа тестирования, отталкиваться стоит не от зрелости компании, а от уровня подготовки и навыков защитников, чтобы почувствовать реальную пользу и эффективность от тестирований в формате Red Team.
На наш взгляд, задачей Red Team является демонстрация того, что даже если проведённый пентест конкретной системы не выявил уязвимости непосредственно в ней, и при этом только в ней (якобы) может храниться определённая информация – все равно можно получить искомые данные. Причём, неважен способ, которым эти данные будут получены: взлом сторонней системы или плагина, которые не были затронуты пентестом; нахождение той же информации в иных системах – например, в выгрузках из БД, хранящихся на файловых серверах; или, например – получение «легитимного» доступа к системе, используя аутентификацию и/или авторизацию в ней от имени допущенного к обработке этих данных лица.
Касаемо же тренировки навыков Blue Team – только в случае, если в роли большинства в Blue Team выступают все штатные сотрудники подразделений безопасности, выполняющие в день «учений» роль именно специалистов Blue Team, «разбавленные» небольшим количеством квалифицированных нанятых инженеров и аналитиков, помогающих в принятии решений в моменты обнаружения действий атакующей команды. Но это могут быть и нанятые команды, умеющие работать с внедрёнными системами обеспечения ИБ, работающие в связке с небольшим количеством штатных специалистов, которые смогут оперативно давать пояснения в отношении «ложных срабатываний». Выбор того или иного количественно-качественного состава зависит от конкретных целей и запланированной поверхности атаки.
Благодарю за пояснения! Еще хотелось бы понять момент, каким образом происходит выбор сценариев для проведения, т.е хочется понять факторы определяющие выбор, следует ли отталкиваться от отрасли деятельности организации, либо от конкретных APT, либо выбирать TTPs наугад из методологии MITRE, либо все таки более индивидуально, исходя из пожеланий заказчика? И еще вопрос, что по Вашем мнению более эффективно — аутсорс Blue Team или все таки своя команда?
В Red team всегда идёт работа так же, как это делал бы некий хакер или инсайдер. То есть, «сценариев», если вообще использовать это слово, два:
1) внешний атакующий, который должен преодолеть периметральную защиту, чаще всего с использованием социального инжиниринга, но также есть масса иных вариантов, как то:
0-day, некорректная конфигурация средств межсетевого экранирования и/или маршрутизаторов, иной человеческий фактор, и т.д.
2) инсайдер — и ему может потребоваться повышение привилегий, но часто — это «кража у себя же», т.е. в задачи Blue team входит эффективное выявление нестандартного поведения таких пользователей, особенно с критичными данными, до того, как сработают средства обнаружения утечки данных, если они вообще сработают.

По второму вопросу тоже нет такого ответа: «делай так — вот большая красная кнопка Сделать Хорошо» — всё зависит от целей, как это и было указано в предыдущем ответе. На наш взгляд, если цель — повысить квалификацию собственных команд ИБ, СБ и т.д., то стоит обратить пристальное вниманиe на вариант с минимальным количеством внешних специалистов (возможно, с установкой рекомендованных ими средств безопасности), а также если не хочется наступить на грабли «мы пропустили первую же атаку, и увидели только один из векторов, ничему не научились». Ведь в этом случае Red team достигнет «флага», и ей придётся заплатить, а фактическая цель не будет выполнена. В иных случаях выбор будет зависеть от множества факторов, и надо рассматривать их в отдельности.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Информация
Дата основания

1 мая 2005

Численность

1 001–5 000 человек

Дата регистрации

4 февраля 2015

Блог на Хабре