BS ISO IEC 27041:2015 pdf free download – lnformation technology – Security techniques – Guidance on assuringsuitability and adequacy ofincident investigative method
5.5.1 General principles of requirements
Prior to designing a process for use in an examination, a proper set of requirements should be produced,accepted by the client and recorded in accordance with good practice.This set of requirements should bederived from the requirements identified for the complete investigation and may include both functionaland non-functional requirements.
Each requirement defines an essential capability, characteristic or quality factor. Each individualrequirement statement should be necessary, implementation-free (i.e. it states only what is required,not how the requirement should be met),unambiguous,complete, singular and consistent with theremainder of the requirements in the set.
Requirements vary in intent and in the kinds of properties they represent. They can be grouped togetherinto similar types to aid in analysis and verification.Examples of types of requirements include:
– Functional – describe the functions or tasks to be performed and will include such considerationsas expected inputs and outputs;
– Performance – defines the extent, how well, and under what conditions a function or task is to beperformed;
– Interface – defines how the solution interacts with external systems, or how elements within thesolution (including human elements) interact with each other;
– Process – include compliance with local laws and processes or administrative requirements;
– Non-functional – define how a solution is supposed to be, including quality requirements such asportability,reliability, maintainability and security, or human factors requirements such as safety,efficiency or health and wellbeing.
In addition to all essential requirements, the lists of requirements produced should also include cleardefinitions of the boundaries of operation associated with the anticipated potential digital evidenceand related investigative processes (e.g.maximum file sizes, maximum and minimum number of inputvalues).
A new list of requirements may need to be formulated for each investigation undertaken to ensure theexamination correctly fulfils the specific case requirements. Using a monolithic approach to the designwould require a significant validation overhead and so the user should where practically possible selectpredefined atomic stages which are compatible with dynamic user definable input parameters.
In that way the unique changes to the requirements will typically be limited to the specific caseinput parameters, and so the case specific validation would predominantly be limited to the specificparameters supplied to the case under investigation, and not the underlying function or process whichshould have been designed at the readiness phase.
EXAMPLE While specific keyword searches will be directly dependent on the case being investigated thekeyword filter process should, if designed correctly, be an atomic process which is independent of the keywordsused.The area which requires unique case specificvalidation be the definition of the correctness of the keyword[s]applied (i.e.the undefined uncertainty error will be in the user’s design of the specific search terms used, forinstance only searching for “Joe Blogs” would miss references to “”fJoe Bioggs” “Mr Blogs”,” .Blogs” “oe”, “foey”,etc.).
The incident under investigation should be clearly identified and defined, including limitations to thescope of the investigation.Sources of potential digital evidence and questions to be answered should beidentified.Sources of risk and their potential effects on the investigation, personnel and systems shouldalso be identified.