2017년 3월 9일 목요일

원전 사이버보안 위험 관리 단계


출처:  Formal Works Inc.

Avoiding Top Mistakes in Safety Critical Software Development

Mistake #1: Forgetting to Conduct Requirements Reviews Often
"Review Requirements Early and Often – Make use of Lean and Agile"

  • Conduct more frequent iterative reviews
  • Review requirements in smaller batches
  • Increase quality by having more thorough reviews & defined criteria
  • Use collaborative techniques during review



Mistake #2:  Forgetting to Use Safety-Critical Requirements Checklists
"Make use of checklists when performing requirements reviews"


Mistake #3 Not Reviewing Software Requirements in Context
"Review Requirements with their traces in context."


Mistake #4– Neglecting Traceability
"When creating new requirements, tests cases, or code:"
  • Establish the required traces immediately, not later when you need to demonstrate those traces to the auditor
  • Make traceability updates mandatory for review of Requirements, Code, & Tests 
  • Two-way traceability for:
    • Requirements to Code Functions
    • Code Functions to Tests
    • Requirements to Tests 


Mistake #5: Neglecting Transition Criteria 




Mistake #6– Forgetting the Safety-Critical Software Lifecycle


Mistake #7 – Safety “Before & During”: Neglecting to Apply Safety  Standards BEFORE Software Development then During!



Mistake #8 – Neglecting Independence

  • Independence refers to the Correctness process (reviews and verification) 
  • Required Independence increases as criticality  increases
  • Not providing required Independence necessitates development rework
  • If future criticality level changes and Independence lacking:  rework.
  • Recommendation:  even when Independence is not required, do it:  better review and insurance against future critical level increase



Mistake #9 – Inadequate Plans or not Following!

  • Plans that are not compliant to standards
  • Lack of checklists
    • E.g. Code reviews without requirements traceability to code
  • Plans are not complete prior to starting associated developments
  • Plans not QA approved
  • Plans too detailed, requiring extreme customization for each project



Mistake #10 - Lack of Automated Testing = Expen$ive Regression Test 

  • Testing is a “life-of-product” continual activity
  • Testing costs exceed development costs, over product lifetime
  • Guilty-until-proven innocent regression: retest everything unless you can ensure no side effects
  • Best regression test strategy?  Retest everything (only practical via automated testing)



Mistake #11: When to “Verify”?


Traditional Software Engineering Sequence:



Recommended “Best Practice” Software Engineering Sequence:




출처: www.afuzion.com

Safety-Critical Requirements

Safety Critical Definitions
  • Software Requirement: “Measurable software processing that is necessary.”
  • Safety-Critical Software Requirement: “A necessary aspect within a system whose anomalous behavior could negatively impact safety.” 


Safety-Critical Systems - Basic Facts

  • “Safety-critical” encompasses many domains: Industrial, Automotive, Aerospace, Nuclear, Medical, etc. 
  • Software size and complexity are rapidly increasing
  • Yesterday’s non-safety-critical is becoming tomorrow’s safety-critical due to IoT, integration/connectivity, etc. 
  • Requirements are  needed to guide development, identify hazard detection/mitigation, and assess implementation.


Safety-Critical Requirements –Background

  • Experts say majority of safety-critical failures stem from requirements. 
  • Safety-critical requirements include Safety aspects, but not exclusively: also address Functional, Performance, etc. 
  • Most safety-critical requirements specifications are incomplete: lack complete hazard prevention/mitigation. 
  • Need requirement identification, specification, verification, and management.

출처: www.afuzion.com