Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 33.117  Word version:  17.2.0

Top   Top   Up   Prev   Next
1…   4.2…   4.2.3…   4.2.3.4…   4.2.3.5…   4.2.4…   4.3…   4.3.4…   4.4… 
4.2.3.4 Authentication and authorization  4.2.3.4.1 Authentication policy  4.2.3.4.2 Authentication attributes  4.2.3.4.3 Password policy  4.2.3.4.4 Specific Authentication use cases  4.2.3.4.5 Policy regarding consecutive failed login attempts  4.2.3.4.6 Authorization and access control 
...

 

4.2.3.4  Authentication and authorization  p. 26

4.2.3.4.1  Authentication policy  p. 26
4.2.3.4.1.1  System functions shall not be used without successful authentication and authorization   p. 26
Requirement Name:
System functions shall not be used or accessed without successful authentication and authorization.
Requirement Description:
The usage of a system function without successful authentication on basis of the user identity and at least one authentication attribute (e.g. password, certificate) shall be prevented. System functions comprise, for example network services (like SSH, SFTP, Web services), local access via a management console, local usage of operating system and applications. This requirement shall also be applied to accounts that are only used for communication between systems. An exception to the authentication and authorization requirement are functions for public use such as those for a Web server on the Internet, via which information is made available to the public.
Security Objective references:
tba.
Test case:
Test Name:
TC_SYS_FUN_USAGE
Purpose:
To ensure that system functions shall not be used without successful authentication and authorization.
Procedure and execution steps:
Pre-Conditions:
  1. The manufacturer shall supply the list of system functions which include network services, local access via a management console, local usage of operating system and applications.
  2. The manufacturer shall supply the list of access entries for system functions.
Execution Steps:
The accredited evaluator's test lab is required to execute the following steps:
  1. The tester verifies, based on his/her own experience, that the list is adequate.
  2. The tester verifies that the access entries to use system functions, which are listed by the manufacturer, require successful authentication on basis of the user name and at least one authentication attribute. This applies to both system functions that are locally accessible and those that are remotely accessible via a network interface.
Expected Results:
  1. The network product does not allow access to any system function provided by the manufacturer without a successful user authentication.
Expected format of evidence:
A testing report provided by the testing agency which will consist of the following information:
  • Description of executed tests and commands
  • Relevant output (e.g. Screenshot)
  • Test result (Passed or not)
Up
4.2.3.4.1.2  Accounts shall allow unambiguous identification of the user   p. 27
Requirement name:
The network product shall use accounts that allow unambiguous identification of the user.
Requirement Description:
Users shall be identified unambiguously by the network product. The network product shall support assignment of individual accounts per user, where a user could be a person, or, for Machine Accounts, an application, or a system. The network product shall not enable the use of group accounts or group credentials, or sharing of the same account between several users, by default. The network product shall support a minimum number of 50 individual accounts per user data base if not explicitly specified in a SCAS of a particular network product, so that accountability for each user is ensured even in large operator networks. The network product shall not support user access credentials unrelated to an account.
Security Objective references:
tba.
Test case:
Test Name:
TC_ACCOUNT_DOCUMENTATION
Purpose:
To ensure that documentation of the network product does not encourage or require the use of group accounts, group credentials, or sharing of the same account between several users. To ensure that the network product does not support credentials unrelated to an account.
Procedure and execution steps:
Pre-Conditions:
  1. All user and group data bases for names and credentials supported by the network product are identified in the documentation accompanying the network product.
  2. All predefined accounts and groups are identified in the documentation accompanying the Network Product.
  3. Instructions of how administrator users can add accounts, groups, and credentials to the database(s) are provided in the documentation accompanying the Network Product.
  4. The operations manual describes OAM user and group concepts supported by the network product.
Execution Steps:
The accredited evaluator's test lab is required to execute the following steps:
  1. Review the system documentation (in particular operations manual) whether it encourages or requires the use of group accounts, group credentials, or sharing of the same account between several users.
  2. Review the system documentation whether the network product requires or supports entering credentials unrelated to an account, in order to perform specific actions, e.g. to enter a "master password" for access to privileged functions.
Expected Results:
  1. The reviewed documentation is in line with the requirement.
Expected format of evidence:
Test report that lists the reviewed documentation (incl. release dates and versions) and the findings.
Test Name:
TC_ACCOUNT_DEFAULTS
Purpose:
To ensure that the default setup of the network product does not enable the use of group accounts or group credentials.
Procedure and execution steps:
Pre-Conditions:
  1. All user and group data bases for names and credentials supported by the network product are identified in the documentation accompanying the network product.
  2. Instructions of how administrator users can view all existing accounts, groups, and protected credentials in the databases are provided in the documentation accompanying the Network Product.
Execution Steps:
The accredited evaluator's test lab is required to execute the following steps:
  1. After login via an account with necessary access rights (e.g. Admin) search in the databases for any group credentials. Example for Linux®: /etc/gshadow
Expected Results:
  1. No group credentials are defined.
Expected format of evidence:
Test report that lists the reviewed documentation, reviewed user and group databases, and the findings.
Test Name:
TC_ACCOUNT_NUMBER
Purpose:
To ensure that a minimum number of individual accounts per user data base is supported. The minimum number is defined in the requirement description of this clause.
Procedure and execution steps:
Pre-Conditions:
All user data bases for names and credentials supported by the network product are identified in the documentation accompanying the network product.
Execution Steps:
The accredited evaluator's test lab is required to execute the following steps:
Create accounts until the minimum number of accounts is reached.
Expected Results:
Successful creation of the minimum number of accounts.
Expected format of evidence:
Test report that lists the reviewed documentation, reviewed user databases, and the findings.
Up
4.2.3.4.2  Authentication attributes  p. 29
4.2.3.4.2.1  Account protection by at least one authentication attribute  p. 29
Requirement Name:
Account protection by at least one authentication attribute.
Requirement Description:
The various user and machine accounts on a system shall be protected from misuse. To this end, an authentication attribute is typically used, which, when combined with the user name, enables unambiguous authentication and identification of the authorized user.
Authentication attributes include:
  • Cryptographic keys
  • Token
  • Passwords
This means that authentication based on a parameter that can be spoofed (e.g. phone numbers, public IP addresses or VPN membership) is not permitted. Exceptions are attributes that cannot be faked or spoofed by an attacker.
Security Objective references:
tba.
TEST CASE:
Test Name:
TC_ACCOUNT_PROTECTION
Purpose:
To ensure that all accounts are protected by at least one authentication attribute.
Procedure and execution steps:
Pre-Conditions:
  1. All predefined accounts are identified in the documentation accompanying the Network Product.
  2. Instructions of how to create new accounts are provided in the documentation accompanying the Network Product.
  3. Instructions of how administrator user can view all existing accounts in the database are provided in the documentation accompanying the Network Product.
Execution Steps:
The accredited evaluator's test lab is required to execute the following steps:
  1. After login via account with necessary access rights (e.g. Admin) search in the database for any undocumented account.
  2. Attempt login to all predefined accounts identified (either documented or not) with and without using the respective authentication attribute.
  3. Create a new account by following instructions in documentation.
  4. Attempt login to the newly created account.
Expected Results:
  1. It is not possible to login to any predefined account without using at least one authentication attribute that satisfies the conditions in the requirement.
  2. It is not possible to login to any newly created account without usage of at least one authentication attribute that satisfies the conditions in the requirement.
Expected format of evidence:
tba
Up
4.2.3.4.2.2  Predefined accounts shall be deleted or disabled   p. 30
Requirement Name:
Predefined accounts shall be deleted or disabled.
Requirement Description:
All predefined or default accounts shall be deleted or disabled. Many systems have default accounts (e.g. guest, ctxsys), some of which are preconfigured with or without known passwords. These standard users shall be deleted or disabled. Should this measure not be possible the accounts shall be locked for remote login. In any case disabled or locked accounts shall be configured with a complex password as specified in clause 4.2.3.4.3.1 Password Structure. This is necessary to prevent unauthorized use of such an account in case of misconfiguration.
Exceptions to this requirement to delete or disable accounts are accounts that are used only internally on the system involved and that are required for one or more applications on the system to function. Also for these accounts remote access or local login shall be forbidden to prevent abusive use by users of the system.
Security Objective references:
TBA.
TEST CASE:
Test Name:
TC_PREDEFINED_ACCOUNT_DELETION
Purpose:
To ensure that predefined accounts are deleted or disabled unless there is specific exception as defined in the requirement 4.2.3.4.2.2.
Procedure and execution steps:
Pre-Conditions:
  1. All predefined accounts are identified in the documentation accompanying the Network Product.
  2. Instructions of how administrator user can view all existing accounts in the database are provided in the documentation accompanying the Network Product.
Execution Steps:
  1. Check in documentation of the existence of any documented predefined account and what is the reason for existence.
  2. After login via account with necessary access rights (e.g. Admin) search in the database for any undocumented account.
  3. Check the password complexity of such existing predefined accounts according to the test provided in clause 4.2.3.4.3.1.
  4. Attempt remote login to such predefined accounts.
Expected Results:
  1. Predefined accounts are either deleted/ disabled or, if existing, the reason is in accordance with the requirement exception.
  2. If there are active predefined accounts in accordance with the requirement exception then there is no remote login possibility.
  3. If predefined account is either disabled or locked then it shall anyway fulfil the complex password requirements as specified in clause 4.2.3.4.3.1 after enabling or unlocking it.
Expected format of evidence:
Evidence can be presented in the form of screenshot/screen-capture on showing for example a remote login failure or complexity of a password of e.g. locked or disabled accounts.
Up
4.2.3.4.2.3  Predefined or default authentication attributes shall be deleted or disabled   p. 31
Requirement Name:
Predefined or default authentication attributes shall be deleted or disabled.
Requirement Description:
Predefined or default authentication attributes shall be deleted or disabled.
Normally, authentication attributes such as password or cryptographic keys will be preconfigured from producer, vendor or developer of a system. Such authentication attributes shall be changed by automatically forcing a user to change it on 1st time login to the system or the vendor provides instructions on how to manually change it.
Security Objective references:
TBA.
TEST CASE:
Test Name:
TC_PREDEFINED_AUTHENTICATION_ATTRIBUTES_DELETION
Purpose:
To ensure that predefined or default authentication attributes are deleted or disabled as defined in the requirement 4.2.3.4.2.3.
Procedure and execution steps:
Pre-Conditions:
  1. Instructions of how administrator user can view all existing accounts in the database are provided in the documentation accompanying the Network Product.
  2. All predefined accounts and their respective predefined or default passwords are identified in the documentation accompanying the Network Product.
Execution Steps:
  1. Check in documentation of the existence of any documented predefined account and what is the login password or if any cryptographic key for such accounts is preinstalled.
  2. After login via account with necessary access rights (e.g. Admin) search in the database for any undocumented account.
  3. Attempt login to such predefined accounts if existing.
Expected Results:
  1. When login is attempted to any predefined account the user is automatically forced to change login password at first time login to the system.
  2. If there is no automatic password change enforced then recommendation and clear instructions of how to manually change the password or how to create and reinstall a new cryptographic key exist in the documentation.
Expected format of evidence:
Evidence can be presented in the form of screenshot/screen-capture on how the network product prompts for password change at first login. Also extracts from product documentation with clear instructions of how to change any default password or cryptographic key.
Up
4.2.3.4.3  Password policy  p. 32
4.2.3.4.3.1  Password Structure   p. 32
Requirement Name:
Password Complexity rule
Requirement Description:
The setting by the vendor shall be such that a network product shall only accept passwords that comply with the following complexity criteria:
  1. Absolute minimum length of 8 characters (shorter lengths shall be rejected by the network product). It shall not be possible setting this absolute minimum length to a lower value by configuration.
  2. Comprising at least three of the following categories:
    • at least 1 uppercase character (A-Z)
    • at least 1 lowercase character (a-z)
    • at least 1 digit (0-9)
    • at least 1 special character (e.g. @;!$.)
The network product shall use a default minimum length of 10 characters. The minimum length of characters in the passwords shall be configurable by the operator. The default minimum length is the value configured by the vendor before any operator-specific configuration has been applied. The special characters may be categorized in sets according to their Unicode category.
The network product shall at least support passwords of a length of 64 characters or a length greater than 64 characters.
If a central system is used for user authentication, password policy is performed on the central system and additional assurance shall be provided that the central system enforces the same password complexity rules as laid down for the local system in this subclause. If a central system is not used for user authentication, the assurance on password complexity rules shall be performed on the Network Product.
When a user is changing a password or entering a new password, the system checks and ensures that it meets the password requirements. Above requirements shall be applicable for all passwords used (e.g. application-level, OS-level, etc.).
Security Objective references:
Hardening.
Test case:
Test Name:
TC_PASSWORD_STRUCT
Purpose:
To verify that password structure adheres to the password complexity criteria.
To verify that password structure is configurable as per the complexity criteria.
Procedure and execution steps:
Pre-Conditions:
  1. Tester has rights to create user account.
Execution Steps:
Execute the following steps:
  1. Test Case 1
    1. The tester logs into Network Product application using admin account.
    2. The tester creates user A following the password complexity criteria.
    3. The tester logs in as user A and attempts to change their password which contains characters from all four categories mentioned in the password complexity criteria.
  2. Test Case 2
    1. The tester logins with privileged account.
    2. The tester modifies password structure policy on the network product by strengthening the policy (e.g. changing the minimum password length to 8+x, changing the minimum number of character Unicode categories to 4).
    3. The tester logs in as user A and attempts to change their password to a password with a strength of less than that permitted by the policy strengthened in step 2 above.
Expected Results:
Tester can change password only if new password fulfil the password complexity criteria
Expected format of evidence:
Evidence suitable for the interface, e.g. screenshot containing the operation result or report in text form.
Up
4.2.3.4.3.2  Password changes   p. 33
Requirement Name:
tba
Requirement Description:
If a password is used as an authentication attribute, then the system shall offer a function that enables a user to change his password at any time. When an external centralized system for user authentication is used it is possible to redirect or implement this function on this system.
Password change shall be enforced after initial login.
The system shall enforce password change based on password management policy. In particular, the system shall enforce password expiry.
Previously used passwords shall not be allowed up to a certain number (Password History).
The number of disallowed previously used passwords shall be:
  • Configurable;
  • Greater than 0;
  • And its default value shall be 3. This means that the network product shall store at least the three previously set passwords. The maximum number of passwords that the network product can store for each user is up to the manufacturer.
When a password is about to expire a password expiry notification shall be provided to the user.
Above requirements shall be applicable for all passwords used(e.g. application-level, OS-level, etc.). An exception to this requirement is machine accounts.
Security Objective references:
tba.
Test case:
Test Name:
TC_PASSWORD_CHANGES
Purpose:
  • To check whether the network product is provisioned with the functionality that enables its user to change the password at any time.
  • The network product enforces password change after initial login.
  • To verify the new password adheres to the password management policy and also to verify whether it has password expiry rule.
  • The network product is configured to disallow specified number of previously used passwords (Password History).
Procedure and execution steps:
Pre-Conditions:
  1. Tester has account with username and password in the network product.
  2. Network product vendor will provide documentation for password management policy which should include details on how to change the password, configure password expiry rule and disallowing specified number of previously used passwords.
  3. The network product vendor shall supply information on how many passwords the network product can store for each user in the password history.
  4. The tester has privilege to modify the number of disallowed previously used password.
Execution Steps:
Execute the following steps:
  1. Positive Test
    Case 1:
    Test case to enforce password change after initial login is covered in clause 4.2.3.4.2.3.
    Case 2:
    1. The tester logs into network product application using a privileged account .
    2. The network product application generates password expiry notification for user Y to force user Y to change the password.
    3. The tester logs out as a privileged user and logs on as user Y.
    4. The tester is prompted to change his password and creates a new password by following the password policy management.
    5. The network product application confirms change in password by, for example, displaying "Password Changed Successfully".
    6. The tester successfully logs-in the network product application as user Y using the new password.
    Case 3:
    1. The tester logs into network product application using a privileged account.
    2. Tester configures the network product application for number of disallowed previously used passwords to x
    3. The tester requests for a password change for user Y.
    4. The tester logs out of the privileged account and logs on as user Y
    5. The tester creates a new password by following the password policy management.
    6. If the password is not equal to any of the x previously used passwords, the network product application still accepts the new password and displays "Password Changed Successfully".
  2. Negative Test
    Case 1:
    Test case to enforce password change after initial login is covered in clause 4.2.3.4.2.3.
    Case 2:
    No negative test case for this scenario.
    Case 3:
    1. The tester logs into network product application using privileged account.
    2. Tester configures the network product application for number of disallowed previously used passwords to x for user Y.
    3. The tester logs out of the privileged account and logs in as user Y
    4. The tester requests for a password change.
    5. The tester sets the new password to a value that is among the last x passwords used previously x times.
Expected Results:
  1. Positive Test
    Case 1:
    Expected result for enforcing password change after initial login is covered in clause 4.2.3.4.2.3.
    Case 2:
    Tester can successfully change the password.
    Case 3:
    Tester can successfully change the password.
  2. Negative Test
    If the negative test case passes, this shows that network product application does not work properly and it violates the requirement.
    Case 1:
    Expected result for enforcing password change after initial login is covered in clause 4.2.3.4.2.3.
    Case 2:
    No negative test case for this scenario.
    Case 3:
    The tester cannot successfully change the password.
Expected format of evidence:
Evidence suitable for the interface, e.g. screenshot contains the operation result.
Up
4.2.3.4.3.3  Protection against brute force and dictionary attacks   p. 35
Requirement Name:
Protection against brute force and dictionary attacks
Requirement Description:
If a password is used as an authentication attribute, a protection against brute force and dictionary attacks that hinder password guessing shall be implemented.
Brute force and dictionary attacks aim to use automated guessing to ascertain passwords for user and machine accounts. Various measures or a combination of these measures can be taken to prevent this.
The most commonly used protection measures are:
  1. Using the timer delay (this delay could be the same or increased depending the operator's policy for each attempt, e.g. double the delay, or 5 minutes delay, or 10 minutes delay) for each newly entered password input following an incorrect entry ("tar pit").
  2. Blocking an account following a specified number of incorrect attempts, refer to 4.2.3.4.5. However it has to be taken into account that this solution needs a process for unlocking and an attacker can force this to deactivate accounts and make them unusable.
  3. Using CAPTCHA to prevent automated attempts (often used for Web applications).
  4. Using a password blacklist to prevent vulnerable passwords.
In order to achieve higher security, it is often meaningful to combine two or more of the measures named here. It is left to the vendor to select appropriate measures.
Above requirements shall be applicable for all passwords used (e.g. application-level, OS-level, etc.). An exception to this requirement is machine accounts.
Security Objective references:
tba.
Test case:
Test Name:
TC_PROTECT_AGAINST_BRUTE_FORCE_AND_DICTIONARY_ATTACKS
This test applies only when the most commonly used protection measures used in the requirement are implemented. If they are not implemented, then the vendor documentation needs to provide alternative measures and the tester needs to develop suitable tests for these alternative measures. Since a vendor is free to select appropriate measures, only the vendor selected measures are to be tested.
Purpose:
To ensure that the system uses a mechanism with adequate protection against brute force and dictionary attacks
To check whether system follows commonly used preventive measures which are mentioned below.
  1. Using the timer delay (e.g. doubling wait times after every incorrect attempt, or 5 minutes delay, or 10 minutes delay) after each incorrect password input ("tar pit").
  2. Blocking an account following a specified number of incorrect attempts (typically 5). However administrator has to keep in account that this solution needs a process for unlocking and an attacker can utilize this process to deactivate the accounts and make them unusable.
  3. Using CAPTCHA to prevent automated attempts (often used for Web interface).
  4. Using a password blacklist to prevent vulnerable passwords.
Procedure and execution steps:
Pre-Conditions:
  1. The password policy management of the network product is configured to use the timer delay after each incorrect password input.
  2. The password policy management is configured to block an account following a specified number of incorrect password attempts (typically 5).
  3. The web interface should be configured with CAPTCHA feature to prevent automated attempts.
  4. CAPTCHA feature is optional and test is done only if implemented.
  5. A password blacklist is configured by the tester. At least one blacklisted password (a password that meets the complexity criteria but is blacklisted) is documented.
  6. Tester has valid credentials as an authorized user.
Execution Steps:
Execute the following steps:
  1. Positive Test
    Case 1:
    Test case to use the timer delay after each incorrect password input is covered in clause 4.2.3.4.5.
    Case 2:
    Test case to block an account following a specified number of incorrect attempts is covered in clause 4.2.3.4.5.
    Case 3:
    1. The network product's login web interface is configured with CAPTCHA feature.
    2. Tester enters the valid password and correct CAPTCHA
    3. Tester can successfully log into the network product.
    In some cases the network product class can have two or more of the attack prevention methods available, which are a combination of Cases 1-3. In such cases the tester will need to run a combination of these test cases.
  2. Negative Test
    Case 1:
    Test case to use the timer delay after each incorrect password input is covered in clause 4.2.3.4.5.
    Case 2:
    Test case to block an account following a specified number of incorrect attempts is covered in clause 4.2.3.4.5.
    Case 3:
    1. The network product's login web interface is configured with CAPTCHA feature.
    2. Tester enters the valid password without CAPTCHA.
    Case 4:
    1. The tester tries to change the password to the blacklisted password.
Expected Results:
  1. Positive Test
    Case 1:
    Expected result for the test case to use the timer delay after each incorrect password input is covered in clause 4.2.3.4.5.
    Case 2:
    Expected result for the test case to block an account following a specified number of incorrect attempts is covered in clause 4.2.3.4.5.
    Case 3:
    Tester can login only after entering the correct password and CAPTCHA.
  2. Negative Test
    Case 1:
    Expected result for the use the timer delay after each incorrect password input is covered in clause 4.2.3.4.5.
    Case 2:
    Expected result for the test case to block an account following a specified number of incorrect attempts is covered in clause 4.2.3.4.5.
    Case 3:
    Tester cannot successfully log in to the network product.
    Case 4:
    Tester cannot successfully change the password to the blacklisted password.
Expected format of evidence:
Evidence suitable for the interface, e.g. screenshot containing the operation result.
Up
4.2.3.4.3.4  Hiding password display   p. 38
Requirement Name:
tba
Requirement Description:
The password shall not be displayed in such a way that it could be seen and misused by a casual local observer. Typically, the individual characters of the password are replaced by a character such as "*". Under certain circumstances it may be permissible for an individual character to be displayed briefly during input. Such a function is used, for ex ample, on smartphones to make input easier. However, the entire password is never output to the display in plaintext.
Above requirements shall be applicable for all passwords used(e.g. application-level, OS-level, etc.). An exception to this requirement is machine accounts.
Security Objective references:
tba.
Test case:
Test Name:
TC_HIDING_PASSWORD_DISPLAY
Purpose:
Verify that the given password is not visible to the casual local observer.
Procedure and execution steps:
Pre-Conditions:
Tester has account with username and password in the network product.
Execution Steps:
Execute the following steps:
  1. The network product will display the login screen.
  2. The tester enters the username.
  3. The tester enters the password.
Expected Results:
The password shall not be displayed in such a way that it could be seen and misused by a casual local observer. Typically, the individual characters of the password are replaced by a character such as "*". Under certain circumstances it may be permissible for an individual character to be displayed briefly during input. Such a function is used, for ex ample, on smartphones to make input easier. However, the entire password is never output to the display in plaintext.
Expected format of evidence:
Evidence suitable for the interface, e.g. screenshot contains the operation results.
Up
4.2.3.4.4  Specific Authentication use cases  p. 39
4.2.3.4.4.1  Network Product Management and Maintenance interfaces   p. 39
Requirement Name:
Network Product Management and Maintenance interfaces
Requirement Description:
The network product management shall support mutual authentication mechanisms, the mutual authentication mechanism can rely on the protocol used for the interface itself or other means.
Security Objective references:
Secure Network Product Administration.
Test case:
Test Name:
TC_MUTUAL_AUTHENTICATION-ON_NETWORK_PRODUCT_MANAGEMENT_PROTOCOLS
Purpose:
Verify that:
There is mutual authentication of entities for management interfaces on the network product.
Procedure and execution steps:
Pre-conditions:
Documentation that lists each of the management protocols and describes the authentication mechanism used for each one.
Execution Steps:
  1. The tester checks that the authentication mechanisms have been configured on the network product.
  2. The tester triggers communication between network product and a test entity that has a legitimate authentication credential.
  3. Then, the tester triggers communication between network product and a test entity that doesn't have a legitimate authentication credential.
Expected results:
  • Mutual authentication is successful and communication between network product and the entity with correct credentials can be established.
  • Mutual authentication fails and communication between the network product and the entity with incorrect credentials cannot be established.
Expected format of evidence:
Test result pass/fail recorded by tester.
Up
4.2.3.4.5  Policy regarding consecutive failed login attempts  p. 40
Requirement Name:
tba
Requirement Description:
a) The maximum permissible number of consecutive failed user account login attempts should be configurable by the operator. The definition of the default value set at manufacturing time for maximum number of failed user account login attempts shall be less than or equal to 8, typically 5. After the maximum permissible number of consecutive failed user account login attempts is exceeded by a user there shall be a block delay in allowing the user to attempt login again. This block delay and also the capability to set period of the block delay, e.g. double the delay, or 5 minutes delay, or 10 minutes delay, after each login failure should be configurable by the operator. The default value set at manufacturing time for this delay shall be greater than or equal to 5 sec.
b) If supported, infinite (permanent) locking of an account that has exceeded maximum permissible number of consecutive failed user account login attempts should also be possible via configuration, with the exception of administrative accounts which shall get only temporarily locked.
Security Objective references:
tba.
TEST CASE:
Test Name:
TC_FAILED_LOGIN_ATTEMPTS
Purpose:
To ensure that the policy regarding failed login attempts is adhered to.
Case 1: Testing for requirement 4.2.3.4.5 a)
Procedure and execution steps:
Pre-Conditions:
  1. At least one user account has been created as per manufacturer's instructions.
  2. Directions of how to configure the maximum permissible number of consecutive failed user account login attempts and the default value of this number are identified in the documentation accompanying the Network Product. Default value shall be stated as well.
  3. Directions of how to configure the block delay in allowing a user attempt to login again when the number of failed login attempts has exceeded the maximum number are identified in the documentation accompanying the Network Product. Default value of the delay shall be stated as well.
Execution Steps:
The accredited evaluator's test lab is required to execute the following steps:
  1. Check default values from precondition 2 and 3.
  2. Perform consecutive failed login attempts for the user account until the default maximum number of precondition 2 is reached.
  3. Attempt again one extra login, which fails again.
  4. Attempt one extra login in less time than the default for the delay of precondition 3, using the correct credentials.
  5. Attempt one extra login in more time than the default for the delay of precondition 3, using the correct credentials.
Expected Results:
  1. Default values from precondition 2 and 3 are in accordance with the requirement.
  2. In execution step 4, the login attempt shall be rejected in all cases.
  3. In execution step 5, the login attempt shall be accepted.
  4. In execution step 6, it is verified that the user can login only at the last login attempt.
Expected format of evidence:
tba
Case 2: Testing for requirement 4.2.3.4.5 b)
Procedure and execution steps:
Pre-Conditions:
  1. At least one user account has been created as per manufacturer's instructions.
  2. Directions of how to configure the maximum permissible number of consecutive failed user account login attempts and the default value of this number are identified in the documentation accompanying the Network Product. Default value shall be stated as well.
  3. Directions of how to optionally configure permanent locking for non-administrative accounts shall be stated as well.
Execution Steps:
The accredited evaluator's test lab is required to execute the following steps:
1)
Check default values from precondition 2.
2)
Perform consecutive failed login attempts for the user account until the default maximum number of precondition 2 is reached.
3)
Attempt again one extra login, which fails again.
4)
Attempt one extra login in more time than the default for the delay of precondition 3, using the correct credentials.
5a)
If supported enable permanent locking of accounts exceeding the maximum permissible number of consecutive failed user account login attempts and repeat steps 1-4 for a normal user.
5b)
If supported enable permanent locking of accounts exceeding the maximum permissible number of consecutive failed user account login attempts and repeat steps 1-4 for a user with administrative access rights.
Expected Results:
In execution step 5a it is verified that the user cannot login at any execution step.
In execution step 5b it is verified that an administrator user can successfully login only at execution step 5b.
Expected format of evidence:
tba
Up
4.2.3.4.6  Authorization and access control  p. 41
4.2.3.4.6.1  Authorization policy   p. 41
Requirement Name:
tba
Requirement Description:
The authorizations for accounts and applications shall be reduced to the minimum required for the tasks they have to perform.
Authorizations to a system shall be restricted to a level in which a user can only access data and use functions that he needs in the course of his work. Suitable authorizations shall also be assigned for access to files that are components of the operating system or of applications or that are generated by the same (e.g. configuration and logging files).
Alongside access to data, execution of applications and components shall also take place with rights that are as low as possible. Applications should not be executed with administrator or system rights.
Security Objective references:
tba.
Test case:
verify authorization policy is in place and that user access and data access in the system are according to the authorization policy.
Procedure and execution steps:
Pre-Conditions:
Documentation describing the authorization policy defined for the system including details on the lowest access rights assigned to user accounts, access to data, application execution and components.
Execution Steps:
  1. Assign access rights (e.g. read only) to user accounts, data files, and applications.
  2. Operations, that are allowed as per authorization policy (as defined in the network product documentation), are attempted via the different user accounts, data files, and applications.
Expected Results:
  1. User accounts, data files, and applications are allowed to be accessed (e.g. able to read but not write to a file, able to execute an application as a user account without administrator rights, etc.) according to the access rights assigned.
  2. User accounts, data files, and applications are not allowed to be accessed above the access rights assigned (e.g. able to write to a read only file, able to execute an application as an administrator, etc.).
Expected format of evidence:
Pass/fail results as recorded by the tester.
Up
4.2.3.4.6.2  Role-based access control   p. 42
Requirement Name:
tba
Requirement Description:
The network product shall support Role Based Access Control (RBAC). A role-based access control system uses a set of controls which determines how users interact with domains and resources. The domains could be Fault Management (FM), Performance Management (PM), System Admin, etc. The RBAC system controls how users or groups of users are allowed access to the various domains and what type of operation they can perform, i.e. the specific operation command or command group (e.g. View, Modify, Execute).
The network product supports RBAC, in particular, for OAM privilege management for network product Management and Maintenance, including authorization of the operation for configuration data and software via the network product console interface.
Security Objective references:
tba.
Test case:
Purpose:
Verify that users are granted access with role-based privileges.
Procedure and execution steps:
Pre-Conditions:
Documentation describing the role based access control system including details on which user roles are defined.
Execution Steps:
  1. User accounts which are assigned to different access roles are created.
  2. Operations, that are allowed by different roles (as defined in the network product documentation), are attempted via the different user accounts.
Expected Results:
  1. Users that are assigned to a role that is not allowed to execute an operation are prevented from executing the operation.
  2. Users that are assigned to a role that is allowed to execute an operation can successfully execute the operation.
Expected format of evidence:
Pass/fail results as recorded by the tester.
Up

Up   Top   ToC