Test 1-5

TEST 1

  • Test Case ID: BIS-2.3.1

  • Test Name: TC_TEST_SERVER_CONNECTION_SIGNATURE_VALIDATION_ENCRYPTION

Objective:

To identify the scenarios where the device establishes server connections with the external world and verify the security features implemented—such as strong cipher suites, secure TLS version, and SSL pinning—through source code walkthrough.

Tools Used:

  • Static Code Analysis Tool (e.g., SonarQube, Checkmarx, Fortify)

  • Manual Code Review

  • IDE/Text Editor (e.g., VSCode, Eclipse)

  • Reference to secure coding standards (e.g., OWASP, NIST)

Test Execution Steps:

  1. Review connection modules in the source code responsible for outbound communication to external servers.

  2. Identify security configurations related to TLS version, cipher suite selection, and certificate validation.

  3. Validate the implementation of SSL/TLS pinning, ensuring that the device is configured to only trust specific certificates or public keys.

  4. Assess exception handling and fallback mechanisms in case the certificate is invalid or missing.

  5. Document all findings from both automated tools and manual inspection.

Expected Results for Pass:

  • Source code reflects secure TLS configurations (TLS 1.2 or above).

  • Only strong cipher suites (e.g., AES-GCM, ECDHE) are allowed.

  • SSL/TLS pinning is implemented correctly to mitigate MITM attacks.

  • No weak or deprecated configurations (e.g., TLS 1.0, RC4) are present.

Test Observations:

(To be filled during actual testing – e.g., “Code uses TLS 1.2 with ECDHE-RSA and AES256-GCM; SSL pinning implemented via hardcoded certificate hash.”)

Evidence Provided:

  • Screenshot/snippet of code implementing TLS configurations

  • Static analysis report excerpt confirming absence of insecure protocols/ciphers

  • SSL pinning logic (e.g., certificate hash validation)

Test Case Result:

(PASS / FAIL – based on actual outcome)

TEST 2

  • Test Case ID: BIS-2.3.2

  • Test Name: TC_TEST_SERVER_CONNECTION_SIGNATURE_VALIDATION_ID

Objective:

To identify the scenarios when the device establishes server connections with the external world and verify that proper certificate validation, certificate chain validation, and certificate revocation checks are implemented in the device.

Tools Used:

  • Custom test TLS servers (configured with valid/invalid/expired/self-signed certs)

  • OpenSSL or TestSSL.sh

  • Wireshark or tcpdump (for monitoring TLS handshake behavior)

  • DUT logging interface / debug console

Test Execution Steps:

  1. Set up test servers with:

    • A valid certificate

    • An expired certificate

    • A self-signed/untrusted certificate

    • A certificate with an invalid chain

    • A certificate revoked in CRL/OCSP

  2. Configure DUT to initiate outbound connections to each of these test servers.

  3. Monitor the device’s behavior during each handshake attempt, including:

    • Whether the connection was established or rejected

    • Whether certificate chain validation occurred

    • Whether revocation checking was performed (CRL/OCSP)

  4. Record system logs and handshake traces for analysis.

Expected Results for Pass:

  • The device successfully establishes a connection only with servers presenting valid, trusted certificates.

  • Connections with expired, self-signed, or revoked certificates are rejected.

  • Certificate chain validation and revocation checks are confirmed through logs or error responses.

Test Observations:

(To be filled during execution – e.g., “DUT rejected expired and self-signed certificates, accepted valid chain with CRL verified.”)

Evidence Provided:

  • Server cert details used for testing

  • DUT logs showing TLS handshake and rejection messages

  • Wireshark capture of handshake process

  • Screenshots or debug output of failed and successful validation

Test Case Result:

(PASS / FAIL – based on actual behavior during test)

TEST 3

  • Test Case ID: BIS-2.3.3

  • Test Name: TC_TEST_SERVER_CONNECTION_SIGNATURE_VALIDATION_VULNE

Objective:

To test the device's TLS implementation for vulnerabilities that could compromise secure server communications, such as padding oracle attacks or the use of weak cipher suites.

Tools Used:

  • testssl.sh

  • SSLyze

  • tls-scan

  • Nessus or equivalent TLS vulnerability scanners

Test Execution Steps:

  1. Run TLS vulnerability scanning tools (e.g., testssl.sh, SSLyze) against the DUT.

  2. Identify supported cipher suites and TLS versions used by the device.

  3. Check for the following vulnerabilities:

    • Use of deprecated TLS versions (e.g., TLS 1.0/1.1)

    • Use of weak ciphers (e.g., RC4, 3DES)

    • Padding oracle or other known cryptographic attacks

    • Missing forward secrecy

  4. Document the findings from the scans and assess whether any misconfigurations or weaknesses exist.

Expected Results for Pass:

  • The DUT only supports TLS 1.2 or higher, with strong cipher suites (e.g., AES-GCM, ECDHE).

  • No known vulnerabilities are identified.

  • TLS settings follow current best practices for secure communication.

Test Observations:

(To be filled during test – e.g., “TLS 1.3 and TLS 1.2 supported; weak ciphers not present; padding oracle test: negative”)

Evidence Provided:

  • TLS scan reports (from tools listed above)

  • Screenshots or logs from scan results

  • Configuration summary or extracted cipher list from DUT

Test Case Result:

(PASS / FAIL – based on findings)

Here is the completed and formatted documentation for TEST 4: BIS-2.3.4:

TEST 4

  • Test Case ID: BIS-2.3.4

  • Test Name: TC_TEST_SERVER_CONNECTION_SIGNATURE_VALIDATION_NMAP

Objective:

To use Nmap to identify open ports on the device that could potentially expose it to unauthorized access or unintended data retrieval, and ensure only documented and secure ports are active.

Tools Used:

  • Nmap (Network Mapper)

Test Execution Steps:

  1. Review documentation from the vendor to obtain a list of expected standard and non-standard ports used by the device.

  2. Perform a comprehensive Nmap port scan of the device’s IP address:

    • Command example:

      nmap -sS -sV -p- <device-ip>

  3. Analyze scan results to determine:

    • Services running on each open port.

    • Whether each open port is expected and justified.

  4. Document any ports or services:

    • Not listed in the vendor documentation.

    • Running unprotected or unintended services.

Expected Results for Pass:

  • The Nmap scan output shows only expected ports as per the OEM documentation.

  • All exposed services are intended, secure, and properly configured.

  • No unexpected or undocumented open ports or services were found.

Test Observations:

(To be filled during testing – e.g., “Ports 22, 443, 8080 found as expected; no unexpected ports; all services verified as secured.”)

Evidence Provided:

  • Nmap scan output logs (plain text or screenshots)

  • Mapping of scanned ports vs. documented ports

  • Service version detection output (from -sV)

Test Case Result:

(PASS / FAIL – based on whether all open ports align with expected configuration)

TEST 5

  • Test Case ID: BIS-2.3.5

  • Test Name: TC_TEST_SERVER_CONNECTION_SIGNATURE_VALIDATION_TLS

Objective:

To verify that the TLS sessions established by the device are resistant to man-in-the-middle (MITM) attacks, ensuring the integrity and confidentiality of data in transit.

Tools Used:

  • Burp Suite (configured as an intercepting proxy)

  • Ettercap (for ARP spoofing/MITM testing)

Test Execution Steps:

  1. Configure Burp Suite or Ettercap to act as an intercepting proxy between the DUT and the intended test server.

  2. Attempt to perform a MITM attack by:

    • Intercepting TLS traffic.

    • Presenting a forged certificate.

    • Attempting to decrypt or modify the traffic.

  3. Observe whether the DUT:

    • Rejects the invalid certificate.

    • Terminates the connection.

    • Provides any logs or alerts related to the tampering attempt.

  4. Document the behavior of the DUT during the attack attempt.

Expected Results for Pass:

  • The device must reject connections when presented with a forged or tampered TLS certificate.

  • TLS session must remain encrypted and resist interception/decryption.

  • No sensitive information should be exposed or altered during transit.

Test Observations:

(To be filled during testing — e.g., “Device terminated session on forged cert. No data intercepted via Burp.”)

Evidence Provided:

  • Screenshots or logs from Burp Suite/Ettercap

  • Network capture (e.g., from Wireshark)

  • DUT logs showing certificate validation failures or session rejections

Test Case Result:

(PASS / FAIL depending on test outcome)

Overall Test Result:

(PASS / FAIL — based on cumulative result of all five sub-tests from BIS-2.3)

Previous2.3 Test Server Connection Signature ValidationNext2.4 – Check for Safe Alternatives to Banned C Functions

Last updated

Was this helpful?