selvalives Aug 25th, 2019 98 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. 1.importance of sec requirement gathering
  2.     -since it is non functional, it is often overlooked
  3.     -stakeholders often overlook also
  4.     -negligence may cause severe impact
  5.     -eliciting sec requirement needs different approach
  6.         -because functional requirements are the positive requirements where else
  7.         sec requirements are negative requirements 
  8.         -means what can go wrong with the application instead of what can the system do
  9.     -should enumerated separate from functional requirement
  10.     -it is against the natural tendency of what people want, because we need to
  11.     listdown what we don't want
  12.     -mixing with functional requirement will make security requirement gathering complicated
  13.     -idenfity the stake holders-user,customer, business sponsor, developers,requirement engineer,
  14.     security expert, project managers
  15.     -follow SMART for good security requirement-Specific,Measurable,Actionable,Realistic,Timely
  16.         -clear and precise wordings for requirements
  17.         -there should be clear way to test the security requirements
  18.         -developers should clearly know what to be developed to satisfy the requirements
  19.         -should be implementable in realtime, practically possible
  21. 2.understand SREengineering and its phases
  23.     types
  24.         1.functional sec requirements-input validations,authentications, strong password policy
  25. drivers-HIPPA,SOX
  26.     phases
  27.         -requirement elicitation is the initial activity of SREngineering-ask for what has to be done !
  28.             -analyze, find the stake holders, security expectation for various functioning of the system,
  29.             -use different approach like brainstorming, white boarding, interviews, workshops,questionnaires
  30.         -requirement analysis based on the elicitation done earlier-check the what has to be done with how can it be done !
  31.             -check for conflicts  and ambiquity
  32.             -check for completenes and clarity
  33.             -check if the requirements meets stakeholders expectation
  34.         -requirement specification
  35.             -finalize and put in on paper
  36.             -critical part as the development will start and continue to be based on this
  37.         -security requirement management
  38.             -update security requirements
  39.             -provide support based on the approach selected-derived or dedicated
  41.         SRE Approaches
  43.         1.derived
  44.                 -abuse cases
  45.                 -security use cases
  46.                 -abuse stories
  47.         2. dedicated
  48.                 -SQUARE
  49.                 -OCTAVE
  50.         -common mistakes
  51.             -requirement engineer will not be able to idenfity all security requirements
  52.             due to lack of modern elicitation knowledge
  53.             -requirements are directly specified without analyzing
  54.             -not SMART-refer to what is SMART
  55.             -requirements are not prioritized
  57. 3.abuse cases and its modeling
  58.     -abuse cases
  59.         -derived from use cases
  60.         -captures abnormal behaviours
  61.         -depicts the intentions of intrude,hack and compromise
  62.         -so that stakeholders can differentiate the appropriate and
  63.         inappropriate uses of system
  64.     -threatens relationship
  65.         -describes abuse case scenario
  66.         -describes how attacker can abuse the system
  67.     -advantages
  68.             -easy to learn n use
  69.             -can contribute a lot during requirement gathering process
  70.         -disadvantages
  71.             -can only be used in object oriented systems
  73. use cases and its modeling
  74.     -analyze the abuse case for mitigation
  75.         -usecase ->(includes) security use case ->(mitigate) abuse case
  76.         -security use cases are driven from abuse cases
  77.     -refer slide for examples
  78. 5.abuser n security stories(apart from use case)
  79.     -refer slide for examples
  80. 6.SQUARE
  81.     -elicitate,categorize and pritorize security requirements
  82.     -focus is similar to derived ,
  83.         to build security concept on the early stages of the development
  84. 7.OCTAVE
  85.     -based on risk evaluation
  86.     -provides structured approach to identify ,priotize and manage security risk
  87.     -based on three phases
  88.         -identify asset based threatens
  89.         -evaluate and identify the vulnerabilities
  90.         -draft the plans
RAW Paste Data
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy. OK, I Understand