Calculating risk POST assesment?

Viewing 4 reply threads
  • Author
    • #4795

      This applies to both Network pen testing and web application assessments.

      I was wondering if there had been any work done on calculating risk POST web app assessment or network pen testing?

      There are a number of risks I can think of POST assessment:

      0day vulnerabilities
      Missed bugs due to time constraints
      The skill/experience of the tester/s
      Missed bugs due to tool/s not functioning as expected

      Any help with this is much appreciated.

      Thank you.

    • #30073

      I’m not sure if I’ve seen a study or data, specific to this.  But you’re absolutely correct, with regards to the possibilities you could run into, POST assessment.

      Tester’s skill level, 0day’s, time constraints, and even machines left out (intentionally or unintentionally) from the scope of the test are ALL items which could spring up.  Additionally, new services / servers / apps (web or not) are stood up at clients all the time, and folks make changes to their local machine configurations, etc.

      While there’s never going to be perfection in a penetration test, the key is finding and validating as much as possible, reliably, in the time permitted, and within the scope and accepted procedures to which you’ve agreed. 

      If you find measured data from a reliable source, please feel free to post it here.  It’s always interesting to see what others have to say, in this regard.

    • #30074

      This is not really my area, but I think that this is a very business specific exercise.  I would approach this as a business impact exercise and assign some sort of qualitative numbering system to each one of those and the systems they affect.  I don’t know if it is possible to quantify something like this, and assign a dollar amount for example.  I think that it is a manual effort, perhaps with the aide of some risk assessment software.  I also think that you would have to get more specific than just “0day attacks.”  For example, a 0day DDOS attack can have a different impact on an application and revenue loss than an 0day XSS attack. 

    • #30075

      The unreleased OSSTMM v3.0 has a section (2.8 Error Handling) which gives information on calculating Auditor error. The acronym they use is TERM (Test Error Risk Margin). This calculation is carried out by the Auditor himself which of course is a biased view however if this is stated, TERM is still useful.

      This still leaves:

      Future changes to the tested environment
      Possibly more?

    • #30076

      Are you limiting this just to hacking-related attacks, or are you more interested in assess risk for all your information systems? A comprehensive risk assessment includes much more than what you mentioned. Even if you are just concerned with web apps/web servers, there is much more to consider. There are issues with availability, environment, employees (intentional/accidental damage), change management, etc. If you’re interested, NIST Special Publication 800-30 is an excellent guide if that’s what you’re looking for:

      I like this book as well:

      You will ideally perform an RA at least annually. We work primarily with financial institutions, which are required to do so. I would assume only a small percentage of other businesses actually adhere to that recommendation.

Viewing 4 reply threads
  • You must be logged in to reply to this topic.

Copyright ©2021 Caendra, Inc.

Contact Us

Thoughts, suggestions, issues? Send us an email, and we'll get back to you.


Sign in with Caendra

Forgot password?Sign up

Forgot your details?