2.3 Шаги эффективного процесса
1. Определение базовых параметров будущего продукта
Выделим типовые параметры, которые необходимо знать для определения уровня требований информационной безопасности:
Что за продукт вы делаете?
Будут ли в продукте персональные данные? Какие именно?
Какое число пользователей продукта вы ожидаете?
Ответим на эти вопросы на примере нашего приложения по личным финансам:
Что за продукт?
Приложение по управлению личными финансами.
Будут ли в приложении персональные данные?
Очевидно, что да. Значит, требования по работе с персональными данными придется выполнять в любом случае. Необходимо обсудить, какой минимальный набор данных необходим и достаточен для приложения.
Какое число пользователей ожидается?
В законодательстве РФ важная граница установлена на уровне 100 тысяч пользователей. Пока пользователей меньше этой границы, требования мягче; когда их станет больше, требования к безопасности будут строже.
2. Синхронизация контекста
Выбор инструмента
Выбранный вами инструмент должен быть таким, чтобы помогать вам коммуницировать и договариваться с другими участниками проекта.
Выбранный вами инструмент должен быть таким, чтобы помогать вам коммуницировать и договариваться с другими участниками проекта.
В своей работе аналитики часто используют инструменты:
объектно-ориентированный язык UML;
методологию ARIS;
методологии IDEF;
нотацию моделирования бизнес-процессов BPMN и др.
Проблема в использовании этих инструментов в том, что не только для подготовки материалов в этом формате, но и для их понимания требуются специальные знания, которыми могут не обладать все участники.
В итоге страдает коммуникация, теряется время на изучение.
В итоге страдает коммуникация, теряется время на изучение.
Возникает парадоксальная ситуация: чем детальнее и лучше аналитик прорабатывает документы, тем сложнее для понимания они становятся, тем ниже качество коммуникации с другими участниками, тем выше потери.
Мы предлагаем отложить использование этих инструментов до следующих этапов, а для начального вовлечения участников использовать более простые в понимании инструменты, не требующие специальных знаний.
Одним из таких инструментов может быть модель С4 (англ. C4 model).
Одним из таких инструментов может быть модель С4 (англ. C4 model).
3. Синхронизация понимания архитектуры системы
Задача этого этапа – выявить ключевые модули продукта и внешних систем, их взаимосвязи и синхронизировать это видение между командами:
разработки;
инфраструктуры;
информационной безопасности.
Любой продукт можно декомпозировать множеством разных способов, и мнения команд разработки, управления инфраструктурой и службы информационной безопасности по этому вопросу могут отличаться. Если вы организовали эту коммуникацию на ранней стадии, то сняли риск последующих разногласий.
На примере приложения с личными финансами это может выглядеть, например, так:
На примере приложения с личными финансами это может выглядеть, например, так:
Уже на этом шаге сотрудники службы информационной безопасности могут дать базовые рекомендации и внести изменения в планируемую функциональность продукта.
Например:
Например:
Использование бота в Telegram для передачи финансовых и персональных данных запрещено Федеральным законом от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации». Поэтому придумывать и проверять клиентские гипотезы в этой части нет никакого смысла.
Хранить персональные данные рекомендуется отдельно от всей другой информации, это упростит прохождение проверок на соответствие критериям. Плюс необходимо сразу предусмотреть, как будет работать процедура деперсонализации этих данных, когда разработчики захотят получить копию системы в свой контур, чтобы исправить ошибку в данных клиента.
5. Создать и запустить «скелет»
Вероятно, каждый руководитель проекта знает, что продукт лучше запускать, начиная с минимально действующего продукта – MVP.
MVP (англ. minimal viable product – «минимально жизнеспособный продукт») – продукт, обладающий минимальными, но достаточными для удовлетворения первых потребителей функциями. Его основная задача – получение обратной связи для формирования гипотез дальнейшего развития продукта.
Однако подходы к MVP – кто как его видит – могут отличаться. Популярная иллюстрация ниже отражает наше понимание MVP.
Практика
Проработайте свой продукт, используя предложенную цепочку действий:
0. Определите идею продукта
Сформулируйте:
кто целевая аудитория (ЦА);
в чем ключевая идея продукта;
какую проблему решает продукт для ЦА.
1. Определите ожидаемые базовые параметры продукта
Выделите показатели, влияющие на уровень требований ИБ.
2. Синхронизируйте контекст
Представьте контекст продукта верхнего уровня и проведите встречи с представителями ИБ, выявите на основе контекста и планируемых базовых показателей продукта:
какие требования они уже могут описать для системы;
при каких условиях требования могут быть облегчены;
какие детали архитектуры нужно раскрыть для уточнения требований.
Теперь вы знаете, в чем заключаются типовые роли участников (или игроков) в процессе реализации проекта или разработки цифрового продукта, какие интересы преследует каждая сторона и как сделать процесс их взаимодействия эффективным.
Далее проанализируем, какие риски и угрозы следует учитывать в работе с информационной безопасностью.
Далее проанализируем, какие риски и угрозы следует учитывать в работе с информационной безопасностью.