Безпечне та вимірюване тестове середовище для авторизованого тестування на проникнення

1. Від початку чітко визначте мету тесту та повноваження

Спершу сформулюйте запитання, на яке шукаєте відповідь: чи можуть два клієнти бачити записи один одного, чи можна перевірити дії адміністратора, чи є зайвий доступ до інтерфейсу керування філією? Вузькі, вимірювані запитання пов’язують висновки тестової команди з конкретною роботою розробника або мережевого адміністратора. Звіт сканування, перевірка вихідного коду та тестування на проникнення мають різний обсяг. Не записуйте їх у документації закупівлі як одну й ту саму послугу.

NIST SP 800-115 розглядає планування оцінювання безпеки, аналіз результатів і заходи поліпшення; додаток B містить початковий шаблон правил проведення робіт. [1] Письмовий дозвіл має чітко визначати власника системи, ресурси в межах тесту, час, дозволені дії, виключені зони, правила обробки даних і особу з правом зупинки. Якщо використовуються хмарні або сторонні послуги, потрібно окремо перевірити їхні правила тестування.

2. Відокремте навчальну лабораторію від продуктивного середовища

Контрольована лабораторія може складатися з тестових пристроїв, цільового застосунку та засобів спостереження. Окрема віртуальна мережа й правила доступу мають блокувати перехід до продуктивних систем, а зовнішні підключення слід обмежити потрібними послугами. Адміністративний доступ також потрібно відокремити. Назва віртуальної машини або інший діапазон IP-адрес самі по собі не доводять дієвості ізоляції. Необхідно перевірити як дозволені шляхи, так і ті, що мають бути заблоковані.

Для навчання можна використовувати застосунки з навмисно закладеними вразливостями; OWASP Juice Shop є саме таким навчальним проєктом. [2] Заповнення такої цілі клієнтськими даними або розміщення її на загальнодоступному продуктивному сервері не є належним проєктуванням лабораторії. Створіть середовище під власним керуванням з обмеженим доступом. Навички, набуті під час навчання, не надають права тестувати системи третіх сторін. Цей посібник також не містить інструкцій із тестування зовнішніх систем.

3. Дані та облікові записи мають належати лабораторії

Працюйте із синтетичними записами клієнтів, замовлень і користувачів. Якщо реальні дані необхідні, використовуйте метод, погоджений відповідальним за обробку даних, і вузькі права доступу. Де можливо, застосовуйте маскування або мінімізацію даних. Робочі API-ключі, паролі й платіжні відомості не повинні потрапляти до тестової копії. Для створених на час тесту облікових записів мають бути відомі власник, роль і час закриття.

Для перевірки повноважень потрібні облікові записи з різними ролями та для різних прикладових клієнтів. Підхід OWASP до тестування авторизації допомагає зібрати очікувані дозволи між ролями й операціями в чітку матрицю. [3] Наприклад, якщо роль повинна читати лише власний запис, результат тесту фіксують разом із відповідною подією в журналі застосунку. Мета полягає не в отриманні інформації про реальну людину, а в перевірці на контрольованих даних, чи діє визначена межа.

4. Створіть відтворюваний початковий стан і систему спостереження

Додайте до початкової документації версію застосунку, конфігурацію, тестові дані та мережеві правила. Має бути зрозуміло, як повернути середовище до чистого стану після завершення випробування. Знімок стану може допомогти, але не обов’язково автоматично повертає стан пов’язаних зовнішніх сервісів чи сховищ даних. План відкату повинен охоплювати всі залежності тестованої системи.

Використовуйте синхронізовані за часом журнали, записи операцій і, за потреби, знімки екрана з мінімізованими чутливими даними. Файли доказів мають бути доступні лише уповноваженій команді; визначте строк зберігання та відповідального за видалення. Оберіть і практичні критерії зупинки: якщо виявлено неочікуване підключення до продуктивного середовища, дані поза погодженими межами або неприйнятний вплив на послугу, роботу припиняють і повідомляють відповідальну особу. Спостереження підвищує і безпеку випробування, і можливість згодом зрозуміти його перебіг.

5. Висновок, виправлення та повторний тест утворюють один ланцюг

OWASP Web Security Testing Guide пов’язує тестування безпеки з життєвим циклом розробки; один інструмент не охоплює всіх проблем безпеки. [4] У звіті вказуйте не лише рівень критичності, а й бізнес-процес, якого торкнулася проблема, передумови, спостережуваний результат і рекомендований контроль. Короткий виклад для керівництва має допомагати ухвалювати рішення, а технічний додаток — бути достатньо зрозумілим для повторного оцінювання висновку уповноваженою командою.

Після виправлення поставте те саме запитання новій версії та перевірте, чи не порушено нормальний сценарій користувача. Відповідальна особа, цільова дата й умови приймання для кожного висновку допомагають не залишити звіт лише в архіві. Успішний лабораторний результат не означає усунення всіх ризиків продуктивного середовища. Зафіксуйте відмінності між середовищами. Під час оцінювання мережевого дизайну та доступу з MyFi Business потреби тестового середовища в підключенні, ізоляції й технічній координації можна визначити окремо.

6. Перевірте перед початком роботи

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

• Чи є письмовий дозвіл, перелік ресурсів, часовий проміжок та відповідальний за зупинку?
• Чи перевірені умови сторонніх і хмарних послуг?
• Чи обмежений доступ лабораторії до продуктивного середовища та непотрібних зовнішніх цілей?
• Чи готові синтетичні дані, окремі тестові облікові записи та початкова конфігурація?
• Чи визначені відповідальні за доступ до доказів, зберігання, очищення й відкат?
• Чи прямо включені до обсягу робіт звіт, виправлення та повторне тестування?