Security and Reliability Testing
Security and Reliability Testing
This domain combines two non-functional areas that are frequently confused in questions. Security testing asks whether assets are protected against malicious action; reliability testing asks whether the software keeps working over time. Both demand precise metrics.
Security fundamentals
- The CIA triad: confidentiality (only authorised parties read data), integrity (data is not altered undetectably), availability (service is reachable when needed). Related properties are authenticity and non-repudiation.
- Security testing types: vulnerability scanning, penetration testing, security audit, risk assessment, and configuration or hardening review.
- Penetration test phases: reconnaissance, scanning and enumeration, exploitation, post-exploitation and privilege escalation, reporting and remediation advice.
- Common vulnerability classes to recognise: injection (SQL, command), cross-site scripting, cross-site request forgery, broken authentication and session management, insecure direct object references, missing function-level access control, security misconfiguration, sensitive data exposure, use of weak cryptography, buffer overflow.
- Techniques: input tampering with boundary and malformed data, privilege escalation attempts, session hijacking and replay, fuzzing, and both static analysis (SAST, on source) and dynamic analysis (DAST, on the running system).
Reliability fundamentals
Reliability is the probability of failure-free operation for a specified period in a specified environment. Key measures: MTTF (mean time to failure), MTTR (mean time to repair), MTBF = MTTF + MTTR, and availability A = MTTF / (MTTF + MTTR) = MTTF / MTBF. The bathtub curve has infant mortality, useful life and wear-out phases; software does not wear out physically, but each modification re-creates an infant-mortality phase, which is why regression testing follows every change. Reliability growth models (Jelinski-Moranda, Musa, Goel-Okumoto) model failure intensity decreasing as defects are removed.
Worked example
A system runs 990 hours before failure on average and takes 10 hours to repair. MTBF = 990 + 10 = 1,000 hours; availability = 990 / 1,000 = 99%. If the requirement is 99.9%, improving MTTR to 1 hour gives 990 / 991 ≈ 99.9% - repairing faster may be cheaper than making the software ten times more reliable. Showing that trade-off is what distinguishes a full-mark answer.
Traps
Using MTBF as the numerator of availability instead of MTTF; treating reliability as identical to availability (a system can be highly available yet fail often if recovery is fast); assuming security testing is functional testing with odd inputs; thinking a vulnerability scan replaces a penetration test.
Key ideas
Security defects are design defects as much as coding defects, and reliability claims must be backed by measured failure data, not by defect counts alone.