Физическая безопасность офиса в ВКР по ИБ: модель угроз, СКУД и оценка рисков

Осенью 2024 года офисы Wildberries пережили нападение, а в марте 2026-го суд вынес приговоры — часть участников получила реальные сроки, часть избежала наказания. Юридическая сторона здесь вторична: для ИТ-выпускника это прежде всего инженерный кейс. Офис — это физический периметр, где сходятся СКУД, видеонаблюдение, DLP и корпоративные информационные системы. Провал физической безопасности автоматически означает компрометацию данных, простой бизнеса и прямые потери. Именно поэтому такие инциденты дают готовую фактуру для ВКР по информационной безопасности: модель угроз, проект защиты и расчёт эффективности.

Три темы ВКР, которые вырастают из этой новости

Как встроить кейс в главы работы

Глава 1. Аналитическая: где живёт новость

Открывайте работу не пересказом инцидента, а структурным анализом: какие классы активов (люди, документы, серверные, носители) оказались под риском. Дополните обзор нормативки — ISO/IEC 27005, ГОСТ Р 51558 (видеонаблюдение), NIST SP 800-53 (контроль физического доступа PE-семейства). Обязательно сравните подход «только СКУД» и «СКУД + SIEM + DLP»: именно это сравнение тянет за собой главу 2.

Глава 2. Проектная: диаграммы и архитектура

Здесь нужны конкретные артефакты. Диаграмма C4 (уровни Context и Container) показывает, как контроллер СКУД, IP-камеры, сервер видеонаблюдения и SIEM связаны между собой. UML-диаграмма последовательности опишет сценарий «аварийное открытие двери → событие в SIEM → алерт дежурному». BPMN-схема процесса реагирования даст нормоконтролёру понять, что вы умеете описывать не только код, но и регламенты. Если совсем трудно с графикой — ASCII-схема тоже принимается:

[Турникет/СКУД]--(Wiegand/OSDP)-->[Контроллер]--(TCP/IP)-->[Сервер PACS]
                                                        |
                                                        v
                                              [Коллектор логов]--->[SIEM]
                                                                     |
                                                              [Правила корреляции]
                                                                     |
                                                            [Алерт / Тикет]

Глава 2–3. Реализация: правило корреляции для SIEM

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

def detect_off_hours_anomaly(event, employee, shift):
    """Событие прохода в нерабочее время или вне графика смен."""
    if event.door_type != "office_perimeter":
        return None
    off_hours = event.timestamp.hour not in range(9, 20)
    not_on_shift = employee.id not in shift.active_ids
    if off_hours and not_on_shift:
        return {
            "rule": "PACS_OFF_HOURS_ACCESS",
            "severity": "high",
            "risk_score": 0.8,
            "mitre": "T1078 Valid Accounts"
        }
    return None

Глава 3. Оценка эффективности

Считать «на глазок» — верный путь к замечаниям. Вводите три метрики: MTTD (среднее время обнаружения), MTTR (среднее время реагирования) и Risk Score по каждому сценарию. Данные можно взять из пилотной установки на учебном стенде, из открытых датасетов по физической безопасности или из логов доступа тестового помещения. Сравните «до/после» внедрения правил — это и есть доказательство эффективности.

Чему вы научитесь на такой работе

• Строить модель угроз по ISO/IEC 27005 и связывать её с MITRE ATT&CK.
• Проектировать интеграцию PACS → SIEM через OSDP/Wiegand и коллекторы логов.
• Писать правила корреляции и валидировать их на синтетических событиях.
• Считать MTTD/MTTR и обосновывать эффект количественно.
• Оформлять диаграммы C4/UML и ТЗ по ГОСТ 34.601.

FAQ по защите и реализации

Источник: Нападавшие на офис Wildberries приговорены к реальным срокам заключения (опубликовано 2026-03-25)