Создание хорошо спроектированной платформы классификации данных

При разработке, обновлении или уточнении платформы классификации данных учитывайте следующие рекомендации:

  • Не ожидайте перехода от 0 до 100 на 1-й день. Корпорация Майкрософт рекомендует подход обхода пошагового выполнения, расстановка приоритетов функций, критически важных для организации, и сопоставление их с временной шкалой. Выполните первый шаг, убедитесь, что он выполнен успешно, а затем перейдите к следующему этапу применения полученных уроков. Помните, что ваша организация по-прежнему может быть подвержена риску во время разработки платформы классификации данных, поэтому можно начать с малого всего с нескольких уровней классификации и расширить ее позже по мере необходимости.

  • Вы не просто пишете для специалистов по кибербезопасности: платформы классификации данных предназначены для широкой аудитории, включая среднего сотрудника, юридические отделы и отделы соответствия требованиям, а также ИТ-отделы. Важно написать понятные и понятные определения для уровней классификации данных, предоставляя реальные примеры везде, где это возможно. Старайтесь избегать использования jargon и рассмотрите глоссарий для аббревиатур и технических терминов. Например, используйте "Личные сведения" и укажите определение вместо простого слова "PII".

  • Платформы классификации данных должны быть реализованы. Чтобы платформы классификации данных были успешными, они должны быть реализованы. Это особенно важно при создании требований к элементам управления для каждого уровня классификации данных. Убедитесь, что требования четко определены, и что они предугадать и устранить любые неоднозначности, которые могут возникнуть во время реализации. Например, если у вас есть элемент управления личной информацией, обязательно укажите, что именно это означает, например номер социального страхования или паспорта.

  • Детализированные только при необходимости: платформы классификации данных обычно содержат от 3 до 5 уровней классификации данных. Но то, что вы можете включить пять уровней, не означает, что это не следует делать. При принятии решения о количестве необходимых уровней классификации учитывайте следующие критерии:

    • Ваша отрасль и связанные с ней нормативные обязательства (строго регулируемые отрасли, как правило, требуют дополнительных уровней классификации)
    • Операционные издержки, необходимые для поддержания более сложной платформы
    • Ваши пользователи и их способность соответствовать повышенной сложности и нюансам, связанным с дополнительными уровнями классификации
    • Взаимодействие с пользователем и специальные возможности при попытке применить ручную классификацию для нескольких типов устройств
  • Получите нужных участников: наличие старшего заинтересованных лиц очень важно для успеха, так как многие проекты трудно запустить или занять больше времени без резервного копирования высшего руководства. Платформы классификации данных обычно принадлежат командам информационных технологий, но они могут иметь юридические последствия, требования к соответствию, конфиденциальности и управлению изменениями. Чтобы убедиться, что вы создаете платформу, которая помогает защитить ваш бизнес, обязательно включите в разработку политики таких заинтересованных лиц по вопросам конфиденциальности и юридических лиц, как ваш директор по конфиденциальности и Офис общих советников. Если в вашей организации есть подразделение по соответствию требованиям, специалисты по управлению информацией или группа управления записями, они также могут иметь ценные сведения. По мере развертывания платформы в организации ваш отдел коммуникации также имеет ключевую роль для внутреннего обмена сообщениями и внедрения.

  • Баланс между безопасностью и удобством. Распространенной ошибкой является создание безопасной, но чрезмерно ограничивающей платформы классификации данных. Возможно, эта платформа была разработана с учетом безопасности, но ее часто трудно реализовать на практике. Если пользователям необходимо выполнить сложные, жесткие и трудоемкие процедуры для применения платформы в повседневной жизни, всегда существует риск того, что они больше не будут уверены в ее значении и в конечном итоге перестанут выполнять следующие процедуры. Этот риск существует на всех уровнях организации, включая руководителей (C-suite) в организации. Хороший баланс между безопасностью и удобством наряду с простыми в использовании инструментами обычно приводит к более широкому внедрению и использованию пользователей. Если в вашей платформе есть пробелы, не дождитесь, пока все будет идеально, чтобы начать реализацию. Вместо этого оцените риск или пробел, создайте план для устранения рисков и продолжайте двигаться вперед. Помните, что защита информации — это не то, что активируется на ночь, а затем выполняется. Планируйте, реализуйте некоторые возможности, подтверждайте успешность и перейдите к следующей вехе по мере развития инструментов и повышения зрелости и опыта пользователей.

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

Проблемные моменты при создании платформы классификации данных

Процесс классификации данных по своей природе является широко используемым и касается практически всех бизнес-функций предприятия. Из-за этой широкой области и сложности управления содержимым в современных цифровых средах компании часто сталкиваются с проблемами, зная, с чем начать, как управлять успешной реализацией и как измерять свой ход выполнения. Распространенные проблемы часто включают в себя:

  • Проектирование надежной и понятной платформы классификации данных, включая определение уровней классификации и связанных элементов управления безопасностью.
  • Разработка плана реализации, который включает подтверждение соответствующего технологических решений, согласование плана с существующими бизнес-процессами и определение влияния на сотрудников.
  • Настройка платформы классификации данных в выбранном решении технологии и устранение любых пробелов между технологическими возможностями средства и самой платформой.
  • Создание структуры управления, которая контролирует постоянное обслуживание и работоспособность усилий по классификации данных.
  • Определение конкретных ключевых показателей эффективности (КПЭ) для отслеживания и измерения хода выполнения.
  • Повышение осведомленности и понимания политик классификации данных, их важность и способы их соответствия.
  • Соблюдение внутренних проверок аудита, нацеленных на потерю данных и средства контроля кибербезопасности.
  • Обучение и привлечение пользователей, чтобы они учитывали необходимость правильной классификации в повседневной работе и применяли правильные меры классификации.

Управление изменениями и обучение

В настоящее время организации используют такие средства, как Microsoft 365, для реализации своей платформы классификации данных. Цель — попытаться автоматизировать классификацию данных и не увеличивать нагрузку на сотрудников. Эта структура не означает, что ваша организация не несет ответственности за повышение осведомленности о необходимости управления содержимым и защиты организации от рисков, описанных в этом документе. В рамках ежегодного расписания обучения по-прежнему проводится обучение по вопросам осведомленности в организации. Наш опыт показывает, что при включении надежных и комплексных усилий в обучение пользователей, которые являются ключевой аудиторией, выполняющая эту работу, повышается их "приобретение" и повышается уровень внедрения и качества. Добавление рекомендаций по метке и советов в приложении может увеличить эти усилия. Это обучение не обязательно должно быть обширным автономным курсом. Ваша организация может включить его в другие регулярные учебные курсы, такие как ежегодное обучение информационной безопасности, а затем включить общие сведения об уровнях и определениях классификации данных. Главное в том, что сотрудники должны понимать, что хотя средство автоматизирует классификацию данных, это не устраняет общую ответственность каждого пользователя за защиту данных в соответствии с политикой компании.

Кроме того, следует рассмотреть более подробное обучение для ИТ-групп и групп информационной безопасности, чтобы усилить готовность к работе. Команды, которые управляют средством и платформой классификации данных, должны находиться на одной странице. Такая координация может потребовать инвестиций в более надежное расписание обучения, которое может выполняться чаще, чем раз в год. Инвестиции в более частые учебные курсы представляют собой еще один способ снижения риска для вашей организации. Эта команда отвечает за реализацию и, следовательно, может быть точкой сбоя, если не обучить средство и политику.

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

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

Управление и обслуживание

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

  • Создание тела управления, предназначенного для классификации данных, или добавление ответственности за классификацию данных в основную часть существующего текста информационной безопасности.
  • Определение ролей и обязанностей для пользователей, контролирующих классификацию данных.
  • Установка ключевых показателей эффективности для отслеживания и измерения хода выполнения.
  • Отслеживание ведущих методик кибербезопасности и нормативных изменений.
  • Разработка стандартных операционных процедур, поддерживающих и принудительно применяя платформу классификации данных.

Отраслевые рекомендации

Хотя основные принципы разработки надежной платформы классификации данных являются универсальными, сведения о вашей платформе будут зависеть от характера вашей отрасли и уникальных факторов соответствия требованиям к данным и факторов безопасности.

Например, финансовым службам может потребоваться учитывать соответствие нескольким нормативным платформам в зависимости от области их деятельности и регионов, в которых они работают. Ценные компании в США должны соответствовать нормативным требованиям к учетным записям, таким как правило SEC 17a-4(f) или правило FINRA 4511, которое соответствует требованиям к безопасности и хранении книг и записей. Аналогичным образом, компании, которые работает в Соединенном Королевстве, должны учитывать соответствие FCA.

Государственные учреждения сталкиваются с различными нормативными актами, которые управляют своими данными, которые зависят от территории и характера их работы. Например, в США правительственные учреждения и их агенты, которые имеют доступ к федеральным налоговым сведениям (FTI), применяются к IRS 1075, что позволяет свести к минимуму риск потери, нарушения или несанкционированного использования федеральных налоговых сведений.

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

  • Организации здравоохранения, обеспечивающие соответствие ТРЕБОВАНИЯМ HIPAA.
  • Образовательные учреждения, от учебных заведений K-12 до университетов, управляя соответствием FERPA.
  • Производители, работающие в соответствии с рекомендациями GxP в своей стране или регионе по информационной безопасности.
  • Мультимедиа, розничная торговля и многие другие компании, которые обрабатывают соответствие ТРЕБОВАНИЯМ GDPR.
  • Доставка и хранение содержимого для развлечения, программного обеспечения и информации, которое работает с CDSA.
  • Информационной безопасности в отрасли энергии, которая соответствует стандарту NERC CIP.

Реализация платформы классификации данных в Microsoft 365

После разработки платформы классификации данных следующим шагом является реализация. Этот Портал соответствия требованиям Microsoft Purview позволяет администраторам обнаруживать, классифицировать, проверять и отслеживать свои данные в соответствии с их платформой классификации данных. Метки конфиденциальности можно использовать для защиты данных путем применения различных средств защиты, таких как шифрование и маркировка содержимого. Их можно применять к данным вручную. по умолчанию на основе параметров политики; или автоматически в результате такого условия, как идентифицированный персональный код.

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

Метка классификации Метка конфиденциальности Параметры метки Опубликовано в
Неограниченный Неограниченный Применение нижнего колонтитула Unrestricted Все пользователи
Общие Общие Применение нижнего колонтитула "Общие" Все пользователи

Совет

Во время пилотного проекта майкрософт по защите внутренней информации возникли проблемы с пониманием и использованием метки "Личные". Пользователи не могли смутить, что это означает персональный интеллект или просто связано с личным вопросом. Метка была изменена на "не бизнес", чтобы она была более понятной. В этом примере показано, что таксономия не обязательно должна быть идеальной с начала. Начните с того, что вы считаете правильным, выполните пилотное развертывание и при необходимости настройте метку на основе отзывов.

Для крупных организаций с глобальным охватом или более сложными требованиями к информационной безопасности вы можете найти эту связь "один к одному" между числом уровней классификации в политике и количеством меток конфиденциальности в среде Microsoft 365, чтобы быть сложной задачей. Эта проблема особенно актуальная в глобальных организациях, где определенный уровень классификации данных, например "Ограниченный", может иметь другое определение или другой набор элементов управления в зависимости от региона.

Дополнительные сведения о реализации см. в разделе "Общие сведения о классификации данных" и "Сведения о метках конфиденциальности".

Ссылки