Deep Dive into the Five Core Security Attributes for Robust Testing

Five Core Security Attributes – In‑Depth Analysis

Confidentiality : Prevent unauthorized disclosure of sensitive data. Test goal is to keep data protected during transmission, storage and processing. Key techniques include penetration testing (vulnerability and port scanning), encryption algorithm verification (AES, RSA, SM2), access‑control testing (RBAC, ABAC) and information‑leakage detection.

Integrity : Prevent unauthorized modification or destruction of data. Test goal is to ensure data remains accurate throughout its lifecycle. Key techniques cover input‑validation testing (SQL injection, XSS, CSRF), business‑logic vulnerability testing, hash and digital‑signature verification, and file‑integrity monitoring.

Non‑repudiation : Ensure operators cannot deny performed actions, providing legal and technical evidence. Test goal is to supply evidential support for critical operations. Techniques include digital‑signature verification, timestamp service testing, audit‑log integrity checks and electronic forensics.

Auditability : Record all security‑related events for investigation and compliance. Test goal is to provide sufficient information for security‑event investigation and audit. Techniques involve audit‑log integrity testing, log‑protection mechanisms, security‑event correlation analysis and compliance audit verification (GDPR, Cybersecurity Law).

Authenticity : Verify the true identity of users, systems and data to prevent impersonation attacks. Test goal is to prevent identity forgery and deception. Techniques include authentication mechanism testing, session‑management security testing, multi‑factor authentication strength verification, and anti‑phishing/social‑engineering testing.

Attribute Relationship Model

Authenticity → Confidentiality → Integrity forms the core protection chain, while Auditability ↔ Non‑repudiation provides evidential and traceability support. The logical flow emphasizes that identity verification underpins access control, which together protect data integrity and confidentiality, and finally enable reliable audit trails.

Comprehensive Case Study: SecureBank Online Transfer System

System background

System name: SecureBank Online Transfer System

Business scenario: Large‑value corporate fund transfers (max ¥5 million per transaction, ¥2 billion daily)

Compliance requirements: Cybersecurity Law, payment‑settlement regulations, ISO 27001

Phase 1 – Authenticity Testing

Scenario: Identity verification during login and transaction authorization.

Test case TC‑AUTH‑01: Weak password "123456" login attempt – resulted in successful login.

Test case TC‑AUTH‑02: Brute‑force 4‑digit SMS code (0000‑9999).

Test case TC‑AUTH‑03: Session fixation attack.

Test case TC‑AUTH‑04: Use of expired session token to access sensitive functions.

Findings:

SMS code validity period was 10 minutes – high risk of brute‑force.

No limit on verification attempts.

Session timeout set to 24 hours.

Remediation: Reduce SMS code validity to 3 minutes. Lock account after 5 failed attempts for 30 minutes. Force re‑authentication for sensitive operations. Shorten session timeout to 15 minutes of inactivity. Phase 2 – Confidentiality Testing Scenario: Data protection during the transfer process. TC‑CONF‑01: Man‑in‑the‑middle attack using Burp Suite to intercept HTTPS traffic. TC‑CONF‑02: Encryption‑algorithm strength verification (SSL/TLS configuration). TC‑CONF‑03: Sensitive‑information leakage via source code and error messages. TC‑CONF‑04: Database security – backup files and data‑masking checks. Findings: Some legacy APIs still support TLS 1.0 (medium risk of MITM). Error messages exposed database table names. Debug mode left enabled in production. Remediation: Upgrade all endpoints to TLS 1.2+ and disable weak cipher suites. Standardise error responses to hide technical details. Turn off debug mode in production environments. Apply data‑masking (show only last 4 digits of bank cards). Phase 3 – Integrity Testing Scenario: Protection against transaction tampering. TC‑INTEG‑01: Modify transfer amount (¥1 000 → ¥10 000). TC‑INTEG‑02: Replay a successful transfer request. TC‑INTEG‑03: Unauthorized operation – modify another user’s transfer record. TC‑INTEG‑04: SQL injection using "' OR '1'='1" in account name. Findings: Transfer requests lacked tamper‑proof signatures. Replay protection was insufficient. Horizontal privilege escalation existed. Remediation: Add digital signatures to all transaction parameters. Introduce unique transaction IDs with expiration. Enforce strict permission checks for every operation. Validate and filter input parameters rigorously. Phase 4 – Non‑repudiation Testing Scenario: Evidence preservation for transfer operations. TC‑NONREP‑01: Signature forgery by modifying signature value. TC‑NONREP‑02: Timestamp tampering. TC‑NONREP‑03: Attempt to delete operation logs. TC‑NONREP‑04: Verify end‑to‑end evidence chain (operation → log → signature). Technical requirements: Use SM2 digital certificates compliant with the Electronic Signature Law. Generate an independent signature for each critical operation, including operation content, timestamp and operator identity. Store logs on WORM devices and conduct regular digital‑forensics drills. Phase 5 – Auditability Testing Scenario: Full‑process security event recording. TC‑AUDIT‑01: Simulate attacks and verify log integrity. TC‑AUDIT‑02: Test log deletion and modification permissions. TC‑AUDIT‑03: Trigger abnormal behaviour and check alert timeliness. TC‑AUDIT‑04: Generate compliance audit report. Implementation requirements: Centralised log storage with strict access control. Use blockchain‑based immutability for log protection. Real‑time monitoring and automatic alerting (99.9%+ alert timeliness). Retain logs for at least five years to meet financial‑regulation mandates. Test Results Summary Authenticity : SMS code brute‑force vulnerability – high risk – could lead to account takeover. Remediation: limit attempts, upgrade to 6‑digit codes. Confidentiality : Out‑dated TLS configuration – medium risk – susceptible to MITM. Remediation: upgrade TLS version, disable weak cipher suites. Integrity : Transaction parameters modifiable – high risk – potential fund loss. Remediation: add digital signatures, strengthen input validation. Non‑repudiation : Logs deletable by admin – medium risk – evidence loss. Remediation: implement log protection, store hashes on blockchain. Auditability : Some operations not logged – low risk – audit blind spots. Remediation: complete audit strategy to record all actions. Best‑Practice Summary Layered Defense Strategy Network perimeter: firewalls, WAF, DDoS protection. Application layer: input validation, session management, error handling. Data layer: encryption, masking, strict access control. Audit layer: comprehensive logging, real‑time alerts, behavior analysis. Continuous Security Testing Framework Development phase: SAST + secure coding guidelines. Testing phase: DAST + penetration testing. Deployment phase: RASP. Operations phase: Continuous monitoring, red‑blue exercises. Security Test Automation Daily scans: vulnerability and configuration checks. Per‑build: SAST and dependency security analysis. Per‑deployment: baseline verification and core penetration cases. Real‑time monitoring: anomaly detection and attack‑pattern matching. People and Process Assurance Security architects design secure architectures. Security engineers execute testing. Security operations handle monitoring and incident response. Compliance experts ensure regulatory adherence. Process flow: security requirement review → design review → code review → test execution → incident response. Conclusion Security testing is not a one‑off activity but a continuous process throughout the software lifecycle. By systematically testing confidentiality, integrity, non‑repudiation, auditability and authenticity, organizations can build a comprehensive defense that safeguards business operations. In the AI era, mastering the known unknowns is no longer difficult; the key is how to discover the unknown unknowns—often hidden within the process of exploring the unknowns of the known.