Основы кибербезопасности для системного аналитика

Безопасность перестаёт быть «задачей ИБ после релиза», когда её формулируют в требованиях до проектирования. Системный аналитик переводит цели конфиденциальности, целостности и доступности в проверяемые FR и NFR, связанные с угрозами, рисками и критериями приёмки. Статья отвечает на вопрос: как встроить security в процесс анализа — выявление, спецификация, изменения, gates — без подмены CISO, AppSec или QSA и без формулировки «ИБ сделает».

1. Суть темы

Кибербезопасность в роли SA — это инженерия требований безопасности (security requirements engineering) на протяжении SDLC — см. 00.03 Жизненный цикл ПО и место аналитика (SDLC, STLC): от контекста системы и перечня активов до user stories, NFR, моделей данных и интеграций. Информационная безопасность (ИБ) шире: охватывает процессы, людей и политики; в корпоративных документах РФ термины часто смешивают — для SA важнее граница роли, чем спор о синонимах. Кибербезопасность фокусируется на цифровых угрозах: компрометации учётных записей, утечках через API, ransomware, злоупотреблении интеграциями.

Отличие от 08.02 Нефункциональные требования (НФТ) — классификация и стандарты: security-требования — частный случай NFR и отдельные security FR с обязательным указанием источника (regulatory, policy, threat, incident) и негативной верификацией (abuse cases, negative tests). В 08.02 — классификация атрибутов качества и конфликты NFR; здесь — процесс: threat modeling, реестр, gates, эволюция при изменениях.

Граница роли SA:

Security by Design / Secure SDLC означает, что безопасность встроена в фазы анализа, проектирования, разработки и эксплуатации — через threat modeling, security stories, security gates в Definition of Done — см. 05.02 Scrum и Kanban (аналитик в Agile) и 05.04 DevOps и непрерывная поставка — влияние на анализ, а не «болт-on» перед релизом. Практики SSDF (NIST SP 800-218) связывают security gates с конвейером — детали pipeline — 07.06 CICD и конвейеры — влияние на требования.

flowchart LR
    subgraph context [Контекст]
        A[Активы и данные]
        B[Границы доверия]
        C[Регуляторный контур]
    end
    subgraph analysis [Анализ SA]
        TM[Threat modeling]
        SR[Security requirements]
        AC[Acceptance criteria]
    end
    subgraph verify [Проверка и эксплуатация]
        T[Тесты и рецензии]
        R[Риск-реестр]
        O[Release / operate]
        I[Post-incident feedback]
    end
    context --> analysis
    analysis --> T
    T --> R
    T --> O
    R -->|residual risk / новые угрозы| TM
    O --> I
    I -->|post-incident| TM

152-ФЗ, ФСТЭК, PCI DSS, отраслевые акты — детали по каждому регуляторному источнику в 08.06 Юридические и регуляторные требования РФ (PCI-DSS) (название файла историческое; статья — hub по compliance РФ). Здесь — общая рамка для любой системы: IAM, защита данных, аудит, модели угроз и связь с 08.05 Управление рисками на этапе анализа.

2. Ключевые понятия

Общий язык ИБ нужен SA, чтобы формулировать требования и вести workshop; глубина проектирования контролей — в соседних разделах: IAM/OAuth — 03.05.05 Безопасность API, классификация БТ/ФТ/НФТ — 02.03.01 Классификация требований (БТ, ФТ, НФТ), trust boundaries на DFD — 03.04.02 Диаграмма потоков данных (DFD) и 03.01.02 Моделирование контекста системы (Context Diagram).

CIA и расширения

Конфиденциальность (Confidentiality), целостность (Integrity), доступность (Availability) — базовый язык security NFR в 10.01.12 Шаблон нефункциональных требований (NFR). Дополнительно:

• подотчётность (accountability) — кто что сделал и когда (audit log);
• неотказуемость (non-repudiation) — нельзя отрицать совершённое действие;
• приватность (privacy) — минимизация и контроль субъекта над ПДн; для РФ-проектов основной мост — 08.06 Юридические и регуляторные требования РФ (PCI-DSS).

При конфликте NFR (полное логирование vs минимизация ПДн) SA фиксирует явный приоритет и компромисс — псевдонимизация, маскирование, сокращение полей в логах — см. 08.02 Нефункциональные требования (НФТ) — классификация и стандарты.

Уязвимость, угроза, риск, контроль

Типы источников требований

В реестре разводите источник и тип требования — иначе «152-ФЗ» и «TLS 1.2+» смешиваются в одной строке без трассировки к 02.03.04 Трассировка требований (концепция):

Regulatory requirement отвечает на «что должно быть доказано регулятору»; security NFR — на «как система должна себя вести». Одно требование может иметь оба слоя: «шифрование ПДн at rest» — NFR; «соответствие приказу ФСТЭК №…» — regulatory trace к 08.06 Юридические и регуляторные требования РФ (PCI-DSS).

Требования безопасности

Security requirements — подмножество 08.02 Нефункциональные требования (НФТ) — классификация и стандарты плюс отдельные security FR — см. 02.03.01 Классификация требований (БТ, ФТ, НФТ):

• функциональные (security FR) — аутентификация, авторизация, аудит, блокировка сессии, MFA;
• нефункциональные (security NFR) — TLS 1.2+, шифрование at rest, сегментация, RTO/RPO.

Каждое: ID, тип источника, owner, метод верификации — иначе «security theater» — см. 02.04.03 Управление качеством требований. Реестр размещается в SRS или связанном артефакте — 02.03.03 Спецификация требований (SRS, Use Case, User Story). Качество формулировок — 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148).

IAM — что попадает в спецификацию

Граница с 03.05.05 Безопасность API: в 10.01.04 Шаблон спецификации REST API и backlog SA фиксирует обязательные блоки — auth method, session/token policy (поля, не алгоритмы), authorization matrix, rate limits, error contract, scopes — и negative scenarios. OAuth flows, rotation schemes, device binding — детальный дизайн в 03.05.05; в SRS достаточно «блок заполнен + ссылка на ADR/03.05.05», если механизм нетривиален.

Модели угроз

Threat modeling — разбор активов, границ доверия, злоумышленников и контрмер. SA фасилитирует артефакты; экспертиза ИБ — STRIDE, attack trees, MITRE ATT&CK как vocabulary тактик (SA не эксперт, но фиксирует выход в backlog).

STRIDE — для злоумышленника и цифровых компонентов:

HAZOP/FMEA — для отказов и опасностей процесса/системы без злоумышленника — 04.04 Техника HAZOP и FMEA для анализа рисков. Правило выбора: STRIDE на workshop по фиче/API; HAZOP — когда критичны отказы оборудования, цепочки поставок, safety-critical процессы. Не смешивайте методы на одной сессии без явной повестки.

Abuse cases — зеркало use case для злоумышленника — 03.02.01 Диаграмма прецедентов (Use Case Diagram); в backlog оформляются как security stories с AC — 02.04.02 Критерии приёмки (Acceptance Criteria); негативные потоки — 03.02.03 Диаграмма последовательности (Sequence Diagram).

Защита данных, Zero Trust, IR

• Классификация данных — в 03.03.03 Словарь данных (описание), 03.03.02 Логическая и физическая модель данных (чувствительные поля, шифрование at rest).
• Zero Trust / сегментация — NFR и архитектурные ограничения; сетевой контекст — 07.07 Сетевые основы (подсети, протоколы и маршрутизация).
• Logging & audit — события, поля, retention, защита логов; основа для incident response (IR) требований: оповещение при подозрительном login, блокировка учётки, сохранение доказательств, экспорт audit trail для расследования, SLA реакции системы (не playbooks SOC — они вне SA, но NFR «система должна поддерживать…» — в зоне SA).

OWASP и ASVS

• OWASP Top 10 — каталог рисков для негативных сценариев.
• OWASP ASVS — верифицируемый чеклист (L1–L3) для security AC.
• NIST CSF / ISO 27001 / ISO 27002 — vocabulary и каталог мер для mapping контролей; SA не переписывает стандарт в SRS — для SRS чаще нужен 27002 (каталог контролей), 27001 — рамка СМИБ.

Выбор уровня ASVS: SA готовит черновик обоснования и эскалирует на утверждение CISO/AppSec:

Утверждает CISO / AppSec с учётом 08.06 Юридические и регуляторные требования РФ (PCI-DSS); SA фиксирует согласованный уровень в SRS и AC, не подменяя risk appetite — эскалация residual risk к 02.01.03 Анализ заинтересованных сторон (Stakeholder Map).

3. Как применяется в работе аналитика

Выявление (elicitation) и контекст

Security поднимайте на первых интервью и воркшопах, а не после архитектуры — см. 02.02.01 Интервьюирование и анкетирование, 02.02.02 Воркшопы, фасилитация и совместные сессии. Минимум вопросов:

• какие данные и активы критичны; есть ли ПДн, платёжный контур, гос. тайна;
• действующие политики ИБ и baseline — не «у нас есть PDF», а кто owner и какие пункты mandatory для проекта;
• интеграции, B2B, SaaS, multi-tenant — кто отвечает за auth и данные;
• инциденты и аудиты за последние 12–24 месяца — что уже ломалось.

На старте проекта зафиксируйте:

1. Активы — данные, ключи, репутация, непрерывность; RTO/RPO как NFR availability.
2. Регуляторный контур — трассировка regulatory requirements к 08.06 Юридические и регуляторные требования РФ (PCI-DSS).
3. Границы доверия — Internet / DMZ / internal / partner B2B на 06.03.05 C4-модель и 03.01.02 Моделирование контекста системы (Context Diagram).
4. Поверхность атаки — UI, REST/gRPC, файлы, админки, batch, webhooks, очереди.

SA готовит черновик целевого профиля защиты (baseline, класс системы по internal policy), фасилитирует сбор вводных от бизнеса и архитектора и эскалирует на утверждение ИБ/CISO — SA не назначает risk appetite и не утверждает профиль.

Реестр и формулировка требований

Реестр security/NFR — отдельная вкладка или тег в инструменте требований — 02.05.06 Инструменты управления требованиями (Jama, DOORS, Confluence); в составе SRS — 02.03.03 Спецификация требований (SRS, Use Case, User Story):

ID | Тип источника | Источник | Требование | Owner | Verification

Пример строк: SEC-042 | threat/STRIDE-I | DFD: export API | Error response без internal ID | Dev | Negative API test.

Чеклист по ролям, интеграциям и API

Для каждой роли и интеграции в spec/backlog проверьте, что заполнены блоки (имена полей — ориентир для 10.01.04 Шаблон спецификации REST API; async — 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf), 03.05.04 Асинхронное взаимодействие (очереди, Kafka, Events)):

Детали механизмов (OAuth flows, refresh rotation, device binding) — в 03.05.05 Безопасность API; правило: если блок в spec пуст — дефект DoR, если механизм спорный — ADR + отсылка в 03.05.05.

Multi-tenancy (B2B SaaS) — отдельный шаблон требований; tenant_id как сквозной идентификатор — 03.06.02 Основы Domain-Driven Design, 10.01.03 Шаблон спецификации БД сервиса:

• изоляция данных по tenant (queries, backups, exports);
• изоляция кэша, очередей, search index;
• admin/support: impersonation только с audit и scope;
• object-level rules: tenant_id во всех операциях — не только RBAC.

Формат security user story:

As <role>, I need <security capability>, so that <risk/business outcome> is mitigated.

Security acceptance criteria (уровень ASVS — по таблице уровней ASVS выше):

• MFA для администраторов;
• запрет default credentials;
• TLS 1.2+ для внешних каналов;
• secrets not in repo / not in logs;
• SBOM / контроль зависимостей в pipeline — 07.06 CICD и конвейеры — влияние на требования;
• audit log при смене роли или экспорте чувствительных данных;
• негативные BDD: brute force, IDOR, cross-tenant access, session fixation.

Критерии приёмки — 02.04.02 Критерии приёмки (Acceptance Criteria); шаблон NFR — 10.01.12 Шаблон нефункциональных требований (NFR).

Threat modeling: гранулярность, изменения, SDLC

Повтор threat model — при смене архитектуры, новых trust boundaries, интеграциях, post-incident. Изменение требований (новый endpoint, смена auth, расширение scope) — триггер delta threat model и security-регресс: что из STRIDE/AC устарело — см. 02.05.02 Управление изменениями (Change Control Board), 02.05.02 Управление приоритетами в условиях изменчивости. Заявка на change без оценки security impact — типичный процессный дефект.

Связь с риском: угроза → treatment (mitigate/accept) → ID требования — 08.05 Управление рисками на этапе анализа; accept эскалируется стейкхолдерам.

Workshop (SA готовит артефакты; ИБ — экспертиза):

1. DFD с entry points — 03.04.02 Диаграмма потоков данных (DFD).
2. STRIDE по компонентам и потокам (включая batch/webhooks).
3. Контрмеры → backlog (FR/NFR + AC).
4. При safety/отказах — отдельная сессия HAZOP — 04.04 Техника HAZOP и FMEA для анализа рисков.

Выход — трассируемые требования — 10.01.15 Шаблон матрицы трассировки, 02.03.04 Трассировка требований (концепция); крупные решения — 10.01.13 Шаблон архитектурного решения (ADR) с options и residual risk.

Артефакты, third-party, IR

Third-party / SaaS — матрица shared responsibility (что в scope поставки SA):

Incident response NFR (минимум для SRS):

• события для алертов: brute force, privilege escalation, mass export;
• автоблокировка учётки / session revocation;
• immutable audit trail для расследования;
• API/процесс выгрузки доказательств для SOC.

Security gates в DoR / DoD

Статическая проверка — 08.03 Тестирование требований (статическое тестирование); рецензия: STRIDE coverage, negative tests, secrets, PII in logs — 08.04 Рецензирование и инспекции (техники Фейгана). Перед стартом разработки — 10.04 Чеклист аналитика перед стартом разработки.

Метрики процесса

Отслеживайте качество security-анализа — 08.01 Метрики и KPI процесса анализа:

• доля security-требований с named verification (цель: 100% для critical);
• дефекты на рецензии: пропуск STRIDE-категории, отсутствие negative AC, смешение regulatory и technical без trace;
• coverage threat model → backlog: каждая high/medium угроза имеет ID требования.

Роли и эскалация

• SA — формулирует, трассирует, фасилитирует threat modeling, черновик профиля защиты.
• CISO / AppSec — baseline, ASVS level, mapping NIST/ISO, утверждение residual risk и профиля.
• DPO / юристы — regulatory requirements, privacy.
• Архитектор — технический дизайн контролей.

SA документирует options и residual risk; окончательный risk appetite и accept — стейкхолдеры — 08.05 Управление рисками на этапе анализа, 02.01.03 Анализ заинтересованных сторон (Stakeholder Map).

4. Типовые ошибки и ограничения

Ограничения роли

• Pen test, SAST/DAST, WAF, SIEM — вне SA; требования проверяемы с named verification.
• Перегруз backlog без verification — «security theater» — см. 02.04.03 Управление качеством требований; лучше меньше, но с AC и trace.
• SA не интерпретирует закон в одиночку — 08.06 Юридические и регуляторные требования РФ (PCI-DSS).
• Дублирование 03.05.05 Безопасность API в SRS: не проектируйте OAuth flows в spec — фиксируйте обязательные блоки и отсылку.

Типичные ошибки

Anti-pattern: «шифровать всё» без key management; «SA утвердил профиль защиты» — SA только готовит черновик и эскалирует; подпись — CISO.

Критерий качества: по документам видно — активы, STRIDE coverage, verification каждого требования, regulatory trace — 02.04.01 Верификация и валидация (V&V).

Связи с другими разделами базы

• Выявление и спецификация — 02.02.01 Интервьюирование и анкетирование, 02.03.01 Классификация требований (БТ, ФТ, НФТ), 02.03.03 Спецификация требований (SRS, Use Case, User Story), 02.04.03 Управление качеством требований.
• Изменения и приоритеты — 02.05.02 Управление изменениями (Change Control Board), 02.05.02 Управление приоритетами в условиях изменчивости: delta threat model при change.
• НФТ и риски — 08.02 Нефункциональные требования (НФТ) — классификация и стандарты, 08.05 Управление рисками на этапе анализа, 08.06 Юридические и регуляторные требования РФ (PCI-DSS).
• Качество и gates — 08.03 Тестирование требований (статическое тестирование), 08.04 Рецензирование и инспекции (техники Фейгана), 10.04 Чеклист аналитика перед стартом разработки.
• API и интеграции — 03.05.05 Безопасность API (дизайн), 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf), 10.01.04 Шаблон спецификации REST API (обязательные блоки spec).
• Моделирование и данные — 03.04.02 Диаграмма потоков данных (DFD), 03.06.02 Основы Domain-Driven Design, 10.01.03 Шаблон спецификации БД сервиса (multi-tenant).
• Шаблоны и трассировка — 10.01.12 Шаблон нефункциональных требований (NFR), 10.01.15 Шаблон матрицы трассировки, 10.01.13 Шаблон архитектурного решения (ADR).

Источники и дополнительные материалы

Стандарты и своды

• OWASP Top 10 (риски веб-приложений): https://owasp.org/www-project-top-ten/
• OWASP Application Security Verification Standard (ASVS): https://owasp.org/www-project-application-security-verification-standard/
• OWASP Proactive Controls (контроль → требование → AC): https://owasp.org/www-project-proactive-controls/
• OWASP Cheat Sheet Series (аутентификация, авторизация, logging, threat modeling и др.): https://cheatsheetseries.owasp.org/
• OWASP Threat Modeling: https://owasp.org/www-community/Threat_Modeling
• NIST Cybersecurity Framework (CSF): https://www.nist.gov/cyberframework
• NIST SP 800-53 Rev. 5 (Security and Privacy Controls): https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final
• NIST SP 800-218 (Secure Software Development Framework, SSDF): https://csrc.nist.gov/publications/detail/sp/800-218/final
• ISO/IEC 27001:2022 (СМИБ — рамка): https://www.iso.org/isoiec-27001-information-security.html
• ISO/IEC 27002:2022 (каталог мер контроля — mapping в SRS): https://www.iso.org/standard/75652.html
• Microsoft STRIDE (модель угроз): https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats
• MITRE ATT&CK (тактики и техники для threat workshop): https://attack.mitre.org/
• CWE (Common Weakness Enumeration): https://cwe.mitre.org/

Контекст compliance (без замены профильных статей)

• PCI Security Standards Council (стыковка с 08.06 Юридические и регуляторные требования РФ (PCI-DSS)): https://www.pcisecuritystandards.org/
• Роскомнадзор / 152-ФЗ о персональных данных: http://pd.rkn.gov.ru/ (портал операторов; при недоступности — https://rkn.gov.ru/personal-data/)
• ФСТЭК России (документы по защите информации): https://fstec.ru/dokumenty/
• БДУ ФСТЭК (банк данных угроз): https://bdu.fstec.ru/

Перед публикацией в vault перепроверьте актуальные редакции OWASP ASVS, NIST SP 800-53/800-218, ISO 27002 и внутренние политики ИБ организации по официальным источникам.