Как снизить риски утечки данных в Big Data: формулируем требования к Cybersecurity

Сегодня мы коснемся процесса управления требованиями и рассмотрим, как техника SQUARE (Security Quality Requirements Engineering) помогает снизить риски в проектах по цифровизации бизнеса и разработке Big Data систем. Читайте в нашем материале, что такое информационная безопасность, BABOK и Gherkin, а также когда и как формулировать требования к cybersecurity на ранних стадиях проектирования.

Что такое требования к ПО: формальные определения и практические примеры

 Начнем с определения термина «требование», которое описывает атрибуты, свойства или качества системы, выявляемые на стадии ее проектирования [1]. Это понятие является общим для всех видов программного обеспечения (ПО), включая комплексные проекты цифровизации и сложные Big Data системы.

BABOK (Business Analysis Body Of Knowledge, свод знаний по бизнес-анализу), профессиональный стандарт бизнес-аналитика от IIBA, международного института бизнес-анализа (International Institute of Business Analysis), регламентирует требование как условие или возможность, необходимые заинтересованной стороне для решения проблемы или достижения цели. Это годное к использованию и документированное представление о потребности может быть сформулировано в виде условия или возможности, которые должны быть выполнены или которыми должно обладать решение или его компоненты для удовлетворения контракта, стандарта, спецификации или других официальных документов [2]. Наиболее наглядно сформулировать требование в таком виде помогает Gherkin – язык   спецификации поведения для BDD (Behavior-driven development) фреймворка Cucumber [3]. Изначально этот язык был предложен в 2007 году как инструмент для аналитиков и представителей бизнеса, чтобы те описывали потребности (требования) как повествовательные сценарии на человеческом языке в простой, лаконичной форме и доступном формате [4]. 

В этом случае требование как бизнес-возможность проектируемой системы будет сформулировано так: <Роль> должен иметь возможность <возможность> с(в) <показатель производительности> с <момент отсчета> находясь в <условия эксплуатации>. На практике это может выглядеть следующим образом:

Оператор колл-центра должен иметь возможность получить информацию о позвонившем клиенте в течение 5 секунд после формирования запроса, если поиск осуществляется с использованием номера договора.

Аналогичным образом конструкции Gherkin позволяют описать требование как ограничение, например: <Система> должна <выполняемая функция> <объект> каждые <производительность> <единица измерения>.  В реальном виде это может выглядеть так: Форма мониторинга должна обновлять информацию о состоянии контролируемого объекта каждые 2 секунды.

Что означает информационная безопасность и как выглядят требования к ней

Информационная безопасность (ИБ, Information Security) – это практика предотвращения несанкционированного доступа, использования, раскрытия, искажения, изменения, исследования, записи или уничтожения информации в физическом (бумажном) или электронном видах. Основная задача ИБ сводится к сбалансированной защите конфиденциальности, целостности и доступности данных, с учётом целесообразности применения и без риска нанести ущерб бизнесу [5].

Согласно триаде CIA, одной из первых и до сих пор применимых ИБ-моделей, безопасная система должна обеспечить хранящимся в ней данным следующие ключевые качества [5]:

• конфиденциальность (Confidentiality)– свойство информации быть недоступной или закрытой для неавторизованных лиц, сущностей или процессов;
• целостность (Integrity) — свойство сохранения правильности и полноты содержания и структуры данных;
• доступность (Availability) — свойство быть доступным и готовым к беспрепятственному использованию по запросу авторизованного субъекта.

По мере развития технологий ИБ к этим ключевым свойствам добавилась достоверность, которая гарантирует строгое соответствие информации предусмотренному результату или субъекту, от которого она поступила [5].

Если рассматривать виды требований по характеру, то требования к безопасности (информационной в том числе) и надежности относятся к нефункциональным. Напомним, нефункциональные требования описывают характер поведения проектируемой системы, тогда как функциональные – само ее поведение: прикладные возможности по решению конкретных пользовательских задач. Помимо требований к информационной безопасности, к нефункциональным также относят бизнес-правила, системные ограничения, условия документирования, дизайна, эксплуатации и других аспектов всего жизненного цикла проектируемого продукта [1].

Принимая во внимание ключевые принципы ИБ (конфиденциальность, целостность, доступность, достоверность), можно сформулировать требования к защите данных в Gherkin-подобных конструкциях. Рассмотрим это на примере банковской Big Data системы, которая выявляет мошеннические операции с помощью машинного обучения (Machine Learning), анализируя поведение пользователей в реальном времени. В частности, гарантию достоверности данных выражает требование, описанное следующим образом:

Система должна блокировать скомпрометированный счет не позднее 2 секунд с момента обнаружения подозрительной операции.

Для соблюдения конфиденциальности Gherkin-сценарий может быть сформулирован так:

Интернет-банк должен повторно аутентифицировать клиента по истечении лимита сессии при условии бездействия пользователя.

Техника SQUARE для анализа требований Cybersecurity в Big Data системах

Чтобы предупредить риски утечки данных и другие проблемы с cybersecurity в Big Data системе, требования к ИБ следует формулировать на этапе анализа потребностей, перед проектированием архитектуры. Это соответствует концепции SQUARE (System Quality Requirements Engineering), которая предполагает работу с требованиями к ИБ, как с функциональными. Данная техника была разработана в 2005 году в американском Университете Карнеги-Меллона. Она предписывает выявлять, категоризировать и определять приоритеты требований ИБ для информационных систем и программных приложений в начале процесса разработки. Модель также может использоваться для документирования и анализа аспектов безопасности уже реализованных систем с целью их последующего улучшения и модификации [6].

Техника SQUARE включает 9 последовательных этапов [6]:

1. Согласование терминов, которые будут использоваться для описания требований к безопасности. Например, что такое идентификация, аутентификация, авторизация, маскирование, шифрование и т.д.
2. Определение измеряемых и достижимых целей безопасности. Например, гарантировать целостность и доступность данных в случае сбоя в рамках RPO (Recovery Point Objective, целевая точка восстановления) 5 минут и RTO (RecoveryTime Objective, целевое время восстановления) 1 час. Подробнее о том, что такое RPO, RTO и другие метрики эксплуатационной надежности (SRE), читайте здесь.
3. Формализованное описание требований к ИБ. Например, сценарии (scenarios), UML-диаграммы вариантов использования (use case diagrams), деревья атак (attack trees), шаблоны, экранные формы и пр.
4. Оценка рисков возникновения разных типов киберугроз. Например, по причине внешних атак, инфраструктуры (программного и аппаратного обеспечения, каналов связи), поведения пользователей и т.д. Другие факторы подобных рисков мы анализировали на примере инцидентов с утечками конфиденциальной информации в этой статье.
5. Выбор техники сбора требований. Например, интервью, опрос, анализ сценариев и пр.
6. Сбор требований, в результате чего сформируется первичный пул требований (бэклог).
7. Разделение требований по категориям: функциональные, системные, архитектурные, программные, нефункциональные (дизайн, поведение пользователей и т.д.)
8. Приоритизация требований с помощью одного из подходов (MoSCoW, QFD, FMEA, анализ Парето, модель Кано, RICE, метод Карла Вигерса, Feature buckets и т.д.). Наиболее популярные и удобные для практического применения подходы к приоритизации задач, включая требования, мы рассмотрим в отдельной статье.
9. Проверка требований – верификация и валидация. Напомним, верификация – это оценка качества представления требований по критериям корректности: единичность, завершенность, последовательность, атомарность, отслеживаемость, актуальность, выполнимость, недвусмысленность, обязательность, проверяемость [1]. А валидация – это проверка требования на соответствие изначальной бизнес-потребности, что его выполнение удовлетворяет первичному запросу со стороны предметной области или заинтересованного лица (стейкхолдера) [2].

По сути, техника SQUARE может использоваться для работы с любыми требованиями, не только к ИБ. Однако, в cybersecurity этот комплексный подход позволит системно охватить максимально возможное число киберугроз и предупредить их возникновение с помощью корректно сформулированных требований к проектируемому объекту. Поэтому знание этой техники будет полезно не только аналитикам Big Data систем, но и руководителям проектов по цифровизации бизнеса.

Безопасность озера данных Hadoop на платформе Arenadata

Код курса

DSEC

Ближайшая дата курса

16 мая, 2023

Длительность обучения

24 ак.часов

Стоимость обучения

66 000 руб.

Подробно разработка и управление требованиями к ПО, а также другие практические вопросы системного и бизнес-анализа разбираются в рамках нашего нового образовательного направления «Школа прикладного бизнес-анализа«. А особенности информационной безопасности и защита больших данных вы узнаете на наших образовательных курсах в лицензированном учебном центре обучения и повышения квалификации ИТ-специалистов (менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data) в Москве:

• BDAM: Аналитика больших данных для руководителей
• DSEC: Безопасность озера данных Hadoop

Источники

1. https://ru.wikipedia.org/wiki/Требования_к_программному_обеспечению
2. https://analytics.infozone.pro/chapter-1-introduction/
3. https://ru.wikipedia.org/wiki/BDD_(программирование)
4. https://habr.com/ru/post/275013/
5. https://ru.wikipedia.org/wiki/Информационная_безопасность
6. https://www.us-cert.gov/bsi/articles/best-practices/requirements-engineering/square-process