Требования к обеспечению информационной безопасности – один из важнейших разделов ТЗ на ИС/АС. Рассмотрим основные концепции ИБ, которые надо знать аналитику при разработке требований к системе, а также разберемся, в каких проектных решениях могут реализоваться эти требования.
Основы информационной безопасности: ликбез для аналитика
Перед тем, как определять требования к ИБ, надо сперва понять смысл этого термина. В ИТ под информационной безопасностью (ИБ) понимают набор экономически целесообразных и технически эффективных практик, методов и средств предотвращения несанкционированного доступа, использования, раскрытия, изменения и уничтожения информационных активов, т.е. данных и компонентов информационной системы (ИС). Все меры ИБ направлены на обеспечение следующих свойств информационных активов:
- конфиденциальность – свойство актива быть недоступным для неавторизованных субъектов (пользователей, внешних систем, сущностей или процессов);
- целостность – сохранение исходной правильности и полноты актива;
- доступность — свойство актива быть доступным и готовым к использованию по запросу авторизованного субъекта, имеющего право на это использование. Чем доступность отличается от надежности, и как ее рассчитать, я рассказываю здесь.
Эти 3 понятия (конфиденциальность, целостность и доступность) настолько важны, что их называют триада информационной безопасности. Не случайно их часто визуализируют в виде треугольника, поскольку именно эта фигура отображает необходимость компромисса между несколькими критериями. Например, в случае управления проектами часто говорят: надо быстро, дешево, много (качественно) – выбери 2. Аналогично с точки зрения ИБ для каждого проекта приоритетным будет одно свойство системы. Например, если проектируемая ИС предназначена для работы с данными, относящихся к государственной или коммерческой тайне, типа создания стратегически важной продукции, которая не должна ни при каких условиях быть раскрыта конкурентам, в приоритете будет конфиденциальность. А если проектируемая система нужна для оказания социальных или коммерческих услуг широкому кругу населения, на первое место выходит доступность.
Однако, приоритет одного понятия триады ИБ над другими не отменяет их значимости и необходимости обеспечения всех 3-х свойств: конфиденциальность, целостность и доступность информационного актива. Чтобы соблюсти в проектируемой системе все эти свойства, необходимо реализовать меры обеспечения ИБ в соответствии с требованиями к информационной безопасности. В свою очередь, разработка требований к ИБ базируется на следующем наборе понятий:
- Риск – потенциальное событие, которое может случиться с определенной вероятностью, а может и не случиться. Но, если риск реализуется, т.е. рисковое событие произойдет, оно принесет неприятные последствия (ущерб) для бизнеса.
- Уязвимость – слабое место внутри системы, которое может привести к рисковому событию;
- Угроза – внешняя опасность, совокупность условий и факторов, которые могут привести к нарушению ИБ.
Угроза всегда имеет какой-то источник, например, злоумышленник или природные явления. Преднамеренная угроза воплощается в виде атаки, например, DOS-атака, когда к системе выполняется слишком много запросов за короткий период времени, блокируя пропускную способность сети. Это приводит к отказу в обслуживании, что и дало название самой атаке (DoS, Denial of Service). Атака совершается на ИС, которая всегда имеет какую-либо уязвимость. Источник угрозы использует (эксплуатирует) уязвимость ИС, что и приводит к реализации рискового события. Впрочем, не так страшен риск, сколько важны его последствия, влияющие на бизнес, использующий информационную систему. Чтобы наглядно показать связь между всеми этими сущностями, я сделала следующую концептуальную модель ключевых терминов ИБ.
Таким образом, чтобы разработать требования к информационной безопасности для проектируемой системы, аналитик должен, прежде всего, определить возможные риски и их последствия для бизнеса. Как это сделать, рассмотрим далее.
Разработка ТЗ на информационную систему по ГОСТ и SRS
Код курса
TTIS
Ближайшая дата курса
2 декабря, 2024
Продолжительность
16 ак.часов
Стоимость обучения
36 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
Ближайшая дата курса
2 декабря, 2024
Продолжительность
16 ак.часов
Стоимость обучения
36 000 руб.
Больше материалов про разработку требований и их оформление в ТЗ вы узнаете на моих курсах в Школе прикладного бизнес-анализа на базе нашего лицензированного учебного центра обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
