Вопросы кибербезопасности, от которых больше не отмахнуться

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

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

Кибератака на СКУД в больнице (2016 год)

В 2016 году больница в Лос-Анджелесе подверглась атаке с использованием вируса-вымогателя, целью которой стали серверы системы контроля доступа. Электронные пропуска, которые обеспечивали открывание/закрывание дверей, перестали работать. Это коснулось операционных, палат для пациентов и других зон. Сотрудникам пришлось вручную проверять удостоверения личности и открывать двери, в ряде случаев было принято решение и вовсе держать двери открытыми. (Источник)

Взлом системы Biostar 2 компании Suprema (2019 год)

В августе 2019 года исследователи из израильской компании vpnMentor обнаружили уязвимость в биометрической системе контроля доступа Biostar 2, разработанной компанией Suprema. Эта уязвимость позволяла получить доступ к базам данных СКУД без аутентификации, что привело к компрометации данных более 1 миллиона пользователей, включая отпечатки пальцев, фотографии лиц, имена пользователей и пароли. Система Biostar 2 использовалась в различных организациях по всему миру, включая правительственные учреждения и банки. (Источник)

Атака на систему видеонаблюдения Verkada (2021 год)

В марте 2021 года хакерская группа получила доступ к внутренним системам компании Verkada, производителя камер видеонаблюдения, и получила доступ к более чем 150 000 камерам, установленным в различных организациях, включая больницы, тюрьмы и школы. Злоумышленники смогли просматривать живые видеопотоки и загружать архивные записи, что вызвало серьезные опасения по поводу конфиденциальности и безопасности данных. (Источник)

Кибератака на пожарную службу Fire Rescue Victoria (2022 год)

В декабре 2022 года пожарная служба Fire Rescue Victoria (FRV) в Австралии подверглась кибератаке, которая нарушила работу системы диспетчеризации и затруднила доступ пожарных к информации об инцидентах. В результате атаки FRV была вынуждена использовать альтернативные методы связи, такие как мобильные телефоны, пейджеры и радиосвязь, для координации действий пожарных бригад. Сообщалось также о хищении персональных данных сотрудников FVR. (Источник)

Взлом системы точного позиционирования Microlise (2024)

В октябре 2024 года кибератаке подверглась система точного позиционирования транспортных средств производства британской компании Microlise. Пострадавшими от кибератаки стали правительственный подрядчик Serco, предоставляющий услуги по сопровождению заключенных для Министерства юстиции, и курьерская служба DHL. В результате инцидента фургоны компании Serco, ежегодно перевозящий более 300 000 заключенных, в течение нескольких дней перемещались по стране без отслеживания местоположения, тревожной сигнализации (panic button), навигации и уведомления о предполагаемом времени прибытия. У части автомобилей экспресс-почты DHL также отсутствовали возможности отслеживания местоположения, навигации и уведомления о предполагаемом времени прибытия. (Источник)

В дополнение к общепринятым принципам (ролевая модель управления пользователями, контроль паролей, авторизация запросов по API, логирование действий пользователей и др.) представляем чеклист критически важных мер обеспечения безопасности СКУД и ИСБ. Это перечень мер – от архитектуры программного обеспечения и шифрования до управления критически важными данными и оптимизации доступа, – без которых внедрение таких систем уже сейчас представляется беспечным решением.

Первое – правильная архитектура ПО. Под этим подразумевается разграничение доступа к информации на основе логических уровней:

• уровень представления, или клиентское ПО (обеспечивает взаимодействие с пользователем);
• уровень приложений, или сервер приложений (получает и обрабатывает информацию, контролирует к ней доступ);
• уровень баз данных (БД), или сервер СУБД.

Клиенты должны взаимодействовать только с сервером приложений через API. Прямой доступ клиентов к БД следует исключить – никаких запросов напрямую, особенно в незашифрованным виде, как это бывает с "толстыми" клиентами. Связь между клиентами и БД должна быть закрыта.

Второе – обязательное шифрование данных на всех уровнях. Включая обмен данными между клиентом и сервером, а также между серверными компонентами. В качестве алгоритмов шифрования следует применять современные протоколы, такие как TLS.

Третье – использование специализированных инструментов для безопасного хранения и управления "секретами" (логины, пароли, ключи шифрования, токены API и другие конфиденциальные данные). Это критически важная информация, которая в случае компрометации позволит несанкционированно подключиться к системе.

Четвертое – запрет на наличие скрытых механизмов обхода безопасности в ПО (бэкдоров). Не должно быть системных учетных записей ("вшитых пользователей"), которые имеют доступ к программному обеспечению по умолчанию.

Пятое – применение алгоритмов шифрования, а также двусторонней аутентификации между сервером и контроллерами, например с использованием протокола EAP-TLS (802.1X).

Шестое – поддержка цифрового протокола OSDP для зашифрованной двусторонней связи между контроллерами и считывателями, что повышает безопасность по сравнению с устаревшими протоколами, такими как Wiegand, где данные передаются в незащищенном виде.

Седьмое – продуманный механизм эмиссии карт доступа. Если ключ шифрования на считывателе скомпрометирован (например, вследствие взлома), возникают две критические задачи. Одна из них – корректная замена ключей. Многие считыватели не поддерживают смену ключей через OSDP, что приводит к необходимости использования собственных, зачастую неудобных решений. Другая – что делать с картами пользователей? В большинстве случаев все карты доступа блокируются и пользователи должны явиться в бюро пропусков для перезаписи ключей шифрования. А если речь идет о 10 тысячах сотрудников? А если это 200 тысяч?

Перепечатка, воспроизведение, распространение или цитирование данного материала (полностью или частично) без предварительного письменного разрешения правообладателя запрещены.