- •Содержание
- •1.3 Наименование организаций – Заказчика и Разработчика
- •1.4 Перечень документов, на основании которых создается система
- •1.5 Плановые сроки начала и окончания работ
- •1.6 Источники и порядок финансирования
- •1.7 Порядок оформления и показа заказчику работ
- •1.8 Состав используемой нормативно-технической документации
- •2 Назначения и цели создания системы
- •2.1 Назначение системы
- •2.2 Цель создания системы
- •Задачи для достижения целей
- •3 Характеристика объекта автоматизации
- •3.1 Краткие сведения об объекте автоматизации
- •3.2 Существующее программное обеспечение
- •3.3 Существующее техническое обеспечение
- •3.4 Существующее нормативно-правовое обеспечение
- •4.1.1.2 Требования к режимам функционирования системы
- •4.1.1.3 Требования по диагностированию системы
- •4.1.1.4 Перспективы развития, модернизация системы
- •4.1.2 Требования к численности и квалификации персонала
- •4.1.3 Требования к показателям назначения
- •4.1.4 Требования к надёжности
- •4.1.5 Требования к безопасности
- •4.1.6 Требования к эргономике и технической эстетике
- •4.1.7 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы
- •4.1.8 Требования к защите информации от несанкционированного доступа
- •4.1.8.1 Средства защиты, обеспечиваемые создаваемым программным продуктом
- •4.1.9 Требования по сохранности информации при авариях
- •4.1.10 Требования к патентной чистоте
- •4.2 Требования к функциям
- •4.2.1 Подсистема хранения данных
- •4.2.2 Подсистема авторизации
- •4.2.3 Базовая подсистема
- •4.2.4 Подсистема работы с документами
- •4.2.5 Подсистема шаблонов
- •4.3 Требования к видам обеспечения
- •4.3.1 Требования к математическому обеспечению
- •4.3.2 Требования к информационному обеспечению системы
- •4.3.3 Требования к лингвистическому обеспечению системы
- •4.3.4 Требования к программному обеспечению системы
- •4.3.5 Требования к техническому обеспечению
- •4.3.6 Требования к организационному обеспечению
- •4.3.7 Требования к методическому обеспечению
- •5 Состав и содержание работ по созданию системы
- •6 Порядок контроля и приёмки системы
- •6.1 Виды испытаний
- •6.2 Общие требования к приёмке работы
- •6.3 Статус приёмочной комиссии
- •7 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
- •8 Требования к документированию
- •Список ипользуемых источников
4.1.1.2 Требования к режимам функционирования системы
Для автоматизированной системы управления инцидентами информационной безопасности «Бустсейв» определены следующие режимы функционирования:
Авторизованный режим – доступ к системе осуществляется только после прохождения аутентификации и авторизации пользователя. В данном режиме доступны мониторинг событий безопасности, просмотр и анализ зарегистрированных инцидентов, запуск автоматических и ручных сценариев реагирования, формирование и просмотр отчётной документации, а также администрирование подсистем и управление правами доступа пользователей.
Режим расследования – предоставляет специалистам по информационной безопасности расширенный набор инструментов для анализа событий, корреляции инцидентов, построения временных цепочек атак, выявления источников угроз и детализации механизмов их распространения. Режим предназначен для проведения углубленного анализа и документирования результатов расследования.
Режим интеграции и обмена данными – обеспечивает взаимодействие АСУ «Бустсейв» с иными элементами ИТ-инфраструктуры университета, включая системы мониторинга, Service Desk-платформы, системы управления доступом, средства защиты информации и внешние источники событий безопасности. Режим поддерживает работу API, загрузку и выгрузку данных, синхронизацию инцидентов и обмен индикаторами компрометации.
4.1.1.3 Требования по диагностированию системы
Система должна обеспечивать контроль своего функционирования и диагностику технического состояния программных и информационных компонентов. Должны быть реализованы средства обнаружения и регистрации ошибок, сбоев и аварийных ситуаций, возникающих при работе отдельных модулей, подсистем и базы данных.
Система должна обеспечивать ведение журналов диагностических сообщений с фиксацией времени возникновения, кода и описания ошибки. Журналы должны быть доступны администраторам для анализа и последующего устранения причин отказов.
При возникновении аварийных ситуаций должна быть обеспечена возможность восстановления работоспособности системы с откатом к последнему корректному состоянию без утраты данных, включая сведения об инцидентах, событиях безопасности и действиях пользователей. Процедуры восстановления должны предусматривать проверку целостности информационных ресурсов.
4.1.1.4 Перспективы развития, модернизация системы
Система должна предусматривать возможность дальнейшего развития и модернизации без необходимости изменения её базовой архитектуры. Должна быть обеспечена возможность расширения функциональных характеристик программного обеспечения, внедрения новых модулей и обновления существующих компонентов.
Система должна поддерживать модернизацию комплекса технических средств, включая замену вычислительного оборудования, расширение ресурсов хранения данных и повышение отказоустойчивости. Конструкция системы должна обеспечивать возможность увеличения производительности за счёт горизонтального и вертикального масштабирования, а также подключения дополнительных вычислительных узлов и подсистем.
Архитектурные решения должны обеспечивать адаптацию системы к изменению объёма обрабатываемых данных, росту количества пользователей, подключению новых источников событий и интеграции со сторонними сервисами без нарушения работоспособности и структуры системы.