-
Как безопасно провести сканирование на уязвимости (Vulnerability Scanning) на сайте заказчика, чтобы случайно не нарушить работу его бизнеса?
Активное сканирование инструментами вроде Acunetix или Nessus создает высокую нагрузку и может привести к отказу в обслуживании (DoS), особенно на слабых серверах. Как технически грамотный исполнитель, вы должны до старта работ попросить клиента развернуть тестовую среду (Staging), полностью копирующую боевую. Если тестирование возможно только на рабочем сервере («на проде»), обязательно согласуйте в ТЗ «окно обслуживания» (обычно это ночь) и снизьте количество потоков в настройках сканера. Если сервер всё же зависнет, но вы действовали строго в рамках утвержденного ТЗ и временного окна, арбитраж биржи примет сторону исполнителя.
-
Что такое пентест (тест на проникновение)?
Это моделирование реальной кибератаки для выявления уязвимостей. Делится на внешний и внутренний пентест: социальная инженерия, взлом паролей, переполнение буфера, SQLi, XSS, CSRF, инъекции.
-
Что делать, если заказчик требует устранить уязвимости, хотя в задании был только аудит?
Аудит и устранение уязвимостей — разные услуги. Если в ТЗ указан только отчёт, исправление кода или конфигураций оформляется отдельным этапом с дополнительной оплатой. Все изменения фиксируйте через переписку. При споре арбитраж ориентируется на изначально согласованные условия.
-
Я провел сложный аудит инфраструктуры для крупного финтех-проекта, но клиент заставил подписать жесткий NDA. Как мне теперь демонстрировать этот успешный кейс в своем портфолио на бирже?
Соглашение о неразглашении (NDA) имеет юридический приоритет. Публиковать данные клиента без его согласия категорически запрещено — это приведет к блокировке вашего профиля и возможным искам. Единственный профессиональный выход: попросить у клиента письменное разрешение на публикацию полностью анонимизированного отчета (Blind Case Study). В таком документе удаляются названия компании, замазываются IP-адреса, домены и логотипы, но остается суть вашей работы (найденные CVE, методы эксплуатации и рекомендации). Если клиент откажет даже в этом, кейс придется оставить в тайне.
-
Заказчик просит провести пентест (Black Box) инфраструктуры конкурента или отказывается предоставить официальное письмо-разрешение (Letter of Authorization) на аудит своих собственных систем. Можно ли брать такой заказ?
Категорически нет. Любые активные действия (сканирование портов, брутфорс, эксплуатация уязвимостей) без явного, документально подтвержденного согласия владельца инфраструктуры являются незаконными. Сам факт создания заказа на бирже не заменяет Letter of Authorization. Вы обязаны запросить документ с подписью, подтверждающий, что заказчик владеет этими ресурсами. Если клиент отказывается, смело отказывайтесь от работы. Биржа блокирует заказчиков, пытающихся нанять исполнителей для атак на чужие ресурсы (Black Hat).
-
Во время аудита я выяснил, что для закрытия критической уязвимости клиенту нужно обновить устаревшее ядро системы (Legacy). Клиент отказывается, так как это сломает его самописный софт, и не принимает мою работу, аргументируя тем, что «дыра не закрыта». На чьей стороне правда?
Задача специалиста по ИБ в рамках аудита — обнаружить уязвимости, оценить риски (например, по шкале CVSS) и предложить корректные методы устранения. Если единственно верный технический путь (обновление ядра) нарушает бизнес-процессы клиента, решение об игнорировании этого риска принимает сам бизнес. Ваша работа считается выполненной в полном объеме с момента передачи качественного отчета и рекомендаций. Арбитраж биржи встанет на вашу сторону и одобрит выплату, так как вы не несете ответственности за устаревшую архитектуру заказчика.
-
Я был нанят для реагирования на инцидент (Incident Response) после взлома базы данных. Я вычистил сервер от вредоносов и закрыл вектор атаки. Теперь заказчик требует 100% гарантии, что его больше никогда не взломают. Как реагировать?
Ни один адекватный специалист по кибербезопасности не может дать 100% гарантию защиты от будущих взломов, так как постоянно появляются новые уязвимости нулевого дня (Zero-Day). Ваша задача в рамках инцидента — остановить текущую атаку, устранить найденные бэкдоры и минимизировать ущерб. Обязательно фиксируйте в ТЗ до начала работ, что результатом вашей услуги является ликвидация конкретного инцидента, а не пожизненная неуязвимость сервера. Арбитраж рассматривает выполнение обязательств только в рамках согласованного объема задач.
-
Как корректно зафиксировать границы пентеста, чтобы не выйти за рамки закона и ТЗ?
Перед началом работ обязательно оформляйте письменное разрешение на тестирование и фиксируйте «Rules of Engagement»: перечень IP-адресов, доменов, допустимые методы (black/white/gray box), запрет на DoS-атаки без согласования. Уточните, проводится ли тестирование в продакшене или тестовой среде. Все условия фиксируйте в переписке на бирже. Если вы действуете строго в рамках согласованного задания, арбитраж eTXT будет учитывать именно зафиксированные условия.
-
Как аргументировать стоимость комплексного аудита?
Обосновывайте цену объёмом инфраструктуры: количество серверов, приложений, сетевых узлов, глубина тестирования (автоматизированное сканирование + ручной анализ). Укажите методологию (OWASP, NIST) и ожидаемый результат — структурированный отчёт с приоритетами по CVSS.
-
Нужно ли передавать заказчику PoC или полноценный эксплойт?
Обычно достаточно Proof of Concept, подтверждающего наличие уязвимости. Полноценные эксплойты передаются только по отдельной договорённости и при согласовании юридических аспектов. Это должно быть прописано в ТЗ.
-
Как избежать споров по критичности уязвимостей?
Согласуйте шкалу оценки (например, CVSS v3.1) до начала работ. В отчёте указывайте формулу расчёта и факторы риска. Это снижает субъективность и упрощает защиту позиции при споре.