Cybersecurity Vocabulary for Developers: OWASP, CVE, and Zero-Trust Language (англійською)

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

Основний словник безпеки

** Поверхня атаки ** — загальний набір точок у системі, де атакуючий може спробувати ввести, видобути дані або завдати шкоди. « Кожна кінцева точка API, поле вводу користувача і залежність від сторонньої програми є частиною нашої поверхні атаки. Зменшення поверхні атаки є одним з найефективніших заходів безпеки, які ми можемо вжити»

** Модель загрози ** — структурований аналіз потенційних загроз системі, визначає, що може піти не так, хто може атакувати, і який буде вплив. « Перед тим, як ми відправляємо інтеграцію платежів, ми повинні запустити сеанс моделювання загроз — як мінімум, аналіз STRIDE нових потоків даних. »

** Актор загрози ** — суб’ єкт (особа, група або автоматизована система), який може використовувати вразливість. Загрози варіюються від автоматичних сканерів до цільових атак на держави. « Найбільш актуальними для нашого застосування є боти, які наповнюють дані про користувачів, і цільові веб- сканери, а не складні цільові атаки »

** Вразливість ** — слабкість у системі, яку може використати злочинець. « Відсутність перевірки вводу у кінцевій точці вивантаження файла є слабкістю; це може дозволити злочинцю вивантажити шкідливий файл. »

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

** CVE (Common Vulnerabilities and Exposures) ** — стандартизований ідентифікатор для публічно оголошених вразливостей безпеки. « Перевірте, чи є у ваших залежностях відкриті CVE з оцінкою CVSS вище 7. 0 перед випуском »

OWASP Top 10 Vocabulary (англійською)

OWASP Top 10 — це найбільш широко використовуваний список найбільш критичних ризиків безпеки веб-застосунків. Знання цього словника є необхідним для будь- якого розробника, який обговорює безпеку під час перегляду коду.

** Введення (A03) ** — сімейство атак, за допомогою яких до інтерпретатора надсилаються дані, які не є надійними, як частина команди або запиту. Найпоширенішою є вставка SQL. « Необроблене з’ єднання SQL у рядку 47 є класичною вразливістю у вставці — замість цього використовуйте параметризовані запити »

** Порушена автентифікація (A07) ** — похибки у реалізації автентифікації і керування сеансами, які дозволяють зломщикам вкрасти дані про користувача або сеанси. « Зберігання токенів сеансів у localStorage замість куки httpOnly є ризиком порушень автентифікації »

** Криптографічні помилки (A02) ** — конфіденційні дані виявлені через слабке шифрування, відсутнє шифрування або погане керування ключами. « Хешування паролів за допомогою MD5 є криптографічною помилкою — скористайтеся bcrypt або Argon2. »

** Небезпечний дизайн (A04) ** — помилки безпеки, які виникають через відсутність або недостатність засобів безпеки на етапі проектування. « Відсутність обмеження швидкості на кінцевій точці реєстрації є проблемою небезпечного дизайну, а не просто вада коду. »

** Неправильне налаштування безпеки (A05) ** — найчастіше зустрічається проблема: типові улікові дані, надмірно допустимі засоби керування доступом, увімкнено непотрібні служби або багатослівні повідомлення про помилки, які виявляють системні дані. « Цей контейнер S3 є публічно доступним — класичне неправильне налаштування безпеки. »

Система безпеки та захисту інформації

** Нульова довіра ** — модель безпеки, яка припускає, що жодному користувачеві, пристрою або мережі не слід довіряти типово, навіть у межах корпоративного периметру. Кожен запит доступу має бути перевірено. « Ми переходимо до архітектури нульової довіри: навіть внутрішні виклики між службами потребуватимуть взаємних TLS і сертифікатів з коротким терміном дії. »

** Найменші привілеї ** — принцип, за яким будь- який користувач, служба або процес має мати лише мінімальні права доступу, необхідні для виконання його функції. « Функції Lambda потрібно лише читати з одного контейнера S3 і записувати до однієї таблиці DynamoDB — застосувати найменші привілеї і негайно вилучити правила AdministratorAccess. »

Defence- in- depth — багатошаровий підхід до безпеки, за якого кілька незалежних елементів керування захищають систему, так що якщо один шар не спрацює, інші залишаться. « Наша стратегія захисту на глибині означає, що навіть якщо залежність має вразливість, комбінація сегментації мережі, перевірки вводу і правил WAF обмежує радіус атаки. »

** mTLS (Mutual TLS) ** — варіант TLS, за якого клієнт і сервер розпізнають один одного за допомогою сертифікатів, а не лише сервер, який представляє сертифікат. Поширений в архітектурах нульового довіри для комунікації між службами.

** SAST (Static Application Security Testing) ** — автоматизований аналіз коду для виявлення вразливостей безпеки без виконання коду. « Ми запускаємо SAST на кожному запиті на звантаження; будь- яке виявлення високої тяжкості блокує об’ єднання. »

** DAST (Dynamic Application Security Testing) ** — автоматичне перевірка безпеки запущеної програми за допомогою імітації атак. « DAST запускається щоночі у нашому середовищі перевірки, щоб виявити проблеми, які SAST може не помітити. »

Як обговорювати безпеку в кодових оглядах

Викликає занепокоєння щодо безпеки:

• «Це виглядає як потенційна вразливість введення — вхідні дані користувача інтерполюються безпосередньо в рядок запиту. Чи можемо ми використовувати параметризовані запити тут?»
• “Я хочу позначити це з точки зору безпеки: ця кінцева точка не має перевірки автентифікації. Чи це навмисне?»
• Повідомлення про помилку на рядку 34 виставляє схему бази даних — це ризик розголошення інформації

Похвала за хорошу практику безпеки:

• «Гарне використання параметризованих запитів всюди — це саме правильний шаблон.»
• «Я ціную явну перевірку вводу на тип файлу — це підхід до захисту в глибину, який ми хочемо»

** Пропозиції щодо поліпшення: **

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

Приклади слів у контексті

1. «Наша модель загрози визначила, що компонентом найвищого ризику є обробник завантаження файлів — він має велику поверхню атаки і обробляє ненадійні вводи, які в кінцевому підсумку надаються іншим користувачам»

2. «Принцип найменших привілеїв застосовується тут: обліковий запис служби, використаний цією Lambda, повинен мати тільки доступ для читання до конкретного префікса S3, який йому потрібен, а не доступ для читання до всього бака»

3. «Захист-в-глибину є нашою відповіддю на питання «а що, якщо один контроль не спрацює?» — ми маємо правила WAF, перевірку вхідних даних, параметризовані запити і кодування виходу, які захищають від атак введення»

4. «CVE, який був оголошений в понеділок, впливає на залежність, яку ми використовуємо безпосередньо; бал CVSS становить 9,1, що ставить його в критичну категорію — нам потрібно залатати і розгорнути до кінця дня»

5. «Нульове довір’я означає, що ми не вважаємо, що трафік, що походить зсередини нашого VPC, є надійним; кожен виклик між службами автентифікується з короткочасним токеном, а права доступу обмежені до необхідного мінімуму»

На практиці: Навігація нюансів з не-рідними мовами

Зрозуміти технічний жаргон - це одне; комунікувати це розуміння ефективно - це зовсім інше. Для розробників, які вивчають професійну англійську мову - особливо тих, чия перша мова не є англійською - тонкощі словника кібербезпеки можуть бути особливо викликом. Це не просто про те, щоб знати визначення «поверхні атаки»; це про те, щоб передати цю концепцію чітко і чітко, враховуючи потенційні нерозуміння, засновані на різних культурних підходах до оцінки ризику або технічних пояснень.

Розглянемо сценарій: Сара переглядає запит на витягування, надісланий Девідом, розробником, який недавно приєднався до команди. Девід реалізував нову кінцеву точку API, але не адекватно вирішив потенційні вразливості. У своєму PR- описі він просто стверджує: “Ця кінцева точка API обробляє дані користувача.” Хоча це технічно правильно, у ньому відсутній важливий контекст, що стосується наслідків безпеки. Рідний англійський носіїв відразу б розпізнав це як недостатньо. Сара може відповісти щось на зразок: «Дейвід, дякую за PR. Перед тим, як ми з’єднаємося, чи не могли б ви, будь ласка, розглянути моделювання загрози, яке ви виконали для цієї кінцевої точки? Які потенційні вектори атаки і як ви їх зменшили, щоб зменшити * поверхню атаки *, відкриту цією новою функціональністю? Важливо розглянути такі речі, як перевірка вхідних даних — чи вона достатньо надійна проти звичайних атак введення?» — ця фраза не просто про заяву технічної вимоги; це про те, щоб спонукати Девіда критично думати про ризики безпеки таким чином, щоб це відповідало встановленим англомовним практикам кібербезпеки.

Крім того, концепція «найменших привілеїв» може бути особливо складною для розробників, звиклих до різних моделей дозволів. Фрази на кшталт «надаючи підвищені привілеї не потрібен» або «зменшуючи радіус вибуху потенційного порушення» є поширеними в англійських дискусіях про безпеку. Це не просто обмеження доступу; це мінімізація шкоди, якщо нападник досягне несанкціонованого доступу. Ми часто бачимо це обговорюється під час перегляду коду, з коментарями на кшталт: “Чи можемо ми зменшити права, необхідні для цієї служби, тільки для доступу тільки для читання? Це відповідає стратегії оборони в глибину»

Нарешті, при обговоренні вразливостей, виявлених за допомогою таких систем, як CVE (Common Vulnerabilities and Exposures), важливо чітко сформулювати інформацію. Замість того, щоб сказати «Ця вразливість має високий бал CVSS», більш ефективним підходом є: «Ця CVE (CVE-2023-12345) описує критичну помилку в [захищеному компоненті], яка може дозволити нападнику виконати довільний код. Оцінка CVSS відображає тяжкість і потенційний вплив. ” Це докладне пояснення забезпечує, що всі розуміють природу уразливості і її наслідки.

Ось приклад того, як ви можете використовувати curl для перевірки на наявність відомої вразливості, що демонструє практичне застосування розуміння термінології:

curl -v --header "X-Custom-Header: vulnerable_value" https://example.com/api/endpoint

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