ИБ для аналитика: требования и проектные решения

ликбез по инфобезу, информационная безопасность основные понятия и стандарты, требования к ИБ, как разработать требования к информационной безопасности ИС в ТЗ, ИБ для аналитика примеры курсы обучение, Школа прикладного бизнес-анализа

Требования к обеспечению информационной безопасности – один из важнейших разделов ТЗ на ИС/АС. Рассмотрим основные концепции ИБ, которые надо знать аналитику при разработке требований к системе, а также разберемся, в каких проектных решениях могут реализоваться эти требования.

Основы информационной безопасности: ликбез для аналитика

Перед тем, как определять требования к ИБ, надо сперва понять смысл этого термина. В ИТ под информационной безопасностью (ИБ) понимают набор экономически целесообразных и технически эффективных практик, методов и средств предотвращения несанкционированного доступа, использования, раскрытия, изменения и уничтожения информационных активов, т.е. данных и компонентов информационной системы (ИС). Все меры ИБ направлены на обеспечение следующих свойств информационных активов:

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

Эти 3 понятия (конфиденциальность, целостность и доступность) настолько важны, что их называют триада информационной безопасности. Не случайно их часто визуализируют в виде треугольника, поскольку именно эта фигура отображает необходимость компромисса между несколькими критериями. Например, в случае управления проектами часто говорят: надо быстро, дешево, много (качественно) – выбери 2. Аналогично с точки зрения ИБ для каждого проекта приоритетным будет одно свойство системы. Например, если проектируемая ИС предназначена для работы с данными, относящихся к государственной или коммерческой тайне, типа создания стратегически важной продукции, которая не должна ни при каких условиях быть раскрыта конкурентам, в приоритете будет конфиденциальность. А если проектируемая система нужна для оказания социальных или коммерческих услуг широкому кругу населения, на первое место выходит доступность.

Триада информационной безопасности и железный треугольник проекта
Триада информационной безопасности и железный треугольник проекта

Однако, приоритет одного понятия триады ИБ над другими не отменяет их значимости и необходимости обеспечения всех 3-х свойств: конфиденциальность, целостность и доступность информационного актива. Чтобы соблюсти в проектируемой системе все эти свойства, необходимо реализовать меры обеспечения ИБ в соответствии с требованиями к информационной безопасности. В свою очередь, разработка требований к ИБ базируется на следующем наборе понятий:

  • Риск – потенциальное событие, которое может случиться с определенной вероятностью, а может и не случиться. Но, если риск реализуется, т.е. рисковое событие произойдет, оно принесет неприятные последствия (ущерб) для бизнеса.
  • Уязвимость – слабое место внутри системы, которое может привести к рисковому событию;
  • Угроза – внешняя опасность, совокупность условий и факторов, которые могут привести к нарушению ИБ.

Угроза всегда имеет какой-то источник, например, злоумышленник или природные явления. Преднамеренная угроза воплощается в виде атаки, например, DOS-атака, когда к системе выполняется слишком много запросов за короткий период времени, блокируя пропускную способность сети. Это приводит к отказу в обслуживании, что и дало название самой атаке (DoS, Denial of Service). Атака совершается на ИС, которая всегда имеет какую-либо уязвимость. Источник угрозы использует (эксплуатирует) уязвимость ИС, что и приводит к реализации рискового события. Впрочем, не так страшен риск, сколько важны его последствия, влияющие на бизнес, использующий информационную систему. Чтобы наглядно показать связь между всеми этими сущностями, я сделала следующую концептуальную модель ключевых терминов ИБ.

Концептуальная модель ключевых понятий ИБ
Концептуальная модель ключевых понятий ИБ

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

Разработка ТЗ на информационную систему по ГОСТ и SRS

Код курса
TTIS
Ближайшая дата курса
3 июня, 2024
Продолжительность
12 ак.часов
Стоимость обучения
27 000 руб.

Требования к ИБ и проектные решения

Формулировать риски лучше всего с учетом понятий в триаде ИБ и по следующей формуле:

Риск = Угроза + Уязвимость + Актив

Например, по этой формуле можно сформулировать риски следующим образом:

  • недоступность данных из-за отказа сервера СУБД вследствие слишком большого количества открытых соединений;
  • несанкционированный доступ к персональным данным пользователей из-за их передачи в параметрах URL при отправке GET-запроса к определенному ресурсу;
  • нарушение целостности данных из-за разрыва сетевого соединения между узлами распределенной БД вследствие аварии в региональном ЦОД.

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

Пример того, как может выглядеть реестр рисков для большинства ИС с возможными контрмерами, я составила в следующей таблице.

Нарушение свойства ИБ Риск Причина Последствие Контрмера
Уязвимость Угроза
·     Конфиденциальность

·     Целостность

·     Несанкционированный доступ к ИС и/или данным

·     Раскрытие чувствительных данных (персональные данные клиентов или сотрудников, коммерческая или государственная тайна)

·     Отсутствие и/или недостатки механизмов аутентификации и авторизации (простые пароли, однофакторная аутентификация)

·     Устаревшее/необновленное ПО

·     Открытые порты, некорректные настройки сетевого оборудования

·     Действия злоумышленника (взлом, SQL-инъекции, внедрение вредоносного кода)

·     Социальная инженерия (фишинговые атаки)

·     Штраф за нарушение 152-ФЗ и/или GDPR

·     Потеря конкурентного преимущества

·     Аутентификация

·     Авторизация

·     Ограничение длительности клиентской сессии

·     Сложная парольная политика

·     Хеширование паролей

·     Шифрование данных

·     Минимальные привилегии

·     Использование защищенных протоколов (HTTPS, SFTP, FTPS, Kerberos и пр.)

·     Организация демилитаризованной зоны с межсетевыми экранами, брандмауэрами, ограничениями IP

Целостность Потеря данных ·     Существование данных в единственном экземпляре

·     Возможности (наличие функций) удаления данных

·     Действия злоумышленника (SQL-инъекции, внедрение вредоносного кода)

·     Природные явления (шторм, землетрясение)

·     Непреднамеренные действия пользователя (случайное удаление данных)

·     Невозможность выполнить обязательства перед клиентами вообще или в установленный срок

·     Нарушение технологии производства продукта

·     Финансовые потери

·     Периодическое резервное копирование (создание бэкапов) с частотой, равной значению RPO (Recovery Point Objective)

·     Репликация данных по разным геозонам

·     «Мягкое» удаление объектов из БД, когда они помечаются как удаленные, но физически не стираются

Доступность Потеря доступности ИС Отказ СУБД, компонента входа в ИС или средства взаимодействия между частями системы ·        Действия злоумышленника или пользователя (слишком большое количество запросов за короткое время)

·        Природные явления (шторм, наводнение и пр.)

·     Штрафы из-за невыполнения обязательств перед клиентами

·     Потеря дохода из-за простоя сервиса

·     Горячее резервирование ключевых компонентов

·     масштабирование (добавление экземпляров) приложений и БД с разным геораспределением

·     Балансировка нагрузки

·     Ограничение входящего трафика

Таким образом, в разделе ТЗ «Требования к информационной безопасности» могут быть изложены следующие требования, например:

  • Система должна обеспечивать двухфакторную аутентификацию;
  • Длительность клиентской сессии ограничивается 15 минутами бездействия;
  • Обеспечить уровень доступности системы не менее 99,99%;
  • Организовать доступ к данным и операции с ними по ролям согласно CRUDL-матрице с минимальными привилегиями;
  • Пароль пользователя должен состоять минимум из 8 знаков, включая строчные и заглавные буквы, цифры и специальные символы (*, #, $, ^, -, _, \, |, /);
  • Пароль пользователя действует в течение 6 месяцев;
  • Запрещено хранить пароли в открытом виде;
  • Обеспечить хранение и обработку персональных данных пользователей согласно 152-ФЗ;
  • Блокировать учетную запись пользователя на 30 минут после 3-х попыток входа в систему с неверными учетными данными;
  • PRO системы (Recovery Point Objective, максимальный период, за который могут быть потеряны данные в случае аварии или отказа из-за взлома) составляет не более 120 минут;
  • Система должна давать возможность восстановить удаленные объекты в течение 3-х суток с момента удаления;
  • Все события пользовательского поведения должны записываться в журнал (лог-файл);
  • При возникновении событий типа ERROR или CRITICAL ответственные за ИБ лица должны уведомлены об этом в течение 30 минут.

Разумеется, это далеко не полный перечень требований к ИБ. В данном обзоре я рассмотрела только софтверную часть, сфокусировав внимание на технических средствах, без учета административных и физических мер обеспечения ИБ. Однако, при разработке ТЗ по шаблону ГОСТ 34.602-2020, о котором я писала здесь, их тоже необходимо определить, т.к. против лома нет приема. Это означает, что ИС может иметь достаточно совершенные механизмы софтверной защиты, но если дверь в серверную открыта настежь, ни о какой ИБ речи не идет.

В заключение отмечу, что различные аспекты информационной безопасности изложены в стандартах ИБ серии ISO/IEC 27000, а также ISO/IEC 17799, ISO/IEC 27001, BS 7799, ГОСТ Р ИСО/МЭК 15408, ГОСТ Р 51275, ГОСТ Р 50922. Рекомендую ознакомиться с этими стандартами, чтобы использовать корректные термины и понимать рассматриваемый контекст.

Надеюсь, этот небольшой обзор поможет аналитикам лучше ориентироваться в основах ИБ и чувствовать себя увереннее при разработке этого раздела ТЗ.

Разработка ТЗ на информационную систему по ГОСТ и SRS

Код курса
TTIS
Ближайшая дата курса
3 июня, 2024
Продолжительность
12 ак.часов
Стоимость обучения
27 000 руб.

Больше материалов про разработку требований и их оформление в ТЗ вы узнаете на моих курсах в Школе прикладного бизнес-анализа на базе нашего лицензированного учебного центра обучения и повышения квалификации системных и бизнес-аналитиков в Москве:

 

Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.

Добавить комментарий

Поиск по сайту

Напишите нам, мы онлайн!