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