Приложение № ____ к тендерной документации

Приложение № ____
к тендерной документации
Техническая спецификация
о закупках лицензии на программный продукт
1. ВВЕДЕНИЕ
Настоящая Техническая спецификация содержит описание основных задач и требований,
предъявляемых Акционерным обществом «Фонд национального благосостояния «СамрукҚазына» (далее – Фонд) к поставке системы управления информацией о безопасности и
событиях безопасности.
2. ОБЩИЕ СВЕДЕНИЯ
2.1. Полное наименование Системы и ее условное обозначение
Полное наименование программного продукта: Система управления информацией о
безопасности и событиях безопасности, позволяющая автоматизировать процесс анализа
событий и повысить эффективность управления сетевой инфраструктурой.
2.2. Наименования организации-Заказчика
Полное наименование Заказчика: Акционерное общество «Фонд национального
благосостояния «Самрук-Қазына» (далее – Фонд, Заказчик).
Краткое наименование: АО «Самрук-Казына» / Фонд
Адрес: Республика Казахстан, город Астана, ул. Кунаева, 8, Блок: Б.
2.3. Перечень основательных документов
Политика системы управления информационной безопасности от 27 декабря 2013 года;
Процедура решения инцидентов информационной безопасности от 27 декабря 2013 года.
2.4. Определения, термины, обозначения и сокращения
Термин
Заказчик
Система
ИС
БД
ОС
ЛВС
ПО
ЦОД
Парсер
API
AD
Backup
copy
LDAP
TCP DUMP
Syslog
round-robin
Dashboard
Описание
Акционерное общество «Фонд национального благосостояния
«Самрук-Қазына»
Система сбора событий информационной безопасности, позволяющая
автоматизировать процесс анализа событий и повысить эффективность
управления сетевой инфраструктурой, англ. SIEM
Информационная система
База Данных
Операционная система
Локальная вычислительная сеть
Программное обеспечение
Центр хранения данных
Программа или часть программы, выполняющая синтаксический анализ
Интерфейс программирования приложений, англ. Application Programming
Interface
LDAP-совместимая реализация службы каталогов, англ. Active Directory
Резервное копирование, процесс создания копии данных
облегчённый протокол доступа к каталогам, англ. Lightweight Directory Access
Protocol
Утилита UNIX, позволяющая перехватывать и анализировать сетевой трафик,
проходящий через компьютер, на котором запущена данная программа
Алгоритм распределения нагрузки распределённой вычислительной системы
методом перебора и упорядочения её элементов по круговому циклу
Панель, содержащая в себе несколько виджетов
Термин
Drill down
IM
Ботнет
Описание
Детализация данных
Система мгновенного обмена сообщениями
Компьютерная сеть, состоящая из некоторого количества хостов, с
запущенными ботами — автономным программным обеспечением
Лог
Файл с записями о событиях в хронологическом порядке
Firewall
Комплекс аппаратных или программных средств, осуществляющий контроль и
фильтрацию проходящих через него сетевых пакетов в соответствии с
заданными правилами
Корреляция Статистическая взаимосвязь двух или более случайных величин или событий
Zero-day
Термин, обозначающий неустранённые уязвимости, а также вредоносные
программы, против которых ещё не разработаны защитные механизмы
DOS,DDOS Вредоносная программа, предназначенная для проведения атаки типа
"Denial of Service" ("Отказ в обслуживании") на удаленный сервер
Subnet/CIDR Диапазон IP-адресов, являющийся частью более широкого диапазона
P2P
Оверлейная компьютерная сеть, основанная на равноправии участников
Recovery
Восстановление
IPS
Система предотвращения вторжений
File sharing
Совместное использование файлов
SOC
Центр управления инцидентами, англ. Security Operation Center
NOC
Центр управления сетевыми соединениями, англ. Network Operations Center
WMI
Инструментарий управления Windows, англ. Windows Management
Instrumentation
JDBC
Соединение с базами данных на Java, англ. Java DataBase Connectivity
SNMP
Простой протокол сетевого управления, англ. Simple Network Management
Protocol
PCI DSS
Стандарт безопасности индустрии платёжных карт, англ. Payment Card Industry
Data Security Standard
SOX
Методика построения системы внутреннего контроля
FISMA
Методология на основе информационного закона об управлении
безопасностью
COBIT
Пакет открытых документов, около 40 международных и национальных
стандартов и руководств в области управления IT, аудита и IT-безопасности
NIST
Национальный институт стандартов и технологий США
ISO
Международная организация по стандартизации, ИСО
HTTP
Протокол прикладного уровня передачи данных
IP адрес
IP-адрес (айпи-адрес, сокращение от англ. Internet Protocol Address) — это
уникальный сетевой адрес узла в компьютерной сети, построенной по
протоколу IP
Модель OSI Базовая эталонная модель взаимодействия открытых систем, сокр. ЭМВОС;
1978 г) — сетевая модель стека сетевых протоколов OSI/ISO.
Netflow
Сетевой протокол, предназначенный для учёта сетевого трафика
Switch
Сетевой коммутатор, устройство, предназначенное для соединения нескольких
узлов компьютерной сети в пределах одного или нескольких сегментов сети
Router
Маршрутизатор, специализированный сетевой компьютер, имеющий как
минимум один сетевой интерфейс и пересылающий пакеты данных между
различными сегментами сети
3. НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ СИСТЕМЫ
3.1. Назначение Системы
Система сбора событий информационной безопасности предназначена для сбора,
корреляции и анализа данных о событиях и угрозах безопасности, поступающих от
различных информационных систем Фонда.
3.2. Количество Товара
Лицензия на программный продукт системы
безопасности поставляется в виде одного комплекта.
сбора
событий
информационной
3.3. Место и условия поставки Товара
Местом поставки Товара является адрес Заказчика: Республика Казахстан, город Астана,
ул. Кунаева, 8, Блок: Б.
Товар поставляется в виде электронного диска с записанным программным обеспечением,
лицензии предоставляются на корпоративный рабочий электронный адрес.
3.4. Срок поставки Товара
Срок поставки составляет 60 календарных дней со дня заключения договора.
3.5. Цели применения Системы
Основные цели применения Системы:
 повышение общего уровня защищенности корпоративной информационной
инфраструктуры Фонда;
 консолидация и хранение журналов событий от различных источников — сетевых
устройств, приложений, журналов ОС, средств защиты;
 автоматизация процесса обнаружения инцидентов с документированием в собственном
журнале, а также своевременное информирование о событиях;
 помощь при проведении расследований произошедших инцидентов.
4. ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ
Объектом автоматизации Заказчика является процесс сбора событий информационной
безопасности с информационных систем, сетевой инфраструктуры в консолидированное
хранилище. Объекты для сбора событий информационной безопасности расположены в
центральном офисе Заказчика, по адресу Центральный офис Заказчика по адресу г. Астана,
Кунаева, д.8, Блок Б (Здание «Изумрудный квартал») и в ЦОД г.Астана, ул.Жирентаева 11
(Здание АО «Казахтелеком»).
Таблица 1 Перечень источников событий
Предварительный список подключаемых источников событий
п/п
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Название системы
Стандартные источники событий
Файловые серверы Microsoft Windows
Файловые серверы Red Hat
СУБД Microsoft SQL
СУБД Oracle
SAP сервера
Microsoft Exchange
Microsoft SharePoint
Microsoft Active Directory
Сетевые устройства Cisco
Microsoft TMG
Количество
2
15
6
15
15
1
2
2
17
1
п/п
Название системы
Количество
Нестандартные источники событий
11.
Kaspersky Antivirus
1
12.
Система электронного документооборота
6
Точный перечень источников событий, должен быть уточнён Поставщиком на момент
автоматизации процесса сбора событий информационной безопасности. Настройка источников
событий производится Поставщиком на основании дополнительно согласованного списка
источников событий, переданного Фондом Поставщику до начала внедрения.
Примечание: под нестандартными источниками событий подразумеваются официально
неподдерживаемые производителями Системы источники.
5. ТРЕБОВАНИЯ К СИСТЕМЕ
5.1. Требования к системе в целом
1. Система должна обеспечивать централизованное управление всеми её компонентами и
функционалом через единый Веб-интерфейс;
2. Система должна иметь встроенный функционал определения всех активов сети;
3. Система должна иметь встроенный функционал автоматической классификации
определенных активов в сети;
4. Система должна поддерживать возможность разделения dashboards через
пользовательский интерфейс для использования во внедрениях SOC и NOC;
5. Система должна предоставлять открытый API для доступа к информации, находящейся
в базе данных системы;
6. Система должна иметь возможность шифровать коммуникации между компонентами;
7. Система должна интегрироваться с системами сторонних производителей (LDAP, AD)
для обеспечения аутентификации;
8. Система должна обеспечивать автоматическое обновление конфигураций без
дополнительных временных затрат со стороны пользователя системы. Например, обновление
правил по отдельным системам и устройствам сторонних производителей;
9. Система должна предоставлять возможность управления системой, создания
аналитических отчетов и правил через веб-интерфейс пользователя;
10. Система должна поддерживать отказоустойчивое внедрение;
11. Система должна гарантировать работу отдельных компонентов системы, при выходе
из строя любой части системы. (Например, центральная консоль выходит из строя, но лог
коллекторы продолжают функционировать);
12. Система должна иметь автоматический процесс резервного копирования
конфигурации (Backup) и возможность восстановления (Recovery) конфигурации из
графического интерфейса пользователя;
13. Система должна иметь встроенный процесс анализа своего состояния и оповещать
пользователя при возникновении проблем;
14. Система должна поддерживать режимы внедрения как: программно-аппаратный
комплект, так и в виде программного обеспечения на серверах заказчика;
15. Система должна интегрироваться с другими системами обеспечения безопасности и
расследования инцидентов;
16. Система должна легко масштабироваться и расширять функционал (при добавлении
новых устройств, офисов, приложений в сети заказчика) для соответствия требованиям бизнеса;
17. Система должна поддерживать разнесенные базы данных для хранениях информации
о событиях, при этом вся информация должна быть доступна через единый интерфейс
пользователя;
18. Система должна выбираться с запасом производительности и работать при
кратковременных пиках нагрузки, превышающих расчетные нагрузки для данной системы;
19. Система должна обеспечивать целостность собранной информации;
20. Система должна предоставлять доступ к ОС устройства. Например, возможность
запустить TCP DUMP для проверки состояния системы;
21. Система должна поддерживать разнесенную модель для корреляции со всех
коллекторов. (Например для 25 неудачных попыток аутентификации, когда 25 событий
приходят не на 1 коллектор, а на несколько.);
22. Система должна поддерживать расширенную таксономию пользователей для событий
и полей. Пользователь должен иметь возможность присваивать событиям любые имена;
23. Система должна предоставлять возможность изменения поведения автоматического
тегирования событий по важности согласно пожеланиям пользователя;
24. Система должна предоставлять прозрачное получение, агрегирование, сортирование,
фильтрацию и аналитику данных по всем разнесенным компонентам системы;
25. Система должна иметь систему сбора журналов событий и их архивации, которая
поддерживает как кратковременное хранение(online), так и долгосрочное(offline) хранение
журналов событий;
26. Система должна поддерживать хранение журналов событий на внешних хранилищах;
27. Система должна обеспечивать рациональное использование хранилищ данных, а
также архивации данных в архиве;
28. Система должна поддерживать стандартные методы сбора журналов событий
(например, syslog, WMI, JDBC, SNMP, и пр.);
29. Система должна поддерживать безагентный сбор журналов событий везде, где это
возможно;
30. Система должна иметь возможность распределять хранение журналов событий и их
обработку по всей архитектуре системы;
31. Система должна предоставлять доступ ко всей информации о событиях на
протяжении длительного периода времени (например,12 месяцев) для дальнейших
расследований.
32. Система должна нормализовать стандартные поля событий (имена пользователей, IP
адреса, имена хостов, устройства-источники событий) с различных устройств мультивендорной
сети. Нормализация должна проводиться без дополнительной настройки (out of the box);
33. Система должна предоставлять стандартную категоризацию событий без
предварительной дополнительной настройки;
34. Система должна иметь возможность хранить информацию о событиях, как в
исходном виде, так и в нормализованном виде для использования в дальнейших
расследованиях;
35. Система должна иметь возможность обрабатывать и нормализировать данные из
полей, которые не поддерживаются изначально и не предоставляются с настройками out of the
box;
36. Система должна обеспечивать анализ событий в режиме реального времени;
37. Система должна обеспечивать анализ событий на протяжении определенного периода
времени;
38. Система должна предоставлять возможность собирать и анализировать событий по
предустановленным пользователем фильтрам;
39. Система должна предоставлять возможность получения дополнительной информации
о событиях при необходимости ( drill down );
40. Система должна обеспечивать фильтрацию, а также показывать через интерфейс
пользователя события в режиме реального времени, где пользователь может сразу же
применять политики и фильтры;
41. Система должна предоставлять отчетность по всем событиям, отчетность должна
быть доступа через веб-интерфейс для пользователей решения;
42. Система должна давать возможность самостоятельной настройки отчетности и
создания собственных отчетов пользователем;
43. Система должна иметь возможность планирования генерации отчетов в определенный
период времени;
44. Система должна предоставлять примеры сгенерированных отчетов для более простого
использования и генерации новых отчетов пользователем, а также мастер создания отчетов;
45. Система должна иметь встроенные отчеты для типичных бизнес-требований
заказчиков;
46. Система должна иметь встроенные отчеты по определенным требованиям стандартов
(PCI, SOX, FISMA) а также лучших практик (NIST, CoBIT, ISO);
47. Система должна предоставлять удобный интерфейс для быстрой визуализации все
информации о сети и безопасности;
48. Система должна иметь встроенные меню для типичных бизнес-требований и
процессов;
49. Система должна предоставлять отчеты за определенный период времени по
различным сегментам и системам в сети;
50. Система должна предоставлять возможность автоматического распределения отчетов;
51. Система должна обеспечивать оповещения по всем угрозам в сети на любых
устройствах;
52. Система должна обеспечивать корреляцию информации с различных источников,
которые никак не взаимодействую между собой;
53. Система должна обеспечивать оповещения на основе обнаруженных аномалий и
поведенческого анализа и изменений;
54. Система должна обеспечивать оповещения по предустановленным политикам
(например, при обнаружении IM трафика, который запрещен.);
55. Система должна обеспечивать оповещения исходя из сегмента сети, а также типа
трафика;
56. Система должна поддерживать приоритезацию оповещений в зависимости от
требований пользователя, а также критичности активов;
57. Система должна обеспечивать возможность создания собственных настраиваемых
оповещений;
58. Система должна предоставлять мастер настройки оповещений для упрощения
процесса их создания, а также улучшения точности результатов и уменьшения количества
ложных срабатываний;
59. Система должна предоставлять возможность создания оповещений при
превышении/нарушении норм работы систем и их использования;
60. Система должна иметь возможность ограничивать число одинаковых оповещений на
единицу времени;
61. Система должна использовать графический интерфейс пользователя для настройки и
демонстрации оповещений;
62. Система должна иметь возможность применять активное воздействие и реакцию на
оповещения. Например, запускать скрипт, или отправлять письмо по почте;
63. Система должна поддерживать интеграцию (на уровне оповещений) с другими
системами безопасности и оповещения, которые функционируют в сети;
64. Система должна иметь возможность коррелировать дополнительные данные
безопасности (географическое расположение, известный ботнет, уязвимость, каналы
распространения и пр.) Эти данные должны автоматически собираться этим же решением, без
подключения дополнительных систем, сторонних разработчиков;
65. Система должна иметь возможность коррелировать информацию с систем
сканирования уязвимостей сторонних производителей;
66. Система должна предупреждать, администратора, если перестали поступать логи с
устройства в сети, которое мониторится (например, нет логов от сервера в течении x минут);
67. Система должна обеспечивать возможность корреляции информации с устройств и
систем различного типа. (Например сигнатура HTTP Exploit с IPS ->повышение привилегий на
локальной машине -> определение нового открытого порта на машине, путем анализа потоков);
68. Система должна обеспечивать встроенный функционал автоматического определения
всех устройств и их инвентаризации по классам систем (например, почтовые сервера, сервера
баз данных и пр.) для минимизации количества ложных срабатываний из-за недостатка
информации о системах;
69. Система должна обеспечивать корреляцию по определенным последовательностям
событий. Например, сервис остановился и не возобновляется на протяжении 10 минут;
70. Система должна поддерживать корреляцию на основе дополнительных данных.
Например, на основе журналов событий с firewall, которые содержат поля с объемом
переданных данных, например, когда источник пересылает более 1GB данных, через один порт
серверу, за 1 час.
Контроль активности сети
71. Система должна визуально отображать профиль трафика в байтах, скорости передачи
пакетов и количестве коммуницирующих между собой хостов. Эти отображения должны
применяться для приложений, портов, протоколов, угроз и других контрольных точек в сети.
Система должна предоставлять информацию об отдельном участке, сети в целом или любой
определенной группы хостов.
72. Система должны поддерживать обработку поступающих событий со скоростью не
менее 2500 событий в секунду.
73. Система должны поддерживать обработку сетевых потоков со скоростью не менее
50000 потоков в минуту.
74. Система должна определять приложение вне зависимости от TCP-порта. Система
должна поддерживать идентификацию приложений не только по общеизвестным портами, но и
в других случаях, а также определять туннелированные приложения (например, если внутри
HTTP передается трафик MS-IM, то сервис должен определяться как MS-Instant Messenger, а не
HTTP).
75. Система должна определять “zero-day” события.
76. Система должна уметь проводить поведенческий анализ трафика и сообщать об
изменениях согласно заданных порогов изменения.
77. Система должна детектировать DoS и DDoS атаки.
78. Система должна детектировать и отображать трафик, относящийся к угрозам.
Выдавать информацию по типам угроз в сети.
79. Система должна различать и профилировать трафик по типам приложений (не только
по общеизвестным TCP портам).
80. Система должна поддерживать разделение трафика согласно логическому дизайну
сети. (т.е., Subnet/CIDR).
81. Система должна выявлять потенциально опасные приложения в сетевом трафике (file
sharing, peer-to-peer и т.д.).
82. Система должна отображать профили трафика по скорости передачи пакетов.
83. Система должна предоставлять информацию в нескольких интервалах времени (за
неделю, день и час).
84. Система должна определять происхождение и назначение потоков трафика в сети, в
том числе и по географическим регионам в режиме реального времени.
85. Система должна разделять и создавать независимые профайлы для локального
трафика и трафика идущего/приходящего в/из интернет.
86. Система должна позволять создавать пользовательские профайлы используя для
выборки любые параметры потока трафика.
87. Система должна поддерживать представление трафика на основе IP адреса, группы IP
адресов, источник/место назначения IP пар и т.д.
88. Система должна обеспечивать сбор и анализ захваченных пакетов данных.
89. Система должна обеспечивать извлечение специфических, определенных
пользователем параметров из захваченных пакетов данных и использовать их в правилах
корреляции.
90. Система должна иметь возможность контекстно связывать активность приложения в
сети с событием безопасности на подконтрольном устройстве.
91. Система в реальном времени должна контекстно связывать выявленные события
безопасности со знаниями об активах в сети.
92. Система должна автоматически определять приоритет выявленных событий
безопасности согласно относительной важности актива.
93. Система должна автоматически определять серьезность выявленного события
безопасности по отношению к уязвимости активов.
94. Система должна быть способным кастомизировать любые аналитические данные,
установленные по умолчанию.
95. Система должна обеспечивать представление информации событий в реальном
времени (как в оригинальном/сыром виде, так и в обработанном формате).
96. Система должна быть способным в автоматически изменять весовые коэффициенты
для устройств в ответ на атаки в сети.
97. Система должна обеспечивать способность отсылать уведомление о тревогах
определенными методами (т.е., SNMP trap, e-mail, и т.д.).
98. Система должна иметь встроенные механизмы управления потоком событий, которые
сотрудники службы безопасности могут использовать для управления своей работой.
99. Система должна обеспечивать двунаправленную интеграцию со сторонним
программным обеспечением службы поддержки, которую сотрудники службы безопасности
могут использовать для управления своей работой.
Требования к управлению рисками
100.Система должна обеспечивать сбор и нормализацию конфигураций свичей,
маршрутизаторов, брандмауэров, и IPS.
101.Система должна быть способным сравнить конфигурации устройств и выявить их
изменения.
102.Система должна выявлять и оповещать об изменениях конфигурации, если эти
изменения выходят за рамки разрешенных пределов и политик.
103.Система должна понимать топологию сети уровня 2 / уровня 3 согласно
общепринятой модели OSI. Пользователь должен иметь возможность отбирать необходимые
устройства (трафик) по подсетям, портам, протоколам.
104.Система должна иметь возможность приоритезировать уязвимости базируясь на
конфигурации.
105.Система должна позволять пользователю запустить сценарий атаки «что если» против
конфигурации сети.
106.Система должна поддерживать сбор информации с серверов и рабочих станций под
управлением ОС Microsoft.
107.Система должна поддерживать сбор информации с серверов и рабочих станций под
управлением ОС Linux/Unix и др.
108.Система должна поддерживать сбор информации с баз данных класса предприятия,
таких как Oracle, MySQL
109.Система должна поддерживать сбор информации с коммерческих приложений (т.e.
SAP, Web, и др.).
110.Система должна поддерживать сбор информации с директорий (т.e. AD, LDAP).
111.Система должна поддерживать сбор информации о потоках трафика по flow
протоколам (т.e. Netflow, J-Flow, S-Flow и др.).
112.Система должна поддерживать сбор информации с систем управления сетью
(например, Cisco LMS).
113.Система должна поддерживать сбор информации с инфраструктуры сети (т.e.
switches, routers, и др.).
5.1.1. Требования к квалификации персонала Поставщика
114.Специалист(ы) Поставщика осуществляющие сопутствующие услуги, должны
обладать опытом внедрения Системы и сертификатами, подтверждающими знания по системе
SIEM от производителя поставляемого товара. Для подтверждения требуется предоставить
резюме специалиста(ов) и копию указанного сертификата. Резюме специалиста должно быть
подписано руководителем компании и подтверждено печатью.
5.1.2. Требования к надёжности
115.Система должна функционировать круглосуточно в бесперебойном режиме, за
исключением случаев проведения профилактических или других работ связанных с
обеспечением функционирования Системы;
116.Система должна включать инструментарий, позволяющий автоматическое резервное
копирование конфигурации Системы, на удалённый физический ресурс, с возможностью
последующего полного восстановления Системы, в случае выхода из строя аппаратной
составляющей;
5.1.3. Требования к созданию правил корреляции
117.Настройка правил корреляции производится Поставщиком на основании
предварительно согласованного списка правил корреляции, переданного Фондом Поставщику
до начала внедрения. Поставщик обязан, при необходимости, предоставить консультации и
рекомендации по составлению правил.
118.Подключение некоторых типов источников может потребовать изменения
конфигурации источников событий. В данном случае Поставщик обязан предоставить
инструкции либо рекомендации по необходимым изменениям. Непосредственно изменения
конфигурации источников событий выполняются силами Фонда. В случае задержки в
настройке конфигурации источников событий со стороны Фонда Исполнитель ответственности
не несет.
5.1.4. Требования к защите информации от несанкционированного доступа
119.Система, должна обеспечивать защитой от несанкционированного доступа:
− идентификацию и аутентификацию пользователей системы при подключении к
системе;
− обеспечение настраиваемой возможности разграничения доступа пользователей и
групп пользователей к данным, группам данных, действиям, типам действий;
− обеспечение в настройках системы возможности ведения журналов аудита,
регистрирующих действия пользователей.
5.1.5. Требования к патентной частоте
120.Предлагаемое к использованию программное обеспечение должно быть
лицензировано фирмой-производителем;
121.Решения по использованию программного обеспечения должны приниматься с
учётом обеспечения поддержки его функционирования производителем.
5.2. Требования к видам обеспечения
5.2.1. Требования к программному обеспечению системы
122.Лицензии для Системы должны позволять сбор событий информационной
безопасности в количество событий в секунду и поддержку неограниченного количества
источников событий Системы для осуществления автоматизации процесса сбора событий
информационной безопасности Заказчика;
123.Лицензии на использование Системы должны быть зарегистрированы на Заказчика;
124.Лицензии на использование Системы не должны быть ограничены по времени
использования.
6. НАСТРОЙКА СИСТЕМЫ
125. Перед началом настройки программного обеспечения Системы Поставщик обязан
предоставить Заказчику список специалистов Поставщика, осуществляющего сопутствующие
услуги;
126. Поставщик должен предоставить Заказчику возможность контроля и надзора за
ходом выполнения настроек.
127.Поставщик должен немедленно известить Заказчика и до получения от него указаний,
приостановить настройки, при обнаружении:
− Возможных неблагоприятных для Заказчика последствий выполнения его указаний о
способе выполнения настроек;
− Иных, не зависящих от Поставщика обстоятельств, угрожающих годности или
качеству результатов внедрения Системы, либо создающих невозможность завершения их в
срок.
128.Поставщик должен исполнять полученные в ходе проведения настроек указания
Заказчика, если такие указания не противоречат условиям настоящей технической
спецификации и не представляют собой вмешательства в оперативно-хозяйственную
деятельность Поставщика.
Таблица 2 Требования к перечню сопутствующих настроек
№
1
2
Этап
Проектирование
Установка
настройка
Системы
Наименование настроек
Актуализация
и
согласование
перечня
источников
событий
Заказчика.
и Установка
программного
Системы
Форма завершения
Список источников событий
для автоматизации процесса
сбора событий
информационной
безопасности.
и
настройка Установленное лицензионное
обеспечения для программное
обеспечение
Системы
Настройка основных параметров Перечень
подключенных
системы; подключение источников источников
в
каталоге
событий согласно утвержденному установленной Системы.
списку (список
подключаемых
источников утверждается Фондом с
участием
Поставщика
перед
началом внедрения).
Проверка
системы.
работоспособности Инструкция по подключению
источников событий
тестового
3
Опытная
эксплуатация
Выполнение
данных
4
Пусконаладочные
работы
Проведение
испытаний
Ввод
в
эксплуатацию
3
сбора Отчёт
о
выявленных
несоответствиях
и
проведении тестирования
приёмо-сдаточных Протокол приёмо-сдаточных
испытаний
промышленную Акт ввода в промышленную
эксплуатацию
7. ТРЕБОВАНИЯ К ГАРАНТИЙНОМУ ОБСЛУЖИВАНИЮ
В состав гарантийного обслуживания Системы должны быть включены следующее:
129.Поставщик в течении 1 года после подписания акта о приемке выполненных работ
осуществляет гарантийное обслуживание Системы без взимания дополнительной платы;
Гарантийное обслуживание Системы Поставщиком включает в себя:
 консультативная помощь по администрированию и эксплуатации Системы;
 проведение восстановительных работ при возникновении проблем.
130.Товар должен предоставляться с гарантийной поддержкой производителя сроком не
менее одного года, включая, но не ограничиваясь, следующим:
 доступ к обновлению системного программного обеспечения;
 доступ к обновлению парсеров и исправлений безопасности;
 доступ к web порталу поддержки производителя в режиме не менее чем 7 дней в неделю
по 24 часа в день;
 возможность создания запросов на техническую поддержку по телефону и по
электронной почте в режиме не менее чем 7 дней в неделю по 24 часа в день;
 возможность указывать приоритет запросов;
 замену вышедшего из строя оборудования.
8. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ
131.Документация по Системе должна включать минимальный пакет документов согласно
Таблице 2;
132.Вся документация должна вестись Поставщиком на русском языке;
Заказчик
Поставщик
____________________ ФИО
М.П.
____________________ ФИО
М.П.