Что такое Cybersecurity в Big Data и при чем здесь анализ требований

Сегодня мы коснемся процесса управления требованиями и рассмотрим, как техника 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 секунды.

Requirement analysis, actors, Gherkin — Gherkin — человекоподобный язык описания требований в виде сценариев

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

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

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

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

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

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

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

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

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

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

Big Data, Большие данные, предиктивная аналитика, защита информации, безопасность, Security, бизнес-процессы, цифровизация, цифровая трансформация, триада CIA — Триада CIA в информационной безопасности: что должна обеспечить cybersecurity

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

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

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

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

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

Код курса

DSEC

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

по запросу

Продолжительность

ак.часов

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

0 руб.

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

Смотреть расписание

Записаться на курс

Источники