Computer Science > Study Notes > Domain 6: Security Assessment and Testing Western Governors UniversityCISSP 101Notes - Domain 6 - ED (All)

Domain 6: Security Assessment and Testing Western Governors UniversityCISSP 101Notes - Domain 6 - EDT_JAN18

Document Content and Description Below

Domain 6: Security Assessment and Testing SLIDE 3: Domain Objectives • Plan for technology development, including risk • Evaluate the system design against mission requirements • Identify where competitive prototyping and other evaluation techniques fit in the process SLIDE 4: Domain Agenda • Design and Validate Assessment and Test Strategies • Conduct Security Control Testing • Collect Security Process Data • Conduct or Facilitate Internal and Third‐Party Audits Design and Validate Assessment and Test Strategies SLIDE 6: Module Topics • Introduction • Roles • Verification and Validation SLIDE 7: The Role of the Systems Engineer and Security ProfessionalD6 P2 v.01_2018 SLIDE 8: The Role of the Working Group • Updates to test and evaluation strategy • Ensure test and evaluation processes are consistent with the acquisition strategy • Ensure user's capability‐based operational requirements are being met by the system SLIDE 9: Verification Software verification ‐ provides objective evidence that the design produces / provides the results of a particular phase in respect to the software development life cycle. It will provide the assurance of compliance with the specified requirements for that phase. Software verification looks for consistency, completeness, and correctness of the software and its supporting documentation as it is being developed. It also supports a subsequent conclusion that the software is validated. Software testing is one of many types of verification activities. It is intended to confirm that software development output meets its input requirements. Other verification activities include: Static and Dynamic analyses, code and document inspections, and walkthroughs. SLIDE 10: Validation Validation is a matter of developing a “level of confidence” that the software or system meets all requirements and user expectations as documented. Identifies the following: defects found in specifications documents, amount of defects remaining, and testing coverage. This will be used to develop an acceptable level of confidence before deploying the product. The level of confidence, and therefore the level of software validation, verification, and testing effort required, will vary depending on the safety risk (hazard) posed by the system.

[Show More]

Last updated: 7 months ago

Preview 1 out of 54 pages

Buy Now

Instant download