Вопросы кибербезопасности еще никогда не были так глубоко вплетены в проектирование классических систем физической безопасности, как сегодня. Крупные предприятия, выбирающие системы контроля и управления доступом (СКУД) или интегрированные системы безопасности (ИСБ), особенно в банковском секторе, все чаще предъявляют требования, которые еще 3–4 года назад казались бы беспрецедентными.
Авторы:
Алексей Лагойко, технический директор, ООО "КомплИТех"
Ольга Федосеева, директор по продукту, ООО "КомплИТех"
Алексей Лагойко, технический директор, ООО "КомплИТех"
Ольга Федосеева, директор по продукту, ООО "КомплИТех"
Защищенность СКУД и ИСБ становится не просто формальным техническим аспектом, а стратегическим требованием, которое должно учитываться на всех этапах жизненного цикла систем безопасности — от разработки до эксплуатации. Нарушение этих требований чревато серьезными последствиями — о чем свидетельствуют реальные кейсы, демонстрирующие уязвимости в системах безопасности по всему миру.
Громкие кибератаки на системы безопасности
В последние годы была задокументирована масса реальных инцидентов, связанных с нарушением кибербезопасности в СКУД, системах видеонаблюдения, системах управления и других корпоративных информационных системах, связанных с решением задач безопасности, в разных странах. Приведенные ниже примеры наглядно демонстрируют риски, с которыми сталкиваются заказчики, и подчеркивают важность внедрения комплексных мер защиты.
Кибератака на СКУД в больнице (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 также отсутствовали возможности отслеживания местоположения, навигации и уведомления о предполагаемом времени прибытия. (Источник)
Кибератака на СКУД в больнице (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 также отсутствовали возможности отслеживания местоположения, навигации и уведомления о предполагаемом времени прибытия. (Источник)
Согласно отчету 2023 World Security Report, каждая четвертая компания (25%) сообщила о снижении своей рыночной стоимости после внутреннего или внешнего инцидента безопасности в 2022 году. На 2023 год 36% респондентов прогнозировали утечку конфиденциальной информации как крупнейшую внутреннюю угрозу, а 25% CSO считали, что мошенничество станет наиболее значимой внешней угрозой. Ожидание роста угроз со стороны хакеров и экономических преступников выросло на 39% по итогам предыдущего года.
В исследовании приняли участие 1775 директоров по безопасности (CSO) или лиц, занимающих аналогичные должности, из 30 стран, представляющих крупные компании с совокупной годовой выручкой более 20 триллионов долларов, что составляет четверть мирового ВВП. Участие CSO было анонимным и независимым.
Чеклист мер киберзащиты
В дополнение к общепринятым принципам (ролевая модель управления пользователями, контроль паролей, авторизация запросов по API, логирование действий пользователей и др.) представляем чеклист критически важных мер обеспечения безопасности СКУД и ИСБ. Это перечень мер – от архитектуры программного обеспечения и шифрования до управления критически важными данными и оптимизации доступа, – без которых внедрение таких систем уже сейчас представляется беспечным решением.
Первое – правильная архитектура ПО. Под этим подразумевается разграничение доступа к информации на основе логических уровней:
Клиенты должны взаимодействовать только с сервером приложений через API. Прямой доступ клиентов к БД следует исключить – никаких запросов напрямую, особенно в незашифрованным виде, как это бывает с "толстыми" клиентами. Связь между клиентами и БД должна быть закрыта.
Второе – обязательное шифрование данных на всех уровнях. Включая обмен данными между клиентом и сервером, а также между серверными компонентами. В качестве алгоритмов шифрования следует применять современные протоколы, такие как TLS.
Третье – использование специализированных инструментов для безопасного хранения и управления "секретами" (логины, пароли, ключи шифрования, токены API и другие конфиденциальные данные). Это критически важная информация, которая в случае компрометации позволит несанкционированно подключиться к системе.
Четвертое – запрет на наличие скрытых механизмов обхода безопасности в ПО (бэкдоров). Не должно быть системных учетных записей ("вшитых пользователей"), которые имеют доступ к программному обеспечению по умолчанию.
Пятое – применение алгоритмов шифрования, а также двусторонней аутентификации между сервером и контроллерами, например с использованием протокола EAP-TLS (802.1X).
Шестое – поддержка цифрового протокола OSDP для зашифрованной двусторонней связи между контроллерами и считывателями, что повышает безопасность по сравнению с устаревшими протоколами, такими как Wiegand, где данные передаются в незащищенном виде.
Седьмое – продуманный механизм эмиссии карт доступа. Если ключ шифрования на считывателе скомпрометирован (например, вследствие взлома), возникают две критические задачи. Одна из них – корректная замена ключей. Многие считыватели не поддерживают смену ключей через OSDP, что приводит к необходимости использования собственных, зачастую неудобных решений. Другая – что делать с картами пользователей? В большинстве случаев все карты доступа блокируются и пользователи должны явиться в бюро пропусков для перезаписи ключей шифрования. А если речь идет о 10 тысячах сотрудников? А если это 200 тысяч?
Первое – правильная архитектура ПО. Под этим подразумевается разграничение доступа к информации на основе логических уровней:
- уровень представления, или клиентское ПО (обеспечивает взаимодействие с пользователем);
- уровень приложений, или сервер приложений (получает и обрабатывает информацию, контролирует к ней доступ);
- уровень баз данных (БД), или сервер СУБД.
Клиенты должны взаимодействовать только с сервером приложений через API. Прямой доступ клиентов к БД следует исключить – никаких запросов напрямую, особенно в незашифрованным виде, как это бывает с "толстыми" клиентами. Связь между клиентами и БД должна быть закрыта.
Второе – обязательное шифрование данных на всех уровнях. Включая обмен данными между клиентом и сервером, а также между серверными компонентами. В качестве алгоритмов шифрования следует применять современные протоколы, такие как TLS.
Третье – использование специализированных инструментов для безопасного хранения и управления "секретами" (логины, пароли, ключи шифрования, токены API и другие конфиденциальные данные). Это критически важная информация, которая в случае компрометации позволит несанкционированно подключиться к системе.
Четвертое – запрет на наличие скрытых механизмов обхода безопасности в ПО (бэкдоров). Не должно быть системных учетных записей ("вшитых пользователей"), которые имеют доступ к программному обеспечению по умолчанию.
Пятое – применение алгоритмов шифрования, а также двусторонней аутентификации между сервером и контроллерами, например с использованием протокола EAP-TLS (802.1X).
Шестое – поддержка цифрового протокола OSDP для зашифрованной двусторонней связи между контроллерами и считывателями, что повышает безопасность по сравнению с устаревшими протоколами, такими как Wiegand, где данные передаются в незащищенном виде.
Седьмое – продуманный механизм эмиссии карт доступа. Если ключ шифрования на считывателе скомпрометирован (например, вследствие взлома), возникают две критические задачи. Одна из них – корректная замена ключей. Многие считыватели не поддерживают смену ключей через OSDP, что приводит к необходимости использования собственных, зачастую неудобных решений. Другая – что делать с картами пользователей? В большинстве случаев все карты доступа блокируются и пользователи должны явиться в бюро пропусков для перезаписи ключей шифрования. А если речь идет о 10 тысячах сотрудников? А если это 200 тысяч?
Если вы хотите задать вопрос либо изучаете рынок на предмет защищенных систем контроля и управления доступом (СКУД) или программных платформ для управления комплексными системами безопасности (КСБ), напишите Ольге Федосеевой по email.
Перепечатка, воспроизведение, распространение или цитирование данного материала (полностью или частично) без предварительного письменного разрешения правообладателя запрещены.