Реферат: Приложение 3 Требования по безопасности Содержание

Приложение 3


Требования по безопасности


Содержание



1. Введение 3

1.1. Цель данного документа 3

2. Общие требования к ИС 4

3. Требования к привилегированному доступу 5

4. Требования к аудиту 6

5. Требования к обновлениям и антивирусному ПО 7

6. Требования к аутентификации и паролям 8

7. Хранение и обмен информацией 9

7.1. С внешними системами 9

7.2. DMZ 9

7.3. В рамках сети Компании 9

8. Service Level Agreements 10

9. Требования к документации 11

10. Требования к организации удаленного доступа для поддержки и внедрения решения. 12

Приложение 1. А – Краткие требования для поставщиков/ Brief requirements for vendors 13

17



^


1.Введение 1.1.Цель данного документа

Требования по безопасности является неотъемлемой частью Открытого Запроса Предложений по выбору поставщика для выполнения работ по реализации системы самообслуживания (для абонентов МТС Украина) на основе интерактивного USSD.


^ 2.Общие требования к ИС
ИС должны устанавливаться с максимально возможным уровнем безопасности

Все сервисные и неиспользуемые для работы ИС учетные записи (в том числе стандартные для ОС или приложений) должны быть закрыты, или заблокированы

На ИС должны быть запущены только те сервисы и приложения, которые необходимы для функционирования данной ИС или выполнения сервисных и бизнес-задач Компании

Запрещается несанкционированная установка и запуск на ИС сервисов, обеспечивающих функционирование и сервисные функции сети передачи данных (DHCP, DNS, все виды PROXY, NTP, SMTP relay, Gating/Routing, LPD, VPN, и т.п.)

Все внедряемые информационные системы должны проходить обязательный технический аудит в Группе безопасности ИС, состоящий из таких этапов:

Согласование архитектуры системы на этапе выбора поставщика или технического решения

Аудит технической документации на выбранное решение или систему[ITGC05] (частично)

Аудит установленной ИС перед запуском в эксплуатацию на соблюдение требований нормативных документов

При внесении значительных изменений в системы (переход на новое оборудование, смена версии ОС либо прикладного ПО) обязательным является проведение технического аудита в объеме п.2.5

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

Удаленный привилегированный доступ к ИС допускается только в случае производственной необходимости, достаточного обоснования и только по защищенным протоколам (ssh, sftp/scp, SecureVNC, и т.п.)

Все действия в ИС, не требующие для выполнения привилегированных прав, должны производиться от имени менее привилегированных учётных записей
^ 4.Требования к аудиту
Все внедряемые, закупаемые или разрабатываемые ИС должны синхронизировать системное время со специально выделенным NTP-сервером, являющимся частью инфраструктуры сети передачи данных

Логирование в ИС должно быть включено, а журналы аутентификации должны, по возможности, храниться в зашифрованном виде, как минимум три месяца локально, после чего должны копироваться и храниться удалённо в течении, как минимум, трёх лет в специально предназначенной для этого ИС

Лог файлы должны содержать, как минимум, следующую информацию:

Факт удачной или неудачной попытки регистрации пользователя в системе

Название выполненной операции

Объект, над которым была выполнена данная операция

Логин пользователя, выполнившего операцию

Результат операции

Дату и время события

Все действия привилегированных пользователей (с использованием системных или административных учётных записей)
^ 5.Требования к обновлениям и антивирусному ПО
Обновления от производителей, связанные с безопасностью ИС, должны устанавливаться по мере их выхода и перед установкой, по возможности, тестироваться на тестовых версиях ИС (при наличии таковых)

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

Для ИС на базе ОС Microsoft обязательна установка антивирусного ПО с регулярным и своевременным автоматическим обновлением антивирусных баз

ОС и прикладное ПО должны быть стабильных последних версий, либо должны быть установлены обновления до тех версий, которые обеспечивают максимальную защищённость системы (отсутствие известных уязвимостей, описанных в различных security bulletin, bugtrack)
^ 6.Требования к аутентификации и паролям
Создаваемые или приобретаемые ИС должны обеспечивать обязательный механизм идентификации и аутентификации пользователей. Использование систем, которые не поддерживают данный механизм пользователей, запрещено

ИС не должна выдавать информации о типе и версии системы или приложения (“system banners”) до успешного завершения процедур идентификации и аутентификации. Кроме того, ИС не должна выдавать подсказок или другой справочной информации, которая может облегчить проникновение в систему неавторизованному пользователю

Проверка введенной информации (логин, пароль) осуществляется только после полного ее ввода. В случае обнаружения ошибки, система не должна уточнять, какие именно данные введены неправильно. Пароль не должен отображаться при вводе

Логический доступ к ресурсам ИС предоставляется только после успешного прохождения процесса идентификации и аутентификации пользователя

Запрещается сохранять пароль в открытом виде в ИС, исполняемых файлах, скриптах, базах данных, на серверах и т.п.

Хранение и передача пароля между клиентом и сервером аутентификации должны осуществляться в защищённом с помощью криптографических алгоритмов виде, или передаваться с использованием защищённых каналов связи

Создаваемые или приобретаемые ИС должны удовлетворять следующие требования:

Предоставлять пользователям возможность самостоятельно выбирать свой пароль (цифробуквенные комбинации) и менять его в любое время

Контролировать смену заданного администратором первичного пароля доступа при первом входе в систему и проверяет качество вводимого пароля в соответствии с определенными требованиями (определённое количество символов, требования к структуре – наличие строчных или заглавных букв, цифр, служебных символов, нетривиальность пароля)

Обеспечивать принудительную смену пароля через предварительно установленный промежуток времени

Иметь возможность заблаговременного оповещения пользователей о необходимости смены пароля (посредством сообщений/подсказок или почтовых рассылок на электронные адреса пользователей)

Если пользовательский пароль до установленной даты не будет изменён, система должна иметь возможность блокировки учётной записи

Обеспечивает хранение истории паролей пользователей, как минимум, за последние 12 месяцев для предотвращения повторного их использования

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

Иметь возможность установки длительности пользовательской сессии, после чего она должна прерываться

Файл или база данных паролей должны хранится отдельно от данных прикладных программ в защищенном при помощи криптографических методов виде, при этом на системном уровне должны применяются стойкие алгоритмы
^ 7.Хранение и обмен информацией 7.1.С внешними системами
Любой процесс обмена конфиденциальной информацией Компании через внешние каналы должен осуществляться с использованием зашифрованного канала передачи данных, с использованием одного из протоколов:

HTTPS с длиной ключа не менее 128 бит

SFTP

S/MIME с использованием PGP

Канал передачи Х25 либо VPN

При невозможности использовать способы передачи, описанные в п.6.1, передаваемые данные должны быть зашифровать с применением стойких криптографических алгоритмов

Если ИС необходим доступ к системам или базам данных, расположенным в зоне внутренней сети Компании, то эти системы должны состоять как минимум из двух серверов (WEB/Gateway server и Application Server) для размещения их в зонах DMZ или Application Zone. Также необходимо, чтобы обмен данными между этими серверами был зашифрован

Если ИС предполагают работу с индивидуальными данными клиентов (почта для абонентов, просмотр состояния счетов, корзины электронных магазинов и т.д.) то соединение обязательно должно использовать протокол передачи, использующий шифрование (https, iiop/ssl)


7.2.DMZ
ИС, расположенные в DMZ, не должны содержать информацию, являющуюся конфиденциальной, либо коммерческой тайной ЗАО «УМС» во избежание ее утечки в результате взлома со стороны публичных сетей.

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

Установка в DMZ серверов под управлением ОС Microsoft запрещена, кроме случаев, когда поставщик гарантирует компенсацию прямых и косвенных убытков в случае компрометации системы


^ 7.3.В рамках сети Компании
Должны использоваться только защищенные протоколы взаимодействия между серверами в информационной системе и между информационными системами, если это возможно.
^ 8.Service Level Agreements
В случае обнаружения критичных уязвимостей в ОС или прикладном ПО внедрённой ИС, при наличии договора на поддержку, поставщик ИС должен, если это возможно предпринять меры по устранению данных уязвимостей (разработка или установка патчей/обновлений) в течении времени описанном в SLA, но не более чем 7 дней с момента обнаружения уязвимости/выхода соответствующего патча



^ 9.Требования к документации
Поставщик должен предоставить следующую документацию для проведения аудита безопасности решения:

9.1 Схема сетевой архитектуры решения согласно предложенному образцу.

Схема обязательно должна включать в себя следующую информацию

- узлы системы предоставляющие сервис, или нуждающиеся в доступе (виртуальный сервер, кластер серверов и т.д - внутренние VLAN/IP subnets

- информационные потоки между VLAN/ IP subnets внутри системы, а также между узами системы и внешними ИС компании. Должно быть указано направление информационного потока, протокол обмена данными, IP адрес источника, IP адрес и порт назначения (сокет).





^ 9.2 Описание узлов системы:


Описание узлов системы предоставляющих сервис, или нуждающиеся в доступе (виртуальный сервер, кластер серверов и.д.

Описание должно включать следующую информацию:

- Тип и версию ОС

- Тип и версию БД (где применимо)

- Тип и версию web/ file /application server (где применимо)

- список запущенных на узле процессов

- список установленных на узле пакетов и их версии


^ 10. Требования к организации удаленного доступа для поддержки и внедрения решения.
Удаленный доступ к ИС компании организовывается путем построения шифрованных VPN туннелей. Доступ осуществляется с применением терминальных access серверов которые являются единственным доступным напрямую для поставщика узлом сети компании. Доступы ко всем остальным ИС осуществляются поставщиком посредством данного терминального сервера.


Требования к терминальному серверу:

- соответствие требованиям к ИС согласно пунктам 2-6 данного документа.

- обеспечение аудита сервера согласно требованиям п4. данного документа

-обеспечения аудита действий поставщиков в продуктивных системах средствами терминального сервера согласно требованиям п4. данного документа.



А – Краткие требования для поставщиков/ Brief requirements for vendors




Общие требования к ИС

ИС должны устанавливаться с максимально возможным уровнем безопасности

Все сервисные и неиспользуемые для работы ИС учетные записи (в том числе стандартные для ОС или приложений) должны быть закрыты, или заблокированы

На ИС должны быть запущены только те сервисы и приложения, которые необходимы для функционирования данной ИС или выполнения сервисных и бизнес-задач Компании

Запрещается несанкционированная установка и запуск на ИС сервисов, обеспечивающих функционирование и сервисные функции сети передачи данных (DHCP, DNS, все виды PROXY, NTP, SMTP relay, Gating/Routing, LPD, VPN, и т.п.)

Все внедряемые информационные системы должны проходить обязательный технический аудит в Группе безопасности ИС, состоящий из таких этапов:

Согласование архитектуры системы на этапе выбора поставщика или технического решения

Аудит технической документации на выбранное решение или систему[ITGC05] (частично)

Аудит установленной ИС перед запуском в эксплуатацию на соблюдение требований нормативных документов

При внесении значительных изменений в системы (переход на новое оборудование, смена версии ОС либо прикладного ПО) обязательным является проведение технического аудита в объеме п.5

Тестовые системы и системы разработки не должны содержать конфиденциальных данных, являющихся собственностью Компании, либо содержать их в закодированном, неполном и/или искаженном виде


General IS Security Requirements

Information systems (IS) should be installed with maximum possible level of security (“hardened” mode)

All unused or service accounts (including OS/application standard ones) should be disabled or deactivated

On IS must be started only those services and applications which are required for functioning of this IS or Company’s business-processes

Unauthorized installation and initiation of services which provide functioning of the data transmission network (i.e. DHCP, DNS, all type of PROXY, NTP, SMTP relay, Gating/Routing, LPD, VPN, etc) are strictly forbidden

All integrated IS should pass an obligatory technical audit in Infosec group, considering such phases:

System architecture concordance on the phase of supplier's choice or technical decision

Audit of technical document on the chosen decision or system

IT audit prior to putting IS into operation in accordance with Company’s statutory acts

After making considerable alterations to the system (equipment, OS or application upgrades) it obligatory to conduct technical audit like in p.5

Test and development systems/instances should not contain any confidential information, either contain it in coded, incomplete and/or distorted way


Требования к привилегированному доступу

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

Удаленный привилегированный доступ к ИС допускается только в случае производственной необходимости, достаточного обоснования и только по защищенным протоколам (ssh, sftp/scp, SecureVNC, и т.п.)

Все действия в ИС, не требующие для выполнения привилегированных прав, должны производиться от имени менее привилегированных учётных записей


Privileged access requirements

Remote privileged user authentication should be forbidden everywhere where it is technically feasibly

Remote privileged access is allowed only in case of production necessity, considerable reasons and only with the use of secure protocols (ssh, sftp/scp, SecureVNC, etc)

All actions, which do not require privileged rights for its execution should be made on behalf of less privileged accounts


Требования к аудиту

Все внедряемые, закупаемые или разрабатываемые ИС должны синхронизировать системное время со специально выделенным NTP-сервером, являющимся частью инфраструктуры сети передачи данных

Логирование в ИС должно быть включено, а журналы аутентификации должны, по возможности, храниться в зашифрованном виде, как минимум три месяца локально, после чего должны копироваться и храниться удалённо в течении, как минимум, трёх лет в специально предназначенной для этого ИС

Лог файлы должны содержать, как минимум, следующую информацию:

Факт удачной или неудачной попытки регистрации пользователя в системе

Название выполненной операции

Объект, над которым была выполнена данная операция

Логин пользователя, выполнившего операцию

Результат операции

Дату и время события

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


Audit requirements

All implementing IS should synchronize system time with the specially selected NTP-server, which is a part of network infrastructure

Logging should be switched on. If it is possible, log files should be stored in encrypted way at least three months locally, whereupon must be copied and kept remotely, at least, three years in specially designed system

Log files should contain at least the following information:

Successful or unsuccessful registration attempts in the system

Name of the executed operation

Object of the operation

User login

Result of operation

Date and time of the event

All privileged users’ actions (at least system and administrative accounts)





Требования к обновлениям и антивирусному ПО

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

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

Для ИС на базе ОС Microsoft обязательна установка антивирусного ПО с регулярным и своевременным автоматическим обновлением антивирусных баз

ОС и прикладное ПО должны быть стабильных последних версий, либо должны быть установлены обновления до тех версий, которые обеспечивают максимальную защищённость системы (отсутствие известных уязвимостей, описанных в различных security bulletin, bugtrack)


^ Updates and antivirus software requirements

Security updates should be installed as soon as they become available. If its possible, such updates should be tested on test IS prior to installation

In case of unstable work of updates, supplier or company, carrying out IS support, owes in strictly stipulated in Agreement on support terms (but less than in seven days) to propose and implement alternative decision of the security issue

For IS based on Microsoft OS it is obligatory to use anti-virus software with the regular automatically bases updates

Operating systems and application software should be of the latest stable release or updated to those versions which provide maximal level of protection (absence of known vulnerabilities, described in different security bulletins, bugtracks)





^ Требования к аутентификации и паролям

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

ИС не должна выдавать информации о типе и версии системы или приложения (“system banners”) до успешного завершения процедур идентификации и аутентификации. Кроме того, ИС не должна выдавать подсказок или другой справочной информации, которая может облегчить проникновение в систему неавторизованному пользователю

Проверка введенной информации (логин, пароль) осуществляется только после полного ее ввода. В случае обнаружения ошибки, система не должна уточнять, какие именно данные введены неправильно. Пароль не должен отображаться при вводе

Логический доступ к ресурсам ИС предоставляется только после успешного прохождения процесса идентификации и аутентификации пользователя

Запрещается сохранять пароль в открытом виде в ИС, исполняемых файлах, скриптах, базах данных, на серверах и т.п.

Хранение и передача пароля между клиентом и сервером аутентификации должны осуществляться в защищённом с помощью криптографических алгоритмов виде, или передаваться с использованием защищённых каналов связи

Создаваемые или приобретаемые ИС должны удовлетворять следующие требования:

Предоставлять пользователям возможность самостоятельно выбирать свой пароль (цифробуквенные комбинации) и менять его в любое время

Контролировать смену заданного администратором первичного пароля доступа при первом входе в систему и проверяет качество вводимого пароля в соответствии с определенными требованиями (определённое количество символов, требования к структуре – наличие строчных или заглавных букв, цифр, служебных символов, нетривиальность пароля)

Обеспечивать принудительную смену пароля через предварительно установленный промежуток времени

Иметь возможность заблаговременного оповещения пользователей о необходимости смены пароля (посредством сообщений/подсказок или почтовых рассылок на электронные адреса пользователей)

Если пользовательский пароль до установленной даты не будет изменён, система должна иметь возможность блокировки учётной записи

Обеспечивает хранение истории паролей пользователей, как минимум, за последние 12 месяцев для предотвращения повторного их использования

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

Иметь возможность установки длительности пользовательской сессии, после чего она должна прерываться

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


^ Password and authentication requirements

Implementing IS should provide the obligatory authentication mechanism for users. Use of the systems which do not support this mechanism is forbidden

IS should not give out any information about system type and version or any prompts or “system banners” prior to successful completion of authentication procedures

Verification of input information (login, password) is carried out only after its complete input. In case of an error, the system must not specify, whether user name or password entered incorrectly. Password should not be displayed while being entered

Logical access to IS resources should be granted only after the successful user identification and authentication

It is forbidden to save password undisguised in IS, executable files, scripts, databases, on servers, etc.

Password storage and transmission between client and authentication server should be carried out in protected by cryptographic algorithms way or with the use of protected communication channels

Created or acquired IS should comply the following requirements:

To grant users an opportunity to choose their password independently (letter-digital combinations) and change it at any time

To control changing of the primary password set by administrator during first logon to the system and checks up its quality in compliance with certain requirements (length, structure requirements - small or capital letters, digits, non-trivial password, etc)

To provide forced changing of password through the preliminary set interval of time

To have an opportunity to notify users in advance about the necessity of password changing (by means of reports/prompts or emails)

If user password was not changed until the date, set in advance, the system should have an opportunity to block user account

Provides storage for user's password history, at least, for the last 12 months for prevention of repeated use

To have an opportunity to set amount of unsuccessful login attempts, whereupon user account should be blocked for certain period

To have an opportunity to predefine user session duration, whereupon it should be interrupted

Password file or database owe kept separately from application programs using cryptographic methods. Only proof algorithms should be used





Хранение и обмен информацией

С внешними системами

Любой процесс обмена конфиденциальной информацией Компании через внешние должен осуществляться с использованием зашифрованного канала передачи данных, с использованием одного из протоколов:

HTTPS с длиной ключа не менее 128 бит

SFTP

S/MIME с использованием PGP

Канал передачи Х25 либо VPN

Удалённая поддержка ПО может осуществляться поставщиками только с использованием канала VPN

При невозможности использовать способы передачи, описанные в п.6.1, передаваемые данные должны быть зашифровать с применением стойких криптографических алгоритмов

Если ИС необходим доступ к системам или базам данных, расположенным в зоне внутренней сети Компании, то эти системы должны состоять как минимум из двух серверов (WEB/Gateway server и Application Server) для размещения их в зонах DMZ или Application Zone. Также необходимо, чтобы обмен данными между этими серверами был зашифрован

Если ИС предполагают работу с индивидуальными данными клиентов (почта для абонентов, просмотр состояния счетов, корзины электронных магазинов и т.д.) то соединение обязательно должно использовать протокол передачи, использующий шифрование (https, iiop/ssl)



DMZ

ИС, расположенные в DMZ, не должны содержать информацию, являющуюся конфиденциальной, либо коммерческой тайной ЗАО «УМС» во избежание ее утечки в результате взлома со стороны публичных сетей.

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

Установка в DMZ серверов под управлением ОС Microsoft запрещена, кроме случаев, когда поставщик гарантирует компенсацию прямых и косвенных убытков в случае компрометации системы



В рамках сети Компании

Должны использоваться только защищенные протоколы взаимодействия между серверами в информационной системе и между информационными системами, если это возможно.


Data storing and exchange requirements

External systems

Any confidential data exchange process through external channels should be carried out with the use of encrypted data channel, with the use of one of the following protocols:

HTTPS with key not less than 128 bit

SFTP

S/MIME with the use of PGP

Х25 data exchange channel or VPN

Remote software support can be carried out by suppliers only with the use of VPN

Whether it is impossibility to use transmission methods, described in p.6.1, any confidential or sensitive information should be encrypted with the use of proof cryptographic algorithms

If IS requires an access to the Company systems or databases, located in Company's intranet, these IS must consist at least of two servers (WEB/Gateway server and Application Server) for placing them in DMZ or Application Zone. It is also necessary that exchange by information between these servers was in encrypted

If IS supposed to work with customer individual information (mail for subscribers, state of accounts, baskets of electronic shops, etc) then encrypted protocols should be used (https, iiop/ssl)



DMZ

IS, located in DMZ, must not contain any confidential information in order to avoid its loss as a result of hack attacks from public networks

IS which is assumed to place in DMZ should be built exceptionally on products and operating systems, satisfying all security requirements and having good producer's support

Setting up of the servers, operating under OS Microsoft in DMZ is forbidden, except for the cases when supplier guarantees compensation of all direct and indirect damages in case of system compromising



Company’s network

Only secure protocols of interaction between servers and information systems should be used, if it is possible


^ Service Level Agreements

В случае обнаружения критичных уязвимостей в ОС или прикладном ПО внедрённой ИС, при наличии договора на поддержку, поставщик ИС должен, если это возможно предпринять меры по устранению данных уязвимостей (разработка или установка патчей/обновлений) в течении времени описанном в SLA, но не более чем 7 дней с момента обнаружения уязвимости/выхода соответствующего патча


Service Level Agreements

In case of finding out critical OS/application vulnerabilities, IS supplier owe if it is possible to undertake certain actions on the removal of these vulnerabilities (development or installing of patches/updates) within the time described in SLA, but noе more than 7 days from the moment of vulnerability detection/proper patch release












ЗАО «УМС» Page of