Этика, scope и образ мышления атакующего

Этика, закон и авторизация — всегда первыми

Это непреложное начало, и это не формальность. Единственный факт, делающий тест по безопасности законным, — явная письменная авторизация от того, кто действительно владеет активом или имеет право разрешить тестирование. Запустите то же сканирование, тот же фаззер, тот же скрипт перебора учётных данных без неё — и, в зависимости от юрисдикции, вы потенциально нарушили закон о компьютерных преступлениях (в США это Computer Fraud and Abuse Act; в Великобритании — Computer Misuse Act; аналогичные статьи есть почти везде). Байты на проводе идентичны. Изменилась только авторизация — и именно она важна для суда.

Поэтому до начала любых работ в письменном виде существуют четыре артефакта:

• Авторизация — подписанный документ (письмо об ангажементе, statement of work или политика программы) от стороны, имеющей право разрешить тестирование названных систем. «Мой руководитель сказал, что всё ок» в Slack — это не авторизация; авторизация — это подпись того, кто вправе её дать.
• Scope — точный перечень того, что вам можно трогать: какие домены, диапазоны IP, приложения и аккаунты внутри и — что не менее важно — что явно снаружи. Боевые платёжные системы, чужой SaaS и всё, чего нет в списке, по умолчанию вне scope. Вне scope — это значение по умолчанию; внутри scope — исключение, которое вам предоставили.
• Правила взаимодействия (rules of engagement, ROE) — как вам можно тестировать: временное окно, какие техники разрешены (можно ли DoS? социальную инженерию? физический доступ?), лимиты скорости, чтобы не уронить прод, правила обращения с любыми чувствительными данными, на которые вы наткнётесь, а также экстренный контакт и условие остановки.
• Ответственное раскрытие (responsible disclosure) — что происходит, когда вы что-то нашли: вы приватно сообщаете владельцу, даёте разумное окно на исправление и не публикуете, не продаёте и не эксплуатируете находку сверх того, что разрешает ангажемент.

Этот трек учит образу мышления атакующего как защитному инструменту. Всё здесь концептуально и оформлено как лаборатория: CTF-машина, которую вы подняли сами, намеренно уязвимое приложение, развёрнутое в вашей собственной VM, размещённая лаборатория, созданная ровно для этого. Здесь нет боевых payload’ов, и ничто никогда не направлено на систему, которой вы не владеете или тестировать которую вы явно не уполномочены. Чтение этого урока не даёт вам права что-либо трогать. Если вы ловите себя на желании дотянуться до реальной цели «просто посмотреть» — остановитесь: именно этот инстинкт и призван перехватить шаг авторизации. OWASP Web Security Testing Guide начинается так же и по той же причине: тестирование без задокументированного scope и разрешения — это не тестирование, а вторжение.

Образ мышления атакующего: цели, поверхность атаки и цепочка

Когда авторизация установлена, наступает собственно сдвиг мышления. Защитников учат думать категориями функций — работает ли логин, проверяет ли загрузка тип файла, рендерится ли отчёт. Атакующий думает категориями целей — я хочу прочитать данные других пользователей, я хочу выполнить код на этом сервере, я хочу остаться незамеченным. Затем он смотрит на всё, что система выставляет наружу (поверхность атаки: каждый endpoint, параметр, зависимость, заголовок, облачный бакет и человек, которого можно обработать социальной инженерией), и спрашивает, какая из выставленных вещей продвигает его к цели.

Этот рефлекс «сначала цель, потом картирование поверхности» — и есть весь смысл изучения нападения ради защиты. Вы учитесь не атаковать; вы учитесь предсказывать атакующего, чтобы тратить защитный бюджет там, где реальная ожидаемая ценность, а не укреплять единственную функцию, на которую никто и не нацелится.

Cyber Kill Chain от Lockheed Martin придаёт этому рефлексу структуру. Она моделирует вторжение как семь последовательных стадий — чтобы добиться успеха, атакующий обязан пройти их по порядку, а значит защитнику достаточно разорвать одно звено, чтобы разорвать всю цепь. Эта асимметрия и есть вся защитная ценность модели: атакующий должен выиграть каждую стадию; защитнику нужно выиграть лишь одну.

Как цепочка делает вас лучшим защитником

Вот часть, которая важна для инженера, который не станет фултайм-пентестером. Kill chain переформулирует «безопасно ли моё приложение?» в последовательность более дешёвых конкретных вопросов: может ли атакующий вообще дотянуться до этой поверхности (разведка, доставка)? Если дотянулся — существует ли изъян, который можно эксплуатировать (ваш собственный код)? Если эксплуатировал — может ли он закрепиться и позвонить домой (ваши рантайм- и сетевые контроли)? Модель распределяет защитное мышление по стадиям вместо ставки на одну идеальную стену.

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

Старшая оговорка: цепочка — это инструмент мышления, а не буквальный сценарий. Реальные вторжения пропускают стадии, возвращаются назад и размывают границы (современные фреймворки вроде MITRE ATT&CK существуют именно для того, чтобы передать эту неаккуратность на более гранулярном уровне техник). Считайте семь стадий чек-листом «где я мог бы это обнаружить или заблокировать», а не обещанием, что атаки маршируют строго слева направо.