Повний посібник з англійської для Інженерів з безпеки

Англійська мова для інженерів

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

Англійська мова є мовою франка глобальної кібербезпеки. Національна база даних вразливостей (NVD), MITRE ATT&CK, OWASP, програма CVE, а також переважна більшість досліджень безпеки, конференцій та консультацій є англійською мовою. Читання та інтерпретація описів CVE, обґрунтування результатів CVSS і описів технік MITRE ATT&CK є щоденною вимогою. Неправильне розуміння рівня тяжкості або опису ланцюга атак може призвести до неправильного пріоритизації роботи з латами.

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

У розділах, наведених нижче, наведено певні слова англійської мови і шаблони спілкування, які вам знадобляться як інженеру з безпеки: точна мова оцінки CVE і CVSS, моделювання загроз STRIDE і OWASP, написання звітів про тестування проникнення, спілкування під час і після інциденту з безпекою, а також ретельне формулювання відповідного розкриття інформації.

Розділ 1: CVE & CVSS Scoring Language

Система Common Vulnerabilities and Exposures (CVE) і Common Vulnerability Scoring System (CVSS) є фундаментальним словником управління вразливістю. Читання і запис в цих системах точно є ключовою вмінням інженера безпеки.

Читання і запис описів CVE

Добре сформований опис CVE слідує структурованому шаблону: назва та версія продукту, тип вразливості, вектор атаки та потенційний вплив. Приклад: « Вразливість переповнення буфера, заснована на стеці, у версіях клієнта FooBar VPN, що були випущені раніше версії 3. 2. 1, надає змогу віддаленому злочинцю, який не пройшов автентифікацію, виконати довільний код з привілеями SYSTEM, надсилаючи спеціально створений пакет автентифікації ». Кожен елемент цього речення має значення. « Переповнення буфера, засноване на стеку » вказує тип CWE (Common Weakness Enumeration). « Віддалений злочинець, який не пройшов автентифікацію » визначає, хто може використати цю вразливість і звідки. « Спеціально створено » — це стандартний словник CVE для навмисно пошкоджених вхідних даних. « Виконати довільний код з привілеями SYSTEM » описує найгірший випадок.

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

CVSS Score Комунікація

Оцінки CVSS v3. x складаються з бази оцінки (0- 10), оцінки часу (змінюється залежно від зрілості експлойту) і оцінки навколишнього середовища (змінюється залежно від конкретного контексту). Базову оцінку обчислюють з шести показників: вектор атаки (мережа/ сусідні/ локальні/ фізичні), складність атаки (низка/ висока), потрібні привілеї (немає/ немає/ немає), взаємодія користувача (немає/ немає), обсяг (не змінено/ змінено) і вплив на конфіденційність/ цілісність/ доступність (немає/ немає/ немає).

При обґрунтуванні результату CVSS команді: «Я оцінив це як CVSS 9.8 Критичний. Вектор атаки - це мережа, тому що її можна використовувати через інтернет без будь-якої близькості. Складність атаки низька — експлойт надійний і не вимагає особливих умов. Значення параметрів Не потрібні привілеї і Взаємодія користувача — Ні, це означає, що будь- який анонімний користувач може запустити цю програму без будь- яких дій з боку жертви. Конфіденційність, цілісність і доступність — всі ці параметри мають значення Висока, оскільки успішний експлойт надає атакуючому повний контроль над вузлом, який був уражений». Такий тип описового виправдання є важливим у звітах з безпеки і рецензіях. Очки без письмового обґрунтування легко неправильно інтерпретуються.

Кваліфікаторний словник: «Критична» (9,0-10,0), «Висока» (7,0-8,9), «Средняя» (4,0-6,9), «Низька» (0,1-3,9), «Без» (0,0). На практиці, «Критична» вразливість вимагає негайної відповіді; «Висока» зазвичай має бути залатана протягом 30 днів; «Средняя» протягом 90 днів; «Нижня» в наступному запланованому вікні обслуговування. При обговоренні розбіжностей у оцінці: «Я б стверджував, що це повинно бути Високим, а не Критичним — Складність атаки повинна бути Високою, тому що експлойт вимагає умови гонки, яка не є тривіальною для надійного запуску»

Розділ 2: Словник моделювання загроз (STRIDE & OWASP)

Моделювання загроз є систематичним процесом ідентифікації загроз перед побудовою або розгортанням системи. Дві системи домінують в англомовних дискусіях моделювання загроз: STRIDE (від Microsoft) і OWASP Top 10. Обидві мають певний словниковий запас, який ви повинні мати змогу читати, застосовувати і вільно спілкуватися.

Словник-довідник

STRIDE — це акронім для шести категорій загроз: Spoofing (підробка чогось або когось), Tampering (зміна даних або коду), Repudiation (заперечення виконання дії), Information Disclosure (розкриття інформації для неавторизованих сторін), Denial of Service (здійснення системи або ресурсу недоступним) і підвищення привілеїв (набуття можливостей за межами того, що дозволено). У сеансі моделювання загроз ви описуєте загрози за допомогою цього словника: «Є загроза підробки — без взаємного TLS, людина-посередині може олігофренувати платіжну службу.» / «Ця черга повідомлень має ризик підробки — будь-яка служба з доступом для читання може споживати і переставляти повідомлення в чергу без виявлення споживачем змін.» / «У нас є прогалина відмови: записи журналу аудиту не підписані, тому компромісний обліковий запис адміністратора може вилучити записи журналу без виявлення»

Діаграма потоку даних (DFD) є стандартним артефактом, створеним під час сеансу моделювання загрози STRIDE. Ви можете вказати межі довіри (лінії, що відокремлюють процеси, запущені з різними рівнями привілеїв або у різних зонах безпеки) і перелік загроз для кожного перетину. Словник: «межа довіри», «склад даних», «процес», «зовнішня суть», «поток даних», «рівень довіри», «поверхня атаки»

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

OWASP Top 10 — список найкритичніших ризиків безпеки веб-застосунків, що оновлюється періодично. Кожен ризик має ідентифікатор (наприклад, A03:2021 — Введення) і стандартний опис. При обговоренні ризиків OWASP в оглядах коду або оглядах дизайну, звертайтеся до ідентифікатора безпосередньо: "Ця кінцева точка вразлива до A03 - Введення. Запит було побудовано за допомогою з’ єднання рядків, а введення користувача не було параметризовано. » / « Керування сеансами тут не анульовує токени під час виходу, що належить до A07 — Спроби ідентифікації та автентифікації зазнали невдачі. » Інші часто цитовані записи: A01 — Порушено контроль доступу, A02 — Криптографічні помилки, A05 — Неправильне налаштування безпеки, A09 — Несправності журналювання і моніторингу безпеки.

OWASP також підтримує декілька інших важливих англомовних ресурсів: OWASP Testing Guide (всеосяжний посібник для тестування безпеки), OWASP ASVS (Application Security Verification Standard — контрольний список вимог безпеки), і OWASP Cheat Sheet Series. Вільно володіти словником цих документів є необхідним для спілкування з іншими фахівцями з безпеки.

Розділ 3: Підготовка до тестування

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

Структура і словник

Професійний звіт про тестування проникнення зазвичай містить: Резюме (нарис ризику високого рівня для нетехнічних читачів), Розділ Обсягу і Методології (що було перевірено і як), Розділ Вивчення (подробні описи вразливостей) і Розділ Відновлення (пріоритетні рекомендації щодо виправлення). У резюме використовується мова, зосереджена на ризиках: «Оцінка виявила три критичні і п'ять високосерйозних вразливостей, які, якщо їх використовувати зовнішнім нападником, можуть призвести до повного компромісу бази даних клієнтів і виставлення PII приблизно 2,4 мільйона користувачів». Кількісне оцінювання впливу, коли це можливо — конкретні цифри мають більшу вагу, ніж нечіткі твердження.

Кожне окреме виявлення у розділі « Вияви » має стандартну структуру: Заголовок виявлення, Серйозність (Критична/ Висока/ Середня/ Низька/ Інформаційна), Оцінка CVSS, Вплив на компонент, Опис (що таке вразливість), Доказ (доказ — знімок вікна, пари запит/ відповідь або витяг з коду), Ризик (що може зробити злочинець) і Відновлення (як виправити помилку). Словник для кожного елемента: « Захищена кінцева точка: POST /api/v2/users/login », « Програма не застосовує обмеження швидкості на спроби автентифікації, що дозволяє атаки з використанням грубої сили », « Злочинець може використати це для переліку коректних імен користувачів і згодом компрометувати облікові записи за допомогою наповнення унікальних даних »

Опис атаки ланцюгами

Однією з найцінніших частин звіту про тестування проникнення є розповідь про те, як декілька виявлень меншої важкості з'єднуються разом, щоб отримати Критичний результат. Для цього потрібна точна послідовна мова: « Об’ єднавши пошук F- 03 (неавтентифікований SSRF) з пошуком F- 07 (внутрішня служба метаданих, доступна з сервера програми), зломщик зміг отримати унікальний ідентифікатор ролі IAM для ролі виробничої бази даних, а потім надати доступ для читання і запису до всіх записів клієнта. » Ключовий словник для ланцюгових описів атаки: « за допомогою, » « потім, » « що, у свою чергу, дозволило, » « у поєднанні з, » « ескалацією до, » « поворотом від, » « з’ єднанням цих двох вразливостей. »

Мова ремідій теж важлива. Використовувати конкретні, дії, які можна виконати: « Реалізувати параметризовані запити (готові інструкції) для всіх взаємодій з базою даних. Замінити поточний запит, який містить рядок у UserRepository. findByEmail () на рядку 47. Уникайте нечітких рекомендацій, наприклад, « виправити вразливість у вставленні ». Найбільш корисні поради щодо виправлення включають: конкретне розташування коду, рекомендований виправлення, фрагмент коду, якщо це можливо, і посилання на відповідний OWASP Cheat Sheet або CWE запис.

Розділ 4: Інформація про відповідь на інцидент

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

Серйозність і класифікація інциденту

Інциденти зазвичай класифікуються за тяжкістю: P0/SEV-1 (критичний — активне порушення з постійним впливом), P1/SEV-2 (високий — значний компроміс, що міститься або неминучий), P2/SEV-3 (середній — обмежений вплив або потенційний компроміс), P3/SEV-4 (нижчий — підозрювана діяльність під час розслідування). При оголошенні інциденту, використовуйте стандартний шаблон: « INCIDENT DECLARED — SEV-2 — Suspicious unauthorized access to production database. Часова шкала: аномалія в шаблоні запиту виявлена о 14:32 UTC. Командир: @AlexSmith. Поточний стан: дослідження початкового вектора доступу. Наступне оновлення через 30 хвилин." Ясна, структурована мова дозволяє паралельно працювати команді реагування на інциденти.

Життєвий цикл реагування на інцидент має певний словник для кожної фази. Визначення: « Ми виявили IOC (індикатор компромісу) — існують вихідні з’ єднання до відомого сервера C2 з кластера програм ». Стримування: « Ми ізолювали вузли, які зазнали пошкоджень, і відкликали пов’ язані з ними дані облікового запису служби ». Виправлення: « Механізм тривалості (заплановане завдання) було вилучено, а початковий вектор доступу (не залатений RCE у пристрої VPN) було залатено ». Відновлення: « Ми відновили з відомої резервної копії, створеної до вікна компромісу ». Вивчення: « Ми проведемо бездоганну пост- смертну перевірку у п’ ятницю — запрошення календаря містить попередній документ з хронологією »

Переклад з англійської мови

Часова шкала подій — це хронологічний запис подій, дій і рішень. Він використовує певний регістр: минулий час, пасивний голос для автоматичних подій, активний голос для людських рішень і часові штампи UTC. Приклади записів: «14:32 UTC — Аномальний шаблон запиту виявлено при моніторингу бази даних.» / «14:45 UTC — Попередження передано інженеру безпеки на гарячу лінію (J. Smith)." / "15:01 UTC — Інцидент оголошений. Призначено командира інциденту. / 15:23 UTC — Рішення прийнято для ізоляції заражених хостів. Обґрунтування: підозрюється активне вилучення даних на основі аномалій у вихідному трафіку. » / » 16: 42 UTC — Судово-експертне зображення, зроблене з пошкоджених вузлів перед відновленням. » На часовій шкалі слід записувати не лише те, що сталося, але й прийняті рішення і їх причини — це важливо для постмортемного дослідження і для регуляторних звітів.

Розділ 5: SOC операційна мова

Центр операцій безпеки (SOC) має свій власний словник, ритми спілкування і конвенції документації. Незалежно від того, працюєте ви в SOC, взаємодієте з одним або створюєте інструменти для одного, розуміння SOC англійської мови є необхідним у сучасній інженерії безпеки.

Мова аналізу та тригерного трианалізу

Аналізатори SOC сортують попередження за допомогою процесу розподілу: вони класифікують кожне попередження як Істинно позитивне (TP — попередження правильно ідентифікувало реальну загрозу), Хибно позитивне (FP — попередження було викликано, але не існує реальної загрози), або Доброякісне Істинно позитивне (BTP — попередження правильно ідентифікувало поведінку, яка в цьому випадку очікується). Мова сортування: «Це попередження є TP — виконання PowerShell, створене веб-процесом, відповідає техніці MITRE ATT&CK T1059.001 (командний і скриптовий інтерпретатор: PowerShell), що використовується на початковій стадії розгортання вимагачів грошей.» / «Закриття цього як FP — аномалія входу з нового місця від співробітника, який подорожує і підтвердив доступ»

SOC комунікація також використовує ідентифікатори MITRE ATT&CK як спільну мову: «Техніка бічного руху є T1021.002 — SMB/Windows Admin Shares. Злочинець використовує Pass-the- Hash для автентифікації до сусідніх вузлів. » Знайомство з матрицею MITRE ATT& CK — тактикою (« чому »), технікою (« як ») і підтехнікою (« конкретною реалізацією ») — тепер очікується, що інженери з безпеки з усього світу будуть вільно володіти цими мовами.

Інформаційна безпека мови

Інформація про загрози має певний словник: IOC (Індикатор компромісу — доказ того, що компроміс відбувся, наприклад, зловмисна IP-адреса або геш файлу), IOA (Індикатор атаки — доказ поведінки атаки в процесі), TTP (Тактика, техніки і процедури — поведінковий відбиток гравця загрози), гравець загрози (особа або група, що проводить атаки) і приписування (процес ідентифікації того, хто відповідальний за атаку). При обміні інформацією про загрозу: «Ми отримали CTI (Cyber Threat Intelligence), що вказує на те, що група загроз SCATTERED SPIDER активно націлюється на компанії в нашому секторі, використовуючи голосове фішинг (vishing), щоб обійти MFA. TTPs збігаються з останніми звітами від CrowdStrike і Mandiant. / "Шах SHA-256 скинутого вантажу збігається з відомим маяком Cobalt Strike з кампанії TA577, задокументованої в ISAC feed."

Розділ 6: Відповідальність за розголошення та поради з безпеки

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

Початкове повідомлення про розголошення

Початковий звіт про вразливість, надісланий виробнику, повинен містити: чітку тему (наприклад, « Звіт про вразливість безпеки: недовірена RCE у клієнті FooBar VPN »), резюме проблеми, повні технічні відомості (кроки для відтворення, код або відео для підтвердження концепції), ваш запропонований бал CVSS з поясненнями і запропонований час розкриття. Тон повинен бути професійним і співпрацелюбним, а не конфронтаційним: «Я пишу, щоб повідомити про вразливість безпеки, яку я виявив у FooBar VPN Client під час проведення досліджень безпеки. Я дотримувався принципів відповідального розкриття інформації і не ділився цими даними з третіми сторонами. Я радий працювати з вашою командою безпеки над відповідним графіком усунення»

Обговорення графіка розкриття використовує конкретний словник: «Я пропоную стандартний 90-денний термін розкриття, який відповідає Google Project Zero і індустріальним нормам. Якщо вам потрібен додатковий час через складність виправлення, я готовий продовжити цей термін до 14 днів за вашим проханням. Я маю намір опублікувати повний технічний запис і код підтвердження концепції [дата], незалежно від стану латки, щоб захистити користувачів, ввівши можливість виявлення. » Ключеві слова: « термін розкриття », « період ембарго », « скоординоване розкриття », « підтвердження концепції (PoC) », « доступність латки », « публічне розкриття »

Консультативна служба з питань безпеки

Опублікована попередня інформація щодо безпеки — це офіційний документ, який інформує користувачів про вразливість і доступні засоби її усунення. Повідомлення використовують стандартизовану структуру: ідентифікатор CVE, оцінку CVSS, версії, які зачіпаються, опис, обхідні шляхи та виправлену версію. Мова формальна і точна: «Критична вразливість (CVE-2024-XXXXX, CVSS 9.8) була виявлена в FooBar VPN Client версіях 3.0.0 до 3.2.0. Ця вразливість дозволяє неавтентифікованому віддаленому злочинцю виконувати довільний код на пошкоджених системах. У розділі щодо виправлення помилок використовується імперативна мова: « Користувачам настоятельно рекомендується негайно оновити до версії 3. 2. 1. Якщо негайне оновлення неможливе, наступне обмеження зменшує ризик у проміжку часу: [кроки обмеження]."

Розділ 7: Інформування нетехнічних зацікавлених сторін

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

Від англійської мови до англійської мови

Технічна мова і мова бізнес-ризиків описують одну й ту ж реальність з різних точок зору. Технічний висновок інженера безпеки стає бізнес-ризиком, коли ви відповідаєте на три запитання: Що міг би зробити нападник? Хто це? Який вплив на бізнес? Порівняйте: Технічні: « Неавтентифікований введення SQL у кінцеву точку входу дозволяє атакуючому здати всю таблицю користувачів ». Бізнес-ризик: «Критична вразливість на сторінці входу нашого клієнта може надати доступ зовнішньому атакуючому до імен, адрес електронної пошти і гешів паролів всіх 850 000 зареєстрованих клієнтів. Це викликало б обов'язкові зобов'язання щодо попередження за GDPR і могло б призвести до значних штрафів і шкоди репутації."

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

Представлення оцінок ризику і пріоритетів латок

При представленні пріоритету патчів керівництву, перекладайте результати CVSS в бізнес-рішень: "У нас є три патчі, які потрібно застосувати цього тижня. Перший є Критичним — він має бал CVSS 9.8 і є підтверджені публічні експлоати. Це ситуація, яка виникає зараз; кожен день затримки є значним ризиком. Другий і третій рівень — це рівень високої складності — важливий, але менш використовуваний. Я рекомендую залатати ці помилки протягом наступних двох тижнів під час наступного вікна підтримки». Такий вид чітких, пріоритетних рекомендацій є тим, що потрібно керівникам — а не необроблені числа CVSS без контексту.

Найбільш корисні слова та фрази для інженерів безпеки

Рекомендований навчальний шлях для інженерів безпеки

Фаза 1: Фундація — Основи кібербезпеки

1. 1-й

   Набір словників безпеки

   Створення основного словника з кібербезпеки: типи атак, класи вразливостей, захисні засоби керування і стандартні англійські терміни, що використовуються в описах CVE і звітах з безпеки.

2. 2-й

   Київський лінгвістичний інститут

   Практикуйте застосування словника кібербезпеки в реальних контекстах — читайте описи CVE, обговорюйте результати CVSS і інтерпретуйте звіти про вразливість.

3. 3-й

   Співвідношення мови і мови

   Англійська мова стандартів безпеки і систем відповідності: GDPR, SOC 2, ISO 27001, PCI-DSS, і як обговорювати засоби контролю безпеки в контексті відповідності.

Стадія 2: Проміжна — Реакція на інцидент та звіти

1. 4-й

   Вправи з мови реагування на інциденти

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

2. П'ять

   Підтримка обміну даними

   Написання висновків, опис ланцюгів атак і створення практичних рекомендацій щодо усунення на мові професійних звітів про тестування проникнення.

3. 6-й

   Вправи з мови безпеки

   Практичний словник інструментів безпеки, лабораторних середовищ і технічних засобів зв' язку для досліджень безпеки.

Стадія 3: Розширена — моделювання загроз, архітектура та розкриття

1. Сім

   Словник архітектурних термінів

   Англійська мова дизайну безпеки: архітектура нульової довіри, захист у глибині, зони безпеки, межі довіри, і словник для моделювання загроз з STRIDE.

2. 8-й

   Система управління доступом та ідентифікацією

   Словник IAM для сучасних хмарних середовищ: OAuth 2.0, OIDC, RBAC, ABAC, ескалація привілеїв і мова переглядів дизайну контролю доступу.

3. Дев'ять

   Мова управління Stakeholder

   Переклад технічних висновків безпеки на мову бізнес-ризиків для керівників, рад і регуляторів.

Використовується для навчання інженерів

Вправляйтеся у словниковому запасі і моделях спілкування, які описано у цьому підручнику, за допомогою таких груп вправ: