Сенсорна мережа, яка вже змонтована на вашому об’єкті
7 класів загроз
Більшість підприємств використовує СКУД як реєстратор: хто зайшов, хто вийшов, табель для бухгалтерії. Журнал подій при цьому росте на десятки тисяч записів на день — і ніхто його не читає, доки не станеться інцидент.
А тепер факт: сучасний контролер доступу генерує 308 типів подій. Проходи за карткою — лише кілька десятків з них. Решта — це сигнали про обхід, саботаж, примус, підбір ідентифікаторів, маніпуляції з обладнанням і сліпі зони. Тобто журнал СКУД — це готова сенсорна мережа безпеки, яка вже змонтована на вашому об’єкті й уже пише дані.
Питання лише одне: чи вміє ваша система ці сигнали читати.
Ми проаналізували повний довідник подій BioStar 2 і згрупували загрози, які видно в журналі, у сім класів. Для кожного — конкретні події, які його викривають, і звіт, який перетворює розрізнені записи на висновок для служби безпеки.
Клас 1. Обхід контролю доступу
Загроза. Прохід без ідентифікації: охоронець відкриває турнікет педаллю «за домовленістю», планку притримують для проходу «паровозиком», двері фізично відчиняють в обхід зчитувача.
Що видно в журналі. Контролер розрізняє ці сценарії окремими подіями: EXIT_BUTTON — легальне ручне відкриття кнопкою; FORCED_OPEN — проворот без картки і без кнопки; HELD_OPEN — утримання відкритим довше таймауту. Ключова умова — сигнал кнопки має бути заведений через контролер, а не напряму на плату турнікета (детальний розбір монтажу — в окремій статті про змову з охороною).
Як ловимо. Звіт ручних відкриттів у розрізі точок проходу і дат: аномалія видна миттєво — на одній прохідній 2 відкриття на день, на іншій 27. Кожна подія FORCED_OPEN — окремий інцидент з негайним оповіщенням.
Клас 2. Саботаж самої системи контролю
Загроза. Найнебезпечніший порушник — той, хто атакує не двері, а систему обліку: перерізає лінію кнопки, розкриває корпус контролера, чистить журнал подій, переводить годинник термінала, скидає пристрій до заводських налаштувань. Мета одна — щоб потрібний прохід не залишив сліду або залишив слід з «правильним» часом.
Що видно в журналі. TAMPER_ON — розкриття корпусу; SUPERVISED_INPUT_SHORT / OPEN — закорочена або перерізана лінія (входи з кінцевими резисторами бачать саботаж кабелю); EVENT_LOG_CLEARED — очищення журналу; TIME_SET — зміна часу пристрою; FACTORY_RESET, DATABASE_RESET — скидання; невдалі спроби входу в адмін-меню термінала.
Як ловимо. Кожна подія цього класу — інцидент рівня P1 з оповіщенням. Очищення лога чи переведення часу на терміналі не має жодного штатного пояснення в нормальній експлуатації — це завжди привід для розбору.
Клас 3. Атаки на ідентифікацію
Загроза. Підбір чужої картки чи PIN, спроба пройти за муляжем відбитка, дублікати біометрії (той самий палець на двох облікових записах — «подвійна особистість»), і системна слабкість — двері, де за політикою потрібна двофакторна ідентифікація, а фактично всі ходять за самою карткою.
Що видно в журналі. Серія VERIFY_FAIL_* на одному пристрої за короткий час — підбір. FAKE_FINGERPRINT_DETECTED — спрацював anti-spoofing: хтось приклав підробку. DUPLICATE_FINGERPRINT / FACE / CARD — дубль ідентифікатора. А співвідношення VERIFY_SUCCESS_CARD до подій з біометрією показує реальну, а не задекларовану політику доступу.
Як ловимо. Два звіти. «Сплески відмов»: пристрої та години, де кількість невдалих спроб перевищила поріг — з розділенням карткових відмов (підбір) і біометричних (деградація сенсора — інша реакція). І «Структура ідентифікації»: двері сортуються за кількістю однофакторних проходів — кандидати на посилення політики видно з першого рядка.
Клас 4. Прохід під примусом
Загроза. Співробітника змушують відкрити двері — під фізичною загрозою. Він не може натиснути тривожну кнопку: нападник поруч і все бачить.
Що видно в журналі. BioStar 2 підтримує duress-ідентифікацію: заздалегідь призначений «палець примусу». Співробітник прикладає його — двері відчиняються абсолютно штатно, нападник нічого не помічає, але в систему летить подія VERIFY_DURESS_* — тиха тривога.
Як ловимо. Це не звіт — це інцидент найвищого пріоритету P0 з негайним оповіщенням посту охорони та керівника СБ. Затримка реакції тут вимірюється секундами, тому такі події мають йти через подієву шину в реальному часі, а не чекати регламентного звіту. Про duress-функцію знають одиниці служб безпеки — при тому, що вона вже є у терміналах, які стоять на об’єктах.
Клас 5. Інсайдерські зловживання
Загроза. Порушник з легальними правами: оператор системи, який відкриває двері з програми «для своїх»; адміністратор, що заводить ідентифікатор прямо на терміналі в обхід центральної системи; змова на прохідній.
Що видно в журналі. OPERATOR_OPEN та RELEASE / UNLOCK_DOOR_BY_OPERATOR — дистанційні відкриття з ПЗ, кожне з прив’язкою до облікового запису оператора. ENROLL / UPDATE / DELETE_USER з кодом пристрою — облікові записи, створені на терміналі, а не в центрі. У поєднанні з журналом дій операторів самої системи виходить повний аудит: хто, коли, що і звідки.
Як ловимо. Звіт відкриттів операторами + звіт операцій з ідентифікаторами на пристроях. Принцип той самий, що з кнопкою охорони: дистанційне відкриття не заборонене — але кожне залишає слід, і аномальна частота видна у зведенні.
Клас 6. Сліпі зони
Загроза. Найпідступніший клас: поки пристрій офлайн — журнал мовчить. Втрата зв’язку, відключення живлення, севша батарея, збій запису відео — і на об’єкті з’являється вікно часу, за яке система не може поручитися. Іноді такі вікна створюють навмисно.
Що видно в журналі. Пари *_CONNECTED / DISCONNECTED для кожного каналу зв’язку (мережа, RS-485, відеопотік), AC_FAIL — перехід на батарею, події рівня заряду, і окремо — REC_FINISHED_FAIL / SNP_SHOT_FINISHED_FAIL: прохід відбувся, а відеокадр до нього не записався. Тобто система знає навіть про те, що доказова база неповна.
Як ловимо. Звіт «Сліпі зони»: тривалість офлайн-вікон по кожному пристрою за період + збої відеофіксації. Пристрій, який «моргає» щоночі о третій, — привід перевірити не лише кабель.
Клас 7. Розвідка периметра
Загроза. Перед спробою проникнення периметр «промацують»: чужа картка на різних дверях, спроби в неробочий час, систематичні відмови одній особі в одній зоні.
Що видно в журналі. Група ACCESS_DENIED_* — понад двадцять причин відмови: прострочена картка, чорний список, чужа зона доступу, порушення anti-passback, заборонений час. Кожна відмова — точка даних. Повторювані відмови одного суб’єкта на одній точці — вже траєкторія.
Як ловимо. Зведення відмов за причинами + звіт «повторні порушники»: суб’єкти з кількома інцидентами різних типів за період. Людина, яка тричі за тиждень «помилилася дверима» серверної, помиляється не випадково.
Від журналу до керування інцидентами
Сім класів — це не сім окремих інструментів. У «Логін» вони працюють як єдиний конвеєр:
- Класифікація. Кожна подія з контролерів отримує категорію і рівень серйозності: P0 — примус, муляж, пожежа, вторгнення; P1 — обхід, саботаж, атаки на журнал; P2 — порушення режиму, ручні відкриття, відмови.
- Інциденти. Проблемні події матеріалізуються в реєстр інцидентів зі статусами: новий → у роботі → закритий з резолюцією. СБ працює не з логом на мільйони рядків, а з чергою конкретних питань.
- Реальний час. P0/P1 не чекають звіту: подієва шина доставляє тривогу на пост охорони і в месенджер керівника СБ за секунди після події.
- Метрики. Час реакції на інциденти за рівнями — SLA служби безпеки стає вимірюваним, як SLA ІТ-підтримки.
І принциповий момент: усе перелічене будується на штатних подіях BioStar 2 — без додаткових датчиків, без заміни обладнання. Термінали, які вже стоять на вашому об’єкті, вже генерують ці сигнали. Різниця між «СКУД для табеля» і «системою безпеки» — не в залізі, а в шарі аналітики над журналом.
Перевірте свій об’єкт: п’ять питань
- Чи побачить ваша СБ, якщо охоронець відкриє турнікет педаллю? Через скільки?
- Чи налаштований «палець примусу» хоч у когось із співробітників критичних зон?
- Хто отримає сповіщення, якщо на терміналі очистять журнал або переведуть час?
- Скільки годин на місяць ваші пристрої проводять офлайн — і чи знаєте ви це число?
- Скільки проходів у критичні зони за минулий місяць були однофакторними?
Якщо хоча б на два питання відповідь «не знаємо» — журнал вашої СКУД знає більше, ніж ваша служба безпеки. Ми допоможемо це виправити.