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

Содержание

1. ИС должны устанавливаться с максимально возможным уровнем безопасности
   
2. Все сервисные и неиспользуемые для работы ИС учетные записи (в том числе стандартные для ОС или приложений) должны быть закрыты, или заблокированы
   
3. На ИС должны быть запущены только те сервисы и приложения, которые необходимы для функционирования данной ИС или выполнения сервисных и бизнес-задач Компании
   
4. Запрещается несанкционированная установка и запуск на ИС сервисов, обеспечивающих функционирование и сервисные функции сети передачи данных (DHCP, DNS, все виды PROXY, NTP, SMTP relay, Gating/Routing, LPD, VPN, и т.п.)
   
5. Все внедряемые информационные системы должны проходить обязательный технический аудит в Группе безопасности ИС, состоящий из таких этапов:
   

• Согласование архитектуры системы на этапе выбора поставщика или технического решения
  
• Аудит технической документации на выбранное решение или систему[ITGC05] (частично)
  
• Аудит установленной ИС перед запуском в эксплуатацию на соблюдение требований нормативных документов
  

6. При внесении значительных изменений в системы (переход на новое оборудование, смена версии ОС либо прикладного ПО) обязательным является проведение технического аудита в объеме п.5
   
7. Тестовые системы и системы разработки не должны содержать конфиденциальных данных, являющихся собственностью Компании, либо содержать их в закодированном, неполном и/или искаженном виде
   

1. Information systems (IS) should be installed with maximum possible level of security (“hardened” mode)
   
2. All unused or service accounts (including OS/application standard ones) should be disabled or deactivated
   
3. On IS must be started only those services and applications which are required for functioning of this IS or Company’s business-processes
   
4. 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
   
5. 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
  

6. After making considerable alterations to the system (equipment, OS or application upgrades) it obligatory to conduct technical audit like in p.5
   
7. Test and development systems/instances should not contain any confidential information, either contain it in coded, incomplete and/or distorted way
   

1. Удаленная аутентификация пользователя с привилегированными полномочиями должна быть запрещена везде, где это технически осуществимо
   
2. Удаленный привилегированный доступ к ИС допускается только в случае производственной необходимости, достаточного обоснования и только по защищенным протоколам (ssh, sftp/scp, SecureVNC, и т.п.)
   
3. Все действия в ИС, не требующие для выполнения привилегированных прав, должны производиться от имени менее привилегированных учётных записей
   

1. Remote privileged user authentication should be forbidden everywhere where it is technically feasibly
   
2. 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)
   
3. All actions, which do not require privileged rights for its execution should be made on behalf of less privileged accounts
   

1. Все внедряемые, закупаемые или разрабатываемые ИС должны синхронизировать системное время со специально выделенным NTP-сервером, являющимся частью инфраструктуры сети передачи данных
   
2. Логирование в ИС должно быть включено, а журналы аутентификации должны, по возможности, храниться в зашифрованном виде, как минимум три месяца локально, после чего должны копироваться и храниться удалённо в течении, как минимум, трёх лет в специально предназначенной для этого ИС
   
3. Лог файлы должны содержать, как минимум, следующую информацию:
   

• Факт удачной или неудачной попытки регистрации пользователя в системе
  
• Название выполненной операции
  
• Объект, над которым была выполнена данная операция
  
• Логин пользователя, выполнившего операцию
  
• Результат операции
  
• Дату и время события
  
• Все действия привилегированных пользователей (с использованием системных или административных учётных записей)
  

1. All implementing IS should synchronize system time with the specially selected NTP-server, which is a part of network infrastructure
   
2. 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
   
3. 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)
  

1. Обновления от производителей, связанные с безопасностью ИС, должны устанавливаться по мере их выхода и перед установкой, по возможности, тестироваться на тестовых версиях ИС (при наличии таковых)
   
2. При нестабильной работе обновлений, поставщик, либо компания, осуществляющая поддержку ИС, должна в строго оговоренный в Договоре на поддержку срок (но не более семи дней) предложить и внедрить альтернативное решение данной проблемы с безопасностью
   
3. Для ИС на базе ОС Microsoft обязательна установка антивирусного ПО с регулярным и своевременным автоматическим обновлением антивирусных баз
   
4. ОС и прикладное ПО должны быть стабильных последних версий, либо должны быть установлены обновления до тех версий, которые обеспечивают максимальную защищённость системы (отсутствие известных уязвимостей, описанных в различных security bulletin, bugtrack)
   

1. 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
   
2. 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
   
3. For IS based on Microsoft OS it is obligatory to use anti-virus software with the regular automatically bases updates
   
4. 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)
   

9. Создаваемые или приобретаемые ИС должны обеспечивать обязательный механизм идентификации и аутентификации пользователей. Использование систем, которые не поддерживают данный механизм пользователей, запрещено
   
10. ИС не должна выдавать информации о типе и версии системы или приложения (“system banners”) до успешного завершения процедур идентификации и аутентификации. Кроме того, ИС не должна выдавать подсказок или другой справочной информации, которая может облегчить проникновение в систему неавторизованному пользователю
    
11. Проверка введенной информации (логин, пароль) осуществляется только после полного ее ввода. В случае обнаружения ошибки, система не должна уточнять, какие именно данные введены неправильно. Пароль не должен отображаться при вводе
    
12. Логический доступ к ресурсам ИС предоставляется только после успешного прохождения процесса идентификации и аутентификации пользователя
    
13. Запрещается сохранять пароль в открытом виде в ИС, исполняемых файлах, скриптах, базах данных, на серверах и т.п.
    
14. Хранение и передача пароля между клиентом и сервером аутентификации должны осуществляться в защищённом с помощью криптографических алгоритмов виде, или передаваться с использованием защищённых каналов связи
    
15. Создаваемые или приобретаемые ИС должны удовлетворять следующие требования:
    

• Предоставлять пользователям возможность самостоятельно выбирать свой пароль (цифробуквенные комбинации) и менять его в любое время
  
• Контролировать смену заданного администратором первичного пароля доступа при первом входе в систему и проверяет качество вводимого пароля в соответствии с определенными требованиями (определённое количество символов, требования к структуре – наличие строчных или заглавных букв, цифр, служебных символов, нетривиальность пароля)
  
• Обеспечивать принудительную смену пароля через предварительно установленный промежуток времени
  
• Иметь возможность заблаговременного оповещения пользователей о необходимости смены пароля (посредством сообщений/подсказок или почтовых рассылок на электронные адреса пользователей)
  
• Если пользовательский пароль до установленной даты не будет изменён, система должна иметь возможность блокировки учётной записи
  
• Обеспечивает хранение истории паролей пользователей, как минимум, за последние 12 месяцев для предотвращения повторного их использования
  
• Иметь возможность установки количества неудачных попыток аутентификации, после чего пользовательская учётная запись должна блокироваться на заранее определённый срок
  
• Иметь возможность установки длительности пользовательской сессии, после чего она должна прерываться
  

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

1. Implementing IS should provide the obligatory authentication mechanism for users. Use of the systems which do not support this mechanism is forbidden
   
2. 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
   
3. 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
   
4. Logical access to IS resources should be granted only after the successful user identification and authentication
   
5. It is forbidden to save password undisguised in IS, executable files, scripts, databases, on servers, etc.
   
6. 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
   
7. 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
  

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

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

• HTTPS с длиной ключа не менее 128 бит
  
• SFTP
  
• S/MIME с использованием PGP
  
• Канал передачи Х25 либо VPN
  

2. Удалённая поддержка ПО может осуществляться поставщиками только с использованием канала VPN
   
3. При невозможности использовать способы передачи, описанные в п.6.1, передаваемые данные должны быть зашифровать с применением стойких криптографических алгоритмов
   
4. Если ИС необходим доступ к системам или базам данных, расположенным в зоне внутренней сети Компании, то эти системы должны состоять как минимум из двух серверов (WEB/Gateway server и Application Server) для размещения их в зонах DMZ или Application Zone. Также необходимо, чтобы обмен данными между этими серверами был зашифрован
   
5. Если ИС предполагают работу с индивидуальными данными клиентов (почта для абонентов, просмотр состояния счетов, корзины электронных магазинов и т.д.) то соединение обязательно должно использовать протокол передачи, использующий шифрование (https, iiop/ssl)
   

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

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

1. 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
  

2. Remote software support can be carried out by suppliers only with the use of VPN
   
3. 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
   
4. 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
   
5. 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)
   

6. 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
   
7. 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
   
8. 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
   

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

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

1. 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