CompTIA SY0-701: Управление, управление рисками и комплаенс — Руководство по подготовке

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Часть CompTIA Security+ SY0-701 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов CompTIA, или пройдите тесты на время на ExamRoll.io.

Управление, риски и соответствие требованиям (Governance, Risk Management, and Compliance), сокращенно GRC, — это связующее звено, которое объединяет технические средства контроля безопасности со стратегией организации, юридическими обязательствами и финансовой реальностью. В то время как файрволы и агенты на конечных точках защищают системы, GRC определяет, зачем они существуют, кто ими владеет и как измеряется и отслеживается их эффективность. Зрелая программа GRC превращает безопасность из разовой технической дисциплины в проверяемую, повторяемую бизнес-функцию.

Управление безопасностью и его основы

Управление безопасностью — это система полномочий, ответственности и принятия решений, которая определяет уровень защищенности организации. Его важнейший элемент — поддержка со стороны руководства, поскольку без приверженности лидеров политики превращаются в документы, которые пылятся на полке, а бюджеты испаряются. Управление создает три уровня документации: политики (высокоуровневые, обязательные для исполнения положения о намерениях, утвержденные руководством), стандарты (конкретные, измеримые требования — например, «минимальная версия TLS 1.3 для всех внешних конечных точек»), процедуры или СОП (пошаговые рабочие инструкции) и рекомендации (рекомендуемые, но не обязательные практики). Путаница между этими уровнями — распространенная ошибка; политика определяет, что и почему, а процедура — как.

К распространенным организационным политикам относятся Политика допустимого использования (AUP), регулирующая использование сотрудниками корпоративных систем, политики паролей и доступа, политики классификации данных, политики реагирования на инциденты и политики управления изменениями. Каждая из них обеспечивается техническими средствами контроля и дисциплинарными процессами.

Оценка рисков и количественный анализ

Управление рисками следует жизненному циклу: выявление активов и угроз, оценка вероятности и последствий, обработка риска и постоянный мониторинг. Определение области оценки — это первый и часто недооцениваемый шаг. Он определяет границы оценки, включая то, какие системы, бизнес-подразделения, типы данных и сценарии угроз рассматриваются. Без определенной области оценки становятся безграничными и дают ненадежные результаты.

Количественный анализ рисков использует денежные значения для объективного сравнения рисков. Основные формулы:

SLE (Single Loss Expectancy) = Asset Value × Exposure Factor
ARO (Annualized Rate of Occurrence) = Expected incidents per year
ALE (Annualized Loss Expectancy) = SLE × ARO

Например, если инцидент с программой-вымогателем будет стоить 15 000 $ за одно происшествие и ожидается, что он произойдет дважды за три года, ARO составит 2 ÷ 3 ≈ 0,667, что делает ALE = 15 000 $ × 0,667 = 10 000 $ в год. Распространенная ошибка — не приводить ARO к годовому значению. Если частота дана за несколько лет, ее необходимо соответствующим образом разделить. Еще одна ловушка — использовать только SLE для обоснования внедрения средства контроля; SLE в 500 000 $ при ARO 0,01 (ALE = 5 000 $) редко оправдывает ежегодные затраты на средство контроля в 50 000 $.

Качественный анализ, напротив, использует порядковые шкалы (низкий/средний/высокий или 1–5) и тепловые карты. Он быстрее и полезен, когда точные финансовые данные недоступны, но ему не хватает точности для принятия решений на основе анализа затрат и выгод.

Аппетит к риску и толерантность к риску определяют, какой уровень риска руководство готово принять. Аппетит — это стратегический уровень приемлемого риска, а толерантность описывает допустимое отклонение от этого уровня. Они должны быть определены до принятия решений по обработке, так как устанавливают порог, выше которого требуются действия.

Стратегии обработки рисков

После оценки каждый риск обрабатывается с использованием одной из четырех стратегий. Снижение (митигация) уменьшает вероятность или последствия с помощью средств контроля — установки патчей, сегментации, MFA. Передача перекладывает финансовые последствия на третью сторону, чаще всего через киберстрахование или возмещение убытков по договору. Уклонение устраняет риск путем прекращения деятельности — например, отказ от хранения определенных типов данных. Принятие — это формальное, задокументированное решение не предпринимать никаких действий, обычно когда стоимость обработки превышает ALE.

Опасное заблуждение — рассматривать страхование как замену снижению риска. Страхование передает финансовые последствия, но никак не предотвращает утечки, репутационный ущерб или штрафы от регуляторов, многие из которых прямо исключены из полисов киберстрахования. Аналогично, развертывание компенсирующего контроля — альтернативной меры защиты, когда основная мера нецелесообразна, — является формой снижения риска, а не его принятия. Если устаревшая система не поддерживает MFA и вместо этого изолирована в сегментированную VLAN с расширенным логированием, эта сегментация является компенсирующим контролем, а не принятым риском.

Реестр рисков

Реестр рисков — это центральный артефакт управления рисками. В нем документируется каждый выявленный риск вместе с ответственным владельцем, оценками вероятности и последствий, текущими средствами контроля, стратегией обработки, остаточным риском, пороговыми значениями и датами пересмотра. Хорошо поддерживаемый реестр позволяет руководству приоритизировать расходы и убеждает аудиторов в том, что решения по рискам прослеживаемы. Типичная запись в реестре может выглядеть так:

Risk ID: R-2024-017
Description: Unpatched Apache Struts on public web tier
Owner: Director of Infrastructure
Likelihood: High | Impact: High | Inherent Risk: Critical
Treatment: Mitigate — WAF virtual patch + emergency change window
Residual Risk: Medium | Threshold: Any exploit PoC published
Review Cadence: Weekly until closed

Оценки рисков должны быть периодическими, а не разовыми. Ландшафт угроз, бизнес-процессы и отношения с третьими сторонами постоянно меняются; ежегодная оценка, дополненная внеплановыми переоценками (при крупных приобретениях, появлении новых нормативных требований, инцидентах), является общепринятым стандартом.

Контракты и сервисные соглашения

Договорные инструменты кодифицируют обязательства между сторонами. Рамочное соглашение об оказании услуг (Master Service Agreement, MSA) устанавливает общие юридические условия, регулирующие все взаимоотношения. Описание работ (Statement of Work, SOW) действует в рамках MSA и определяет конкретные результаты, сроки и критерии приемки для отдельного проекта. Соглашение об уровне обслуживания (Service Level Agreement, SLA) определяет измеримые обязательства по производительности — процент времени безотказной работы, время отклика, штрафы за несоблюдение метрик. Распространенная ошибка — путать SOW и SLA: в SOW говорится «сдать клиентский портал к третьему кварталу», а в SLA — «портал будет поддерживать доступность 99,9% со временем реакции на инцидент в четыре часа».

Соглашение о неразглашении (Non-Disclosure Agreement, NDA) защищает конфиденциальную информацию, которой обмениваются стороны. Меморандум о взаимопонимании (Memorandum of Understanding, MOU) выражает намерение о сотрудничестве и, как правило, не имеет обязательной юридической силы. Соглашения о деловом партнерстве (Business Partnership Agreements, BPA) регулируют совместные предприятия, а Соглашения о безопасности межсетевых соединений (Interconnection Security Agreements, ISA) определяют технические требования и требования безопасности при прямом соединении систем двух организаций.

Риски третьих сторон и цепочка поставок

Управление рисками третьих сторон исходит из того, что состояние безопасности организации распространяется на каждого поставщика, имеющего доступ к ее данным или системам. Комплексная проверка начинается до подписания контракта — с анализа финансовой стабильности, сертификатов безопасности и истории инцидентов — и продолжается на протяжении всего сотрудничества посредством периодических переоценок, пунктов о праве на аудит и услуг непрерывного мониторинга.

Риск цепочки поставок распространяет это на происхождение оборудования, программного обеспечения и прошивок. Спецификации программного обеспечения (Software Bills of Materials, SBOM), проверка подписи кода и опросники по безопасности для поставщиков становятся все более обязательными. Компрометация SolarWinds в 2020 году наглядно продемонстрировала, как доверенный канал обновления ПО сам может стать вектором атаки: злоумышленники внедрили бэкдор (SUNBURST) в конвейер сборки Orion, который затем был криптографически подписан и распространен среди примерно 18 000 клиентов как легитимное обновление. Никакие средства защиты периметра не остановили его, потому что вредоносный код поступил в виде доверенного, подписанного пакета от известного поставщика. Урок в том, что доверие в цепочке поставок необходимо постоянно проверять, а не принимать как должное.

Аттестации, аудиты и соответствие нормативным требованиям

Независимое подтверждение соответствия принимает несколько форм. Отчеты SOC 2 Type II, подготавливаемые лицензированными аудиторскими фирмами по стандартам AICPA, оценивают средства контроля сервисной организации за определенный период (обычно 6–12 месяцев) на соответствие критериям доверительных услуг (Trust Services Criteria). SOC 2 Type I охватывает только один момент времени и является значительно более слабым доказательством. SOC 1 относится к средствам контроля финансовой отчетности; SOC 3 — это общедоступная сводка. Сертификация ISO/IEC 27001 демонстрирует наличие действующей Системы менеджмента информационной безопасности.

Критически важное различие: аттестация — это официальное заявление, иногда сделанное самим поставщиком (самоаттестация), а иногда — независимым аудитором. Самоаттестация поставщика имеет гораздо меньшую доказательную силу, чем отчет о независимом аудите третьей стороны. Запросить «ваш SOC 2» и принять в ответ маркетинговый PDF — частая ошибка при закупках; требуемым артефактом является фактический подписанный отчет от аудиторской фирмы с ее заключением.

Нормативные режимы налагают особые обязательства. PCI DSS регулирует обращение с данными держателей карт и содержит предписывающие технические требования — сегментация сети, ежеквартальные сканирования ASV, ежегодные тесты на проникновение. GDPR устанавливает права для субъектов данных ЕС, требует уведомления об утечке в течение 72 часов и предусматривает штрафы до 4% от годового мирового оборота. HIPAA защищает медицинскую информацию в США, SOX регулирует целостность финансовой отчетности, а GLBA применяется к финансовым учреждениям. Соответствие требованиям — это необходимый минимум, а не предел: соответствие PCI-DSS не означает полную безопасность, а лишь то, что на момент оценки был достигнут определенный базовый уровень.

Практический сценарий: сбой в системе GRC, приведший к штрафу от регулятора

Региональная сеть медицинских учреждений передала свою биллинговую платформу стороннему поставщику, не проведя должной проверки безопасности и не включив в договор пункты о праве на аудит. Поставщик пострадал от инцидента с программой-вымогателем, в результате которого были раскрыты данные 340 000 пациентов. Поскольку сеть медучреждений не провела проверку Соглашения с деловым партнером (Business Associate Agreement, BAA), не имела доказательств наличия у поставщика средств контроля безопасности и не провела оценку рисков, связанных с этими отношениями, HHS OCR признало сеть нарушившей Правило безопасности HIPAA. Итоговое урегулирование включало штраф в размере 1,2 миллиона долларов и двухлетний план корректирующих действий. Технические средства контроля в самой сети медучреждений были адекватными; сбой был полностью на уровне управления — отсутствие программы управления рисками поставщиков, договорных обязательств по безопасности и периодической переоценки. Этот сценарий иллюстрирует, что сбои в GRC — это не абстрактные недостатки в соблюдении требований; они приводят к конкретному, измеримому финансовому и репутационному ущербу.

Все домены · Управление идентификацией и доступом →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →