Современная государственная организация производит большое количество решений, для оперативного принятия которых неизбежно предоставление удаленного доступа к ИТ-сервисам организации. Удаленный доступ на практике превращается в мобильный доступ — ведь современные смартфоны поддерживают любые технологии удаленного доступа, и принадлежащая государству информация начинает перетекать в многоугольнике — периметр организации, домашняя ИТ-инфраструктура, рабочий ноутбук и личный смартфон сотрудника.
В такой сложной конфигурации немудрено запутаться даже первым лицам — что и произошло с Хиллари Клинтон (в том время госсекретарем — руководителем министерства иностранных дел США). Она использовала личную почту для хранения служебной переписки, более 2000 писем из которой после обнаружения получили тот или иной гриф секретности.
Клинтон можно понять — без удобного удаленного доступа к почте и календарю уже не мыслит себя ни один руководитель, а большое количество специализаций сотрудников, командировки в регионы и районы приводят к необходимости иметь доступ и к информационным системам из любой точки страны или региона.
Налево пойдешь — коня потеряешь..
Перед формированием «правил жизни» — установления порядка обращения сотрудников с мобильной информацией, разработкой архитектуры кибербезопасности — нужно определиться со стратегией.
Как и в известной сказке в силу специфики сектора государственного управления стратегий всего три: «открытая», «формальная» и «полная». За скобки сразу вынесем защиту государственной тайны, так как обработка государственной тайны требует защищенного помещения, а значит концептуально плохо совместима с мобильностью ИТ-сервисов.
«Открытая» стратегия подразумевает прямой и недвусмысленный юридически значимый запрет сотрудникам организации передавать какие-либо конфиденциальные сведения за ее периметр. Реализовать запрет на уровне техники довольно трудно, но это и не главное. Главное — запрет должен быть юридически корректно оформлен и доведен до всех сотрудников организации (под роспись, а в идеале — как часть регулярного контроля знаний по кибербезопасности). С большой долей вероятности сотрудники технически все еще смогут получить доступ к конфиденциальным сведениям по удаленным каналам, но если в организации игнорируются указания руководителя — у нее есть гораздо более существенные проблемы, чем кибербезопасность.
«Формальная» стратегия ориентирована исключительно на требования регуляторов в области технической и криптографической защиты конфиденциальной информации (ФСТЭК и ФСБ соответственно). Практически в любой государственной организации уже существует некий задел по теме соответствия нормативным требованиям по защите конфиденциальной информации, остается масштабировать существующие практики на новые каналы передачи, места обработки и хранения информации. Отдельно отмечу, что «конфиденциальная информация» (в просторечьи — КИ) — это закрытый перечень информации: персональные данные, тайна следствия и ряд других охраняемых законом тайн. Конфиденциальной с точки зрения руководителя может быть совсем другая информация, и с технической точки зрения лучше ее защищать, не привлекая всю громаду нормативных требований.
«Полная» стратегия будет выбором государственных организаций, которым по тем или иным причинам кибербезопасность жизненно важна. Например, они могут предоставлять жизненно важные для граждан сервисы, обрабатывать значимое количество финансовых данных или интеллектуальной собственности коммерческих предприятий, быть соединенными с десятками «третьих сторон» (у каждой из которых могут быть свои проблемы безопасности). Таким организациям кроме выполнения требований регуляторов (исторически нацеленных на обеспечение конфиденциальности сведений) показан аудит микса ИТ-сервисов и устройств доступа, выработка целостной и комплексной архитектуры кибербезопасности для защиты ключевых активов компании.
Нам нечего скрывать, или «открытая» архитектура
«Открытая» архитектура (ОА) нацелена на обеспечение доступности и достоверности информации организации, ведь мобильность может быть не только каналом утечки но и точкой входа в ИТ-сервисы организации. Представим лишь, что потерянный пресс-секретарем ведомства ноутбук был использован для отправки в адрес деловых изданий «официального» заявления ведомства с компрометирующей руководителя информацией.
В последние
Соответственно, ОА состоит из пяти блоков — аудит, защита, мониторинг, реагирование и восстановление. Кстати, практики обеспечения пожарной безопасности в государстве де факто аналогичны — есть и инспекция (аудит), и защита (выполнение требований), и мониторинг (на основе осведомленности и сигналов граждан), и реагирование и восстановление — пожарные команды и помощь пострадавшим.
Блок «аудит» ОА направлен на прояснение состояния дел во всех сегментах информационной системы предприятия:
1) пользователи — что они обязаны делать и что знают (стандарты, политики, обучение и тестирование знаний);
2) учетные записи — каковы парольные политики (сложность пароля, частота смены пароля, есть ли блокировка после неправильного ввода);
3) каналы доступа к сервисам — предусмотрено ли шифрование передачи данных между ядрами сервисов и устройствами доступов;
4) устройства доступа — установлены ли унифицированные стандарты безопасности устройств доступа (ПК, ноутбуков) — антивирусы, шифрование мобильных устройств доступа, обязательность установки исправлений (патч-менеджмент);
5) ядра сервисов — проводился ли аудит безопасности при выводе сервисов в Интернет, включены ли журналы событий для обеспечения возможности расследования в будущем.
Подчеркну, что фактически мобильные ИТ-сервисы могут быть расположены и за периметром организации (в свое время СМИ сообщали, что значимый процент контактных адресов тендеров госзакупок расположен у внешних провайдеров электронной почты). В рамках ОА внешние сервисы разумно приравнять к внутренним, реализуя ОА в той части, где это возможно и рационально (например, где-то защищать данные ключевых сотрудников, а где-то — настаивать на использовании корпоративного сервиса).
Блок «защита» ОА направлен на повышение кибербезопасности во всех пяти сегментах той информационной системы предприятия, что будет «мобилизирована»:
· сегмент «пользователи» — разработка и внедрение политики прав и обязанностей мобильных пользователей. Среди классических рекомендаций — не использовать публичные Wi-Fi-cети (без шифрования), закрывать клавиатуру при вводе пароля, оперативно сообщать о пропаже устройства доступа с подключенными ИТ-сервисами организации, а также о компрометации паролей или токенов доступа;
· сегмент «учетные записи» — учетные записи пользователей мобильных ИТ-сервисов доступа должны быть защищены строгими парольными политиками (например, Group Policy, ActiveSync) и многофакторной аутентификацией. Двухфакторная аутентификация должна быть совместима с международными протоколами WS-Federation или OAuth. В случае отсутствия финансовых возможностей для реализации двухфакторной аутентификации обязательно внедрение компенсирующей меры — политики блокировки учетной записи после определенного количества попыток. Такая политика имеет побочный эффект — можно вызвать перебои в обслуживании с помощью ложной атаки. Но учитывая возможность перебирать пароли доступа в организацию 24 часа 365 дней в году, другой альтернативы может не быть. Для снижения связанных с потерями устройств рисков отмечу полезность и политики требования ввода пароля после определенного периода ожидания;
· сегмент «каналы доступа» — каналы доступа должны использовать шифрование (S\MIME, VPN-клиент, VPN-туннель
· сегмент «устройства доступа» — устройства доступа к ИТ-сервисам должны быть защищены не хуже стационарных ПК, как минимум должен быть установлен пароль доступа к устройству, использоваться встроенное шифрование накопителей на платформах iOS\OS X\Windows\Android, сильные парольные политики (локальные учетные записи, PIN Security);
· сегмент «ядра сервисов» — ядра сервисов нужно строить на поддерживаемых производителем технологиях (никаких End of Support!). Желательно использовать новейшие технологии (в них обычно больше встроенных технологий безопасности, например, Windows 10 включает технологию Credential Guard, эффективно противодействующую «бичу» Windows-инфраструктур — классической атаке Pass-the-Hash).
Перед выводом сервисов в Интернет нужно проводить аудит их безопасности — хотя бы бесплатными сканерами Microsoft MBSA, OpenVAS, а критичные сервисы проверять на соответствие требованиям безопасности производителей (все крупные вендоры имеют т. н. Security Guides) и/или передовым практикам (например, классическим CIS). Для обеспечения возможности последующего мониторинга и расследования нужно настраивать системы логирования в ядрах сервисов.
Сквозной мерой для всех сегментов будет планирование и реализация процедур резервного копирования данных.
Блок «мониторинг» ОА направлен на понимание текущей ситуации с кибербезопасностью мобильных ИТ-сервисов. Идентифицировать проблему можно через сигналы от пользователей по итогам потери, по итогам странного поведения ИТ-сервисов (например, внезапной блокировки учетной записи из-за одноразового неправильного ввода пароля), через выявление попыток брутфорса (например, при помощи периодического использования скриптов).
Блок «реагирование» ОА структурирован на основе простых сценариев из жизненного цикла устройств доступа:
1) потеря устройства. Нужно сменить пароли к сервисам, заблокировать доступ устройства к сервисам и сделать full wipe (если устройство корпоративное);
2) аномалия в ИТ — странное поведение ИТ-сервиса/попытка взлома методом брутфорса. Нужно сменить пароли, выявить источник брутфорса, временно поменять антивирус на устройствах доступа (выявить вирусы, что невидимы для текущего антивируса), провести дальнейшее расследование. Возможно ужесточить парольную политику или отключить старые неиспользуемые сервисные учетные записи (частая причина неудачных попыток входа в домен).
Блок «восстановление» ОА — провести инструктаж пользователя. Выдать ему новые учетные данные, возможно выдать новое корпоративное устройство. В случае необходимости — восстановить данные из резервных копий. Желательно провести анализ причин инцидента, извлечь уроки — разработать и внедрить корректирующие меры.
ОА подразумевает максимально возможное использование встроенных мер кибербезопасности популярных платформ и мобильных сервисов (например, возможностей по удаленному стиранию данных Microsoft Exchange ActiveSync). В случае недостаточности встроенных мер можно приобрести отдельные средства защиты. При отсутствии финансовой возможности приобретения коммерческих средств защиты (например, провайдеров многофакторной аутентификации) можно использовать Open Source (например, Gluu). Впрочем, за использование Open Source придется дополнительно заплатить временем сотрудников.
В зависимости от степени готовности и размера организации проект по реализации ОА может быть реализован за несколько недель или месяцев, часто без выделения дополнительных бюджетных средств.
«Ты регулятор — я дурак», или «формальная» архитектура
«Формальная» архитектура (ФА) ориентирована на выполнение требований ФСТЭК и ФСБ в рамках их компетенции — технический и криптографической защиты конфиденциальной информации. Увы, для государственных органов реализация требований возможна только с применением т. н. сертифицированных средств защиты, что выливается в ограничение выбора средств защиты, проблемы с их обновлениями и в целом в большие управленческие сложности с поддержанием системы кибербезопасности в актуальном угрозам «живом» и меняющемся состоянии.
Поэтому соответствие требованиям регуляторов остается во многом вещью в себе, что де факто помогает реализовать сдвиг ответственности от организации к регуляторам, но недостаточно для снижения актуальных рисков.
Соответственно, ФА может состоять из ОА (всех пяти блоков) + блок выполнения требований регуляторов. В частности, выполнения приказа № 17 ФСТЭК России «О защите государственных информационных систем» и меры ЗИС 30 «Защита мобильных технических средств» Методического документа по приказу № 17 ФСТЭК России.
Методический документ довольно детален, на рынке есть достаточно компаний-проектировщиков системы защиты, представлен ряд сертифицированных средств защиты для ноутбуков, смартфонов и планшетов — с выполнением требований регуляторов принципиальных сложностей в общем случае возникнуть не должно. Кроме экзотических вариантов — например, использования несертифицированного Linux.
В зависимости от степени готовности и размера организации проект по реализации ФА может быть реализован за срок от года, и без выделения дополнительных существенных бюджетных средств никак не обойтись — сертифицированные средства защиты недешевы.
Для самых «буйных», или «полная» архитектура
«Полная» архитектура (ПА) подразумевает снижение реальных рисков кибербезопасности. А это возможно только когда сотрудники добровольно делают выбор использовать защищенные решения (безопасность становится удобной), поэтому стандартные блоки включают широкий набор защищенных сервисов, что сможет заместить «теневые ИТ» контролируемыми корпоративными практиками. Вместе с этим риски, которые снижаются мерами ОА, никуда не денутся — поэтому ПА функционирует как ОА + дополнительные блоки: «защита», «реагирование» и «восстановление» (блоки «аудит» и «мониторинг» в целом одинаковы у обеих архитектур).
Блок «защита» ПА в первую очередь формирует новые безопасные сервисы — «корпоративный Dropbox» (EFSS — enterprise file synchronization service), корпоративную почту, а после формирования публикует их в Интернете удобным образом и обучает пользователей работе с ними. Например, электронную почту можно опубликовать, используя application proxy или terminal services от различных производителей. В идеале вся информация, что нужна пользователям в мобильном режиме, должна циркулировать исключительно внутри корпоративных удобных и защищенных сервисов.
Сегмент «пользователи» — крайне важная формализация целей, задач и ограничений мобильной безопасности возможна через создание и введение в действие политики мобильной безопасности, определяющей подход к мобильности (BYOD/COPE), баланс интересов организации и пользователей. Для обучения пользователей возможно создание и введение в действие правил использования мобильных технологий (как отдельного документа либо раздела правил допустимого использования корпоративных ИТ-активов), однако правила могут быть частью политики мобильной безопасности. Оптимально все же разделять политику и правила, так как они служат разным целям и должны быть написаны разными языками. Политика — формальным, правила — понятным пользователям без ИТ-образования и без понимания стратегических целей организации.
Для крупных организаций (10 000+ пользователей) рационально создание механизма проверки знаний пользователями правил использования при получении доступа к мобильным сервисам, а также места для хранения доказательств согласия пользователей (на случай проверок аудита, внешних сторон или необходимости увольнения сотрудника из-за нарушения).
Сегмент «устройства доступа» — для упорядочения парка мобильных устройств и сервисов разумно создать стандарт корпоративной мобильности: какие сервисы и модели мобильных устройств допустимы в организации, какие технические меры применяются для защиты мобильных устройств. Лучшие мировые практики (европейские, американские и австралийские) рекомендуют типовой набор технических мер защиты:
1) управление аналогично рабочему месту (наличие антивируса, установка, удаление и контроль приложений или настроек) либо наличие защищенного изолированного контейнера с корпоративной информацией и сервисами (обычно в составе
2) перед подключением в сеть необходимо пройти health check (обновлен ли антивирус, установлены ли обновления, включено ли шифрование, нет ли jailbreak, установлен ли PIN). Для этого можно внедрить технологии NAC, 802.1x, MDM;
3) публикация приложений с помощью application proxy позволит уменьшить возможный поток информации к пользователю, снизить риск выгрузок и хищения пользователем информации (пользователь получит только картинку).
Блок «мониторинг» ПА — мониторинг на уровне ПА должен становиться уже проактивным. Проактивное планирование плана сбора событий, настройка правил контроля аномальной активности позволят быстрее выявлять и быстрее реагировать, а значит уменьшить ущерб от инцидентов кибербезопасности. Хорошими помощниками в этом деле стали технологии классов Log management/SIEM.
Блок «реагирование» ПА — к ранее описанным сценариям добавится третий — реагирование на утечку информации с умыслом или по неосторожности пользователя. Такие инциденты лучше начинать расследовать со съема максимально возможного количества журналов событий, анализа действий пользователя, ведь именно от наличия умысла пользователя зависит, есть ли необходимость применять к нему административные меры. Мероприятия по зачистке доступа пользователя в сеть описаны в ОА, для проштрафившегося пользователя возможно также провести внеочередную сертификацию — проверку доступов, тем самым снизив уровень его доступа к корпоративной информации до минимально нужного для работы значения.
В зависимости от степени готовности и размера организации проект по реализации ПА может быть реализован за срок от года, он потребует выделения дополнительных существенных бюджетных средств (сертифицированные средства защиты недешевы). Впрочем, ПА дает и побочный эффект — видя столь существенное внимание руководства организации к кибербезопасности проверяющие могут закрыть глаза на определенные недостатки, что при умелом руководстве программой безопасности может сделать ПА более экономически эффективной, чем ФА.
При отсутствии финансовой возможности приобретения коммерческих средств защиты (например систем log management/SIEM) можно использовать Open Source (например, ELK, OSSIM). Однако, выбор ПА подразумевает рациональность бюджетных инвестиций в кибербезопасность мобильных ИТ-сервисов. Закон «сохранения энергии» неумолим — линию между углами безопасность, удобство и экономичность возможно провести только одну, и нужно выбрать две из трех. Однако у организаций и руководителей, что настроены на долгосрочную работу, успешную конкуренцию в электоральном и политическом поле, обеспечение стабильности и достоверности федеральных и региональных государственных услуг, такого выбора нет. Опыт Клинтон, Бреннан (директор ЦРУ, пострадавший от утечки в
Отдельным интересным ходом может быть использование аттестованного по требованиям регуляторов и дополнительно защищенного российского облака в качестве защищенной инфраструктуры для ядер мобильных ИТ-сервисов. Это может высвободить время и средства организации для более интересных, чем обеспечение кибербезопасности типовой инфраструктуры, задач. Но, увы, красивые картинки архитектур безопасности поставщиков российских облачных услуг не всегда относятся непосредственно к их ЦОДам. «Раз на раз не приходится» — поэтому без предварительно аудита кибербезопасности такого поставщика никак не обойтись. Конечно, поставщик лучше умеет предоставлять инфраструктурные услуги, но в конечном итоге в случае реализации рисков на него будет сложно или невозможно переложить политическую и юридическую ответственность.
Ключевой принцип эффективности
Вне зависимости от избранной стратегии эффективное внедрение возможно лишь при взаимной работе руководства организации, менеджеров по ИТ и кибербезопасности и сотрудников организации. Тщательно спланированная работа по привлечению заинтересованных сторон в разработку решений, применение передового опыта дисциплины управления изменениями (change management) обеспечит успех и закрепление изменений — сделав организацию более устойчивой к киберкризисам и позволив ей воспользоваться полным потенциалом мобильности как стиля работы и жизни.
