Security testing: Difference between revisions

Revision as of 13:23, 23 June 2020

Revision as of 22:05, 31 October 2020

Line 3:

{{Information security}}

'''Security testing''' is a process intended to reveal flaws in the [[security]] mechanisms of an [[information system]] that protectprotects data and maintain functionality as intended.<ref>M Martellini, & Malizia, A. (2017). Cyber and chemical, biological, radiological, nuclear, explosives challenges : threats and counter efforts. Springer.</ref> Due to the logical limitations of security testing, passing the security testing process is not an indication that no flaws exist or that the system adequately satisfies the security requirements.

Typical security requirements may include specific elements of [[confidentiality]], [[integrity]], [[authentication]], availability, authorization and [[non-repudiation]].<ref>"Introduction to Information Security" US-CERT https://www.us-cert.gov/security-publications/introduction-information-security</ref> Actual security requirements tested depend on the security requirements implemented by the system. Security testing as a term has a number of different meanings and can be completed in a number of different ways. As such, a Security Taxonomy helps us to understand these different approaches and meanings by providing a base level to work from.

== Confidentiality ==

Line 21:

== Authentication ==

This might involve confirming the identity of a person, tracing the origins of an artifact, ensuring that a product is what its packaging and labeling claims to be, or assuring that a [[computer program]] is a trusted one.

== Authorization ==

Line 41:

Common terms used for the delivery of security testing:

* '''Discovery''' - The purpose of this stage is to identify systems within scope and the services in use. It is not intended to discover vulnerabilities, but version detection may highlight deprecated versions of [[software]] / firmware and thus indicate potential vulnerabilities.

* '''Vulnerability Scan''' - Following the discovery stage this looks for known security issues by using automated tools to match conditions with known vulnerabilities. The reported risk level is set automatically by the tool with no manual verification or interpretation by the test vendor. This can be supplemented with credential based scanning that looks to remove some common [[False positives and false negatives|false positives]] by using supplied credentials to authenticate with a service (such as local windows accounts).

* '''Vulnerability Assessment''' - This uses discovery and vulnerability scanning to identify security vulnerabilities and places the findings into the context of the environment under test. An example would be removing common false positives from the report and deciding risk levels that should be applied to each report finding to improve business understanding and context.