Any company that taking care about information security should have a some security requirements or standard.
Usually it's huge and very formal document created for using within the company. It's OK.
But, what's happens when some new information system (product, solution ) have purchased from foreign supplier and going to integration with your corporate environment? Sure thing this new system must pass your security audit. Lucky you if everything ok. But what could you do if not? Even if couple of words about security exist inside contract or agreement with supplier you will spent a lot of time pushing him to close security holes and slow down whole integration and whole project.
From my point of view the best way to save your time and money is to create short and concrete document calling "Security requirement for new IS " and make whole this document a part of agreement with supplier.
Sample of this document you can find below :
General IS Security Requirements
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.Unauthorised 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
Privileged access requirements
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
Audit requirements
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)
Updates and antivirus software requirements
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 Windows 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)
Password and authentication requirements
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
Data storing and exchange requirements
External systems
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/Reverse proxy 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)
DMZ
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
Company’s network
9.Only secure protocols of interaction between servers and information systems should be used, if it is possible
Service Level Agreements
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
Usually it's huge and very formal document created for using within the company. It's OK.
But, what's happens when some new information system (product, solution ) have purchased from foreign supplier and going to integration with your corporate environment? Sure thing this new system must pass your security audit. Lucky you if everything ok. But what could you do if not? Even if couple of words about security exist inside contract or agreement with supplier you will spent a lot of time pushing him to close security holes and slow down whole integration and whole project.
From my point of view the best way to save your time and money is to create short and concrete document calling "Security requirement for new IS " and make whole this document a part of agreement with supplier.
Sample of this document you can find below :
General IS Security Requirements
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.Unauthorised 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
Privileged access requirements
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
Audit requirements
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)
Updates and antivirus software requirements
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 Windows 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)
Password and authentication requirements
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
Data storing and exchange requirements
External systems
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/Reverse proxy 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)
DMZ
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
Company’s network
9.Only secure protocols of interaction between servers and information systems should be used, if it is possible
Service Level Agreements
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
No comments:
Post a Comment