├── _build ├── html │ ├── _static │ │ ├── custom.css │ │ ├── down.png │ │ ├── file.png │ │ ├── plus.png │ │ ├── up.png │ │ ├── minus.png │ │ ├── comment.png │ │ ├── ajax-loader.gif │ │ ├── up-pressed.png │ │ ├── comment-bright.png │ │ ├── comment-close.png │ │ ├── down-pressed.png │ │ ├── fonts │ │ │ ├── Lato-Bold.ttf │ │ │ ├── Lato-Regular.ttf │ │ │ ├── RobotoSlab-Bold.ttf │ │ │ ├── Inconsolata-Bold.ttf │ │ │ ├── RobotoSlab-Regular.ttf │ │ │ ├── Inconsolata-Regular.ttf │ │ │ ├── fontawesome-webfont.eot │ │ │ ├── fontawesome-webfont.ttf │ │ │ └── fontawesome-webfont.woff │ │ ├── css │ │ │ └── badge_only.css │ │ ├── js │ │ │ ├── theme.js │ │ │ └── modernizr.min.js │ │ ├── pygments.css │ │ ├── doctools.js │ │ └── alabaster.css │ ├── objects.inv │ ├── .buildinfo │ ├── _sources │ │ ├── tree.txt │ │ ├── media.txt │ │ ├── index.txt │ │ ├── faq.txt │ │ └── reporting.txt │ ├── genindex.html │ ├── search.html │ ├── media.html │ ├── index.html │ └── faq.html └── doctrees │ ├── faq.doctree │ ├── tree.doctree │ ├── index.doctree │ ├── media.doctree │ ├── reporting.doctree │ ├── environment.pickle │ ├── exploitation.doctree │ ├── pre_engagement.doctree │ ├── threat_modeling.doctree │ ├── post_exploitation.doctree │ ├── technical_guidelines.doctree │ ├── intelligence_gathering.doctree │ ├── vulnerability_analysis.doctree │ └── preengagement_interactions.doctree ├── tree.rst ├── README.md ├── source ├── Media ├── Main_Page ├── FAQ └── Reporting ├── media.rst ├── index.rst ├── faq.rst ├── Makefile ├── make.bat ├── conf.py └── reporting.rst /_build/html/_static/custom.css: -------------------------------------------------------------------------------- 1 | /* This file intentionally left blank. */ 2 | -------------------------------------------------------------------------------- /_build/html/objects.inv: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/html/objects.inv -------------------------------------------------------------------------------- /_build/doctrees/faq.doctree: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/doctrees/faq.doctree -------------------------------------------------------------------------------- /_build/doctrees/tree.doctree: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/doctrees/tree.doctree -------------------------------------------------------------------------------- /_build/html/_static/down.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/html/_static/down.png -------------------------------------------------------------------------------- /_build/html/_static/file.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/html/_static/file.png -------------------------------------------------------------------------------- /_build/html/_static/plus.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/html/_static/plus.png -------------------------------------------------------------------------------- /_build/html/_static/up.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/html/_static/up.png -------------------------------------------------------------------------------- /_build/doctrees/index.doctree: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/doctrees/index.doctree -------------------------------------------------------------------------------- /_build/doctrees/media.doctree: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/doctrees/media.doctree -------------------------------------------------------------------------------- /_build/html/_static/minus.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/html/_static/minus.png -------------------------------------------------------------------------------- /_build/doctrees/reporting.doctree: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/doctrees/reporting.doctree -------------------------------------------------------------------------------- /_build/html/_static/comment.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/html/_static/comment.png -------------------------------------------------------------------------------- /_build/doctrees/environment.pickle: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/doctrees/environment.pickle -------------------------------------------------------------------------------- /_build/html/_static/ajax-loader.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/html/_static/ajax-loader.gif -------------------------------------------------------------------------------- /_build/html/_static/up-pressed.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/html/_static/up-pressed.png -------------------------------------------------------------------------------- /_build/doctrees/exploitation.doctree: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/doctrees/exploitation.doctree -------------------------------------------------------------------------------- /_build/doctrees/pre_engagement.doctree: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/doctrees/pre_engagement.doctree -------------------------------------------------------------------------------- /_build/html/_static/comment-bright.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/html/_static/comment-bright.png -------------------------------------------------------------------------------- /_build/html/_static/comment-close.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/html/_static/comment-close.png -------------------------------------------------------------------------------- /_build/html/_static/down-pressed.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/html/_static/down-pressed.png -------------------------------------------------------------------------------- /_build/doctrees/threat_modeling.doctree: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/doctrees/threat_modeling.doctree -------------------------------------------------------------------------------- /_build/html/_static/fonts/Lato-Bold.ttf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/html/_static/fonts/Lato-Bold.ttf -------------------------------------------------------------------------------- /_build/doctrees/post_exploitation.doctree: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/doctrees/post_exploitation.doctree -------------------------------------------------------------------------------- /_build/html/_static/fonts/Lato-Regular.ttf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/html/_static/fonts/Lato-Regular.ttf -------------------------------------------------------------------------------- /_build/doctrees/technical_guidelines.doctree: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/doctrees/technical_guidelines.doctree -------------------------------------------------------------------------------- /_build/html/_static/fonts/RobotoSlab-Bold.ttf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/html/_static/fonts/RobotoSlab-Bold.ttf -------------------------------------------------------------------------------- /_build/doctrees/intelligence_gathering.doctree: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/doctrees/intelligence_gathering.doctree -------------------------------------------------------------------------------- /_build/doctrees/vulnerability_analysis.doctree: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/doctrees/vulnerability_analysis.doctree -------------------------------------------------------------------------------- /_build/html/_static/fonts/Inconsolata-Bold.ttf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/html/_static/fonts/Inconsolata-Bold.ttf -------------------------------------------------------------------------------- /_build/html/_static/fonts/RobotoSlab-Regular.ttf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/html/_static/fonts/RobotoSlab-Regular.ttf -------------------------------------------------------------------------------- /_build/doctrees/preengagement_interactions.doctree: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/doctrees/preengagement_interactions.doctree -------------------------------------------------------------------------------- /_build/html/_static/fonts/Inconsolata-Regular.ttf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/html/_static/fonts/Inconsolata-Regular.ttf -------------------------------------------------------------------------------- /_build/html/_static/fonts/fontawesome-webfont.eot: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/html/_static/fonts/fontawesome-webfont.eot -------------------------------------------------------------------------------- /_build/html/_static/fonts/fontawesome-webfont.ttf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/html/_static/fonts/fontawesome-webfont.ttf -------------------------------------------------------------------------------- /_build/html/_static/fonts/fontawesome-webfont.woff: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pentest-standard/docs/HEAD/_build/html/_static/fonts/fontawesome-webfont.woff -------------------------------------------------------------------------------- /_build/html/.buildinfo: -------------------------------------------------------------------------------- 1 | # Sphinx build info version 1 2 | # This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done. 3 | config: 904a8d6f861d6a5042ed35264b227ec4 4 | tags: 645f666f9bcd5a90fca523b33c5a78b7 5 | -------------------------------------------------------------------------------- /_build/html/_sources/tree.txt: -------------------------------------------------------------------------------- 1 | .. The Penetration Testing Execution Standard documentation master file, created by 2 | sphinx-quickstart on Sun Oct 30 18:04:42 2016. 3 | You can adapt this file completely to your liking, but it should at least 4 | contain the root `toctree` directive. 5 | 6 | Welcome to PTES's documentation! 7 | ====================================================================== 8 | 9 | Contents: 10 | 11 | .. toctree:: 12 | :maxdepth: 2 13 | 14 | index 15 | preengagement_interactions 16 | intelligence_gathering 17 | threat_modeling 18 | vulnerability_analysis 19 | exploitation 20 | post_exploitation 21 | reporting 22 | faq 23 | media 24 | 25 | Indices and tables 26 | ================== 27 | 28 | * :ref:`genindex` 29 | * :ref:`modindex` 30 | * :ref:`search` 31 | 32 | -------------------------------------------------------------------------------- /tree.rst: -------------------------------------------------------------------------------- 1 | .. The Penetration Testing Execution Standard documentation master file, created by 2 | sphinx-quickstart on Sun Oct 30 18:04:42 2016. 3 | You can adapt this file completely to your liking, but it should at least 4 | contain the root `toctree` directive. 5 | 6 | Welcome to PTES's documentation! 7 | ====================================================================== 8 | 9 | Contents: 10 | 11 | .. toctree:: 12 | :maxdepth: 2 13 | 14 | index 15 | preengagement_interactions 16 | intelligence_gathering 17 | threat_modeling 18 | vulnerability_analysis 19 | exploitation 20 | post_exploitation 21 | reporting 22 | technical_guidelines 23 | faq 24 | media 25 | 26 | Indices and tables 27 | ================== 28 | 29 | * :ref:`genindex` 30 | * :ref:`modindex` 31 | * :ref:`search` 32 | 33 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # docs 2 | pentest-standard.org docs redesign 3 | 4 | ## Why? 5 | 6 | The [pentest-standard.org](http://pentest-standard.org) site is pretty great, but it's a little dated, and the way in which to make contributions is murky. This repo is an effort to redesign the site around GitHub and [Read The Docs](https://readthedocs.org/). 7 | 8 | ## Is this official? 9 | 10 | No. This is currently an unofficial fork for the sole purpose of showing what the site could look like in this new format. 11 | 12 | Hopefully the project members will like it. 13 | 14 | ## Original 15 | 16 | The original material comes from [pentest-standard.org](http://pentest-standard.org). It is reproduced verbatum in the [source](./source/) directory per the [GNU Free Documentation License](http://www.gnu.org/licenses/old-licenses/fdl-1.2.txt), under which the work is licensed. 17 | 18 | ## Experimental Version 19 | 20 | The RTD version can be found at [http://pentest-standard.readthedocs.io/en/latest/](http://pentest-standard.readthedocs.io/en/latest/). 21 | -------------------------------------------------------------------------------- /source/Media: -------------------------------------------------------------------------------- 1 | Here is some of the media releases since the birth of PTES. 2 | 3 | [http://www.zdnet.com.au/white-hat-standard-to-out-lazy-testers-339311763.htm Zdnet] 4 | 5 | [http://resources.infosecinstitute.com/standards-for-penetration-testing/ InfoSecInstitute] 6 | 7 | [http://blog.c22.cc/2011/03/04/penetration-testing-execution-standard/ Chris John Riley Blog] 8 | 9 | [http://www.iamit.org/blog/2011/03/defining-penetration-testing/ Iftach Ian Amit (iiamit) Blog] 10 | 11 | [http://www.secmaniac.com/march-2011/the-penetration-testing-execution-standard-ptes-alpha-released/ Dave Kennedy (ReL1K) Blog] 12 | 13 | [http://securityjustice.com/archives/164 Security Justice Podcast] 14 | 15 | [http://www.blip.tv/file/4936935 Blip.tv] 16 | 17 | [http://www.zonbi.org/ Zonbi.org] 18 | 19 | [https://www.infosecisland.com/blogview/12700-PTES-White-Hat-Hackers-Initiative.html InfoSecIsland] 20 | 21 | [http://www.zonbi.org/archives/454 Zonbi.org] 22 | 23 | [http://blip.tv/file/get/Aluc-Aluc_Radio_EP0x19386.m4a Aluc.TV Podcast] 24 | 25 | [http://www.isdpodcast.com/episode-318-shooting-the-shit-with-chris-nickerson-indi303/ ISDPodcast 1] 26 | 27 | [http://www.isdpodcast.com/episode-321-late-night-with-iftach-ian-amit-iiamit/ ISDPodcast 2] 28 | 29 | [http://www.securabit.com/2011/03/30/securabit-episode-78-comodogate-and-social-penetration/?utm_source=rss&utm_medium=rss&utm_campaign=securabit-episode-78-comodogate-and-social-penetration Securabit Podcast] 30 | 31 | [http://www.sourceconference.com/boston/ptes.asp Source Boston session on PTES] and the [http://www.sourceconference.com/ptes_interview.m4v video interview] 32 | 33 | -------------------------------------------------------------------------------- /media.rst: -------------------------------------------------------------------------------- 1 | Media 2 | ----- 3 | 4 | Here is some of the media releases since the birth of PTES. 5 | 6 | `Zdnet `__ 7 | 8 | `InfoSecInstitute `__ 9 | 10 | `Chris John Riley 11 | Blog `__ 12 | 13 | `Iftach Ian Amit (iiamit) 14 | Blog `__ 15 | 16 | `Dave Kennedy (ReL1K) 17 | Blog `__ 18 | 19 | `Security Justice Podcast `__ 20 | 21 | `Blip.tv `__ 22 | 23 | `Zonbi.org `__ 24 | 25 | `InfoSecIsland `__ 26 | 27 | `Zonbi.org `__ 28 | 29 | `Aluc.TV 30 | Podcast `__ 31 | 32 | `ISDPodcast 33 | 1 `__ 34 | 35 | `ISDPodcast 36 | 2 `__ 37 | 38 | `Securabit 39 | Podcast `__ 40 | 41 | `Source Boston session on 42 | PTES `__ and the `video 43 | interview `__ 44 | -------------------------------------------------------------------------------- /_build/html/_sources/media.txt: -------------------------------------------------------------------------------- 1 | Media 2 | ----- 3 | 4 | Here is some of the media releases since the birth of PTES. 5 | 6 | `Zdnet `__ 7 | 8 | `InfoSecInstitute `__ 9 | 10 | `Chris John Riley 11 | Blog `__ 12 | 13 | `Iftach Ian Amit (iiamit) 14 | Blog `__ 15 | 16 | `Dave Kennedy (ReL1K) 17 | Blog `__ 18 | 19 | `Security Justice Podcast `__ 20 | 21 | `Blip.tv `__ 22 | 23 | `Zonbi.org `__ 24 | 25 | `InfoSecIsland `__ 26 | 27 | `Zonbi.org `__ 28 | 29 | `Aluc.TV 30 | Podcast `__ 31 | 32 | `ISDPodcast 33 | 1 `__ 34 | 35 | `ISDPodcast 36 | 2 `__ 37 | 38 | `Securabit 39 | Podcast `__ 40 | 41 | `Source Boston session on 42 | PTES `__ and the `video 43 | interview `__ 44 | -------------------------------------------------------------------------------- /source/Main_Page: -------------------------------------------------------------------------------- 1 | 2 | ===High Level Organization of the Standard=== 3 | The penetration testing execution standard consists of seven (7) main sections. These cover everything related to a penetration test - from the initial communication and reasoning behind a pentest, through the intelligence gathering and threat modeling phases where testers are working behind the scenes in order to get a better understanding of the tested organization, through vulnerability research, exploitation and post exploitation, where the technical security expertise of the testers come to play and combine with the business understanding of the engagement, and finally to the reporting, which captures the entire process, in a manner that makes sense to the customer and provides the most value to it. 4 | 5 | This version can be considered a v1.0 as the core elements of the standard are solidified, and have been "road tested" for over a year through the industry. A v2.0 is in the works soon, and will provide more granular work in terms of "levels" - as in intensity levels at which each of the elements of a penetration test can be performed at. As no pentest is like another, and testing will range from the more mundane web application or network test, to a full-on red team engagement, said levels will enable an organization to define how much sophistication they expect their adversary to exhibit, and enable the tester to step up the intensity on those areas where the organization needs them the most. Some of the initial work on "levels" can be seen in the intelligence gathering section. 6 | 7 | Following are the main sections defined by the standard as the basis for penetration testing execution: 8 | *[[Pre-engagement|Pre-engagement Interactions]] 9 | *[[Intelligence_Gathering|Intelligence Gathering]] 10 | *[[Threat_Modeling|Threat Modeling]] 11 | *[[Vulnerability_Analysis|Vulnerability Analysis]] 12 | *[[exploitation|Exploitation]] 13 | *[[Post_Exploitation|Post Exploitation]] 14 | *[[reporting|Reporting]] 15 | 16 | As the standard does not provide any technical guidelines as far as how to execute an actual pentest, we have also created a technical guide to accompany the standard itself. The technical gude can be reached via the link below: 17 | 18 | *[[PTES_Technical_Guidelines | Technical Guidelines]] 19 | 20 | For more information on what this standard is, please visit: 21 | 22 | *[[FAQ|The Penetration Testing Execution Standard: FAQ]] 23 | 24 | -------------------------------------------------------------------------------- /index.rst: -------------------------------------------------------------------------------- 1 | .. _index: 2 | 3 | 4 | ########################################## 5 | The Penetration Testing Execution Standard 6 | ########################################## 7 | 8 | *************************************** 9 | High Level Organization of the Standard 10 | *************************************** 11 | 12 | **Fork Disclaimer**: Note that this is an unofficial fork, the goal for which is to experiment with an alternative platform for the standard. The official PTES can be located at ``_. 13 | 14 | The penetration testing execution standard consists of seven (7) main 15 | sections. These cover everything related to a penetration test - from 16 | the initial communication and reasoning behind a pentest, through the 17 | intelligence gathering and threat modeling phases where testers are 18 | working behind the scenes in order to get a better understanding of the 19 | tested organization, through vulnerability research, exploitation and 20 | post exploitation, where the technical security expertise of the testers 21 | come to play and combine with the business understanding of the 22 | engagement, and finally to the reporting, which captures the entire 23 | process, in a manner that makes sense to the customer and provides the 24 | most value to it. 25 | 26 | This version can be considered a v1.0 as the core elements of the 27 | standard are solidified, and have been "road tested" for over a year 28 | through the industry. A v2.0 is in the works soon, and will provide more 29 | granular work in terms of "levels" - as in intensity levels at which 30 | each of the elements of a penetration test can be performed at. As no 31 | pentest is like another, and testing will range from the more mundane 32 | web application or network test, to a full-on red team engagement, said 33 | levels will enable an organization to define how much sophistication 34 | they expect their adversary to exhibit, and enable the tester to step up 35 | the intensity on those areas where the organization needs them the most. 36 | Some of the initial work on "levels" can be seen in the intelligence 37 | gathering section. 38 | 39 | Following are the main sections defined by the standard as the basis for 40 | penetration testing execution: 41 | 42 | #. :ref:`preengagement_interactions` 43 | #. :ref:`intelligence_gathering` 44 | #. :ref:`threat_modeling` 45 | #. :ref:`vulnerability_analysis` 46 | #. :ref:`exploitation` 47 | #. :ref:`post_exploitation` 48 | #. :ref:`reporting` 49 | 50 | As the standard does not provide any technical guidelines as far as how 51 | to execute an actual pentest, we have also created a technical guide to 52 | accompany the standard itself. The technical gude can be reached via the 53 | link below: 54 | 55 | * :ref:`technical_guidelines` 56 | 57 | For more information on what this standard is, please visit: 58 | 59 | * :ref:`faq` 60 | -------------------------------------------------------------------------------- /_build/html/_sources/index.txt: -------------------------------------------------------------------------------- 1 | .. _index: 2 | 3 | 4 | ########################################## 5 | The Penetration Testing Execution Standard 6 | ########################################## 7 | 8 | *************************************** 9 | High Level Organization of the Standard 10 | *************************************** 11 | 12 | **Fork Disclaimer**: Note that this is an unofficial fork, the goal for which is to experiment with an alternative platform for the standard. The official PTES can be located at ``_. 13 | 14 | The penetration testing execution standard consists of seven (7) main 15 | sections. These cover everything related to a penetration test - from 16 | the initial communication and reasoning behind a pentest, through the 17 | intelligence gathering and threat modeling phases where testers are 18 | working behind the scenes in order to get a better understanding of the 19 | tested organization, through vulnerability research, exploitation and 20 | post exploitation, where the technical security expertise of the testers 21 | come to play and combine with the business understanding of the 22 | engagement, and finally to the reporting, which captures the entire 23 | process, in a manner that makes sense to the customer and provides the 24 | most value to it. 25 | 26 | This version can be considered a v1.0 as the core elements of the 27 | standard are solidified, and have been "road tested" for over a year 28 | through the industry. A v2.0 is in the works soon, and will provide more 29 | granular work in terms of "levels" - as in intensity levels at which 30 | each of the elements of a penetration test can be performed at. As no 31 | pentest is like another, and testing will range from the more mundane 32 | web application or network test, to a full-on red team engagement, said 33 | levels will enable an organization to define how much sophistication 34 | they expect their adversary to exhibit, and enable the tester to step up 35 | the intensity on those areas where the organization needs them the most. 36 | Some of the initial work on "levels" can be seen in the intelligence 37 | gathering section. 38 | 39 | Following are the main sections defined by the standard as the basis for 40 | penetration testing execution: 41 | 42 | #. :ref:`preengagement_interactions` 43 | #. :ref:`intelligence_gathering` 44 | #. :ref:`threat_modeling` 45 | #. :ref:`vulnerability_analysis` 46 | #. :ref:`exploitation` 47 | #. :ref:`post_exploitation` 48 | #. :ref:`reporting` 49 | 50 | As the standard does not provide any technical guidelines as far as how 51 | to execute an actual pentest, we have also created a technical guide to 52 | accompany the standard itself. The technical gude can be reached via the 53 | link below: 54 | 55 | * :ref:`technical_guidelines` 56 | 57 | For more information on what this standard is, please visit: 58 | 59 | * :ref:`faq` 60 | -------------------------------------------------------------------------------- /_build/html/_static/css/badge_only.css: -------------------------------------------------------------------------------- 1 | .fa:before{-webkit-font-smoothing:antialiased}.clearfix{*zoom:1}.clearfix:after,.clearfix:before{display:table;content:""}.clearfix:after{clear:both}@font-face{font-family:FontAwesome;font-style:normal;font-weight:400;src:url(fonts/fontawesome-webfont.eot?674f50d287a8c48dc19ba404d20fe713?#iefix) format("embedded-opentype"),url(fonts/fontawesome-webfont.woff2?af7ae505a9eed503f8b8e6982036873e) format("woff2"),url(fonts/fontawesome-webfont.woff?fee66e712a8a08eef5805a46892932ad) format("woff"),url(fonts/fontawesome-webfont.ttf?b06871f281fee6b241d60582ae9369b9) format("truetype"),url(fonts/fontawesome-webfont.svg?912ec66d7572ff821749319396470bde#FontAwesome) format("svg")}.fa:before{font-family:FontAwesome;font-style:normal;font-weight:400;line-height:1}.fa:before,a .fa{text-decoration:inherit}.fa:before,a .fa,li .fa{display:inline-block}li .fa-large:before{width:1.875em}ul.fas{list-style-type:none;margin-left:2em;text-indent:-.8em}ul.fas li .fa{width:.8em}ul.fas li .fa-large:before{vertical-align:baseline}.fa-book:before,.icon-book:before{content:"\f02d"}.fa-caret-down:before,.icon-caret-down:before{content:"\f0d7"}.fa-caret-up:before,.icon-caret-up:before{content:"\f0d8"}.fa-caret-left:before,.icon-caret-left:before{content:"\f0d9"}.fa-caret-right:before,.icon-caret-right:before{content:"\f0da"}.rst-versions{position:fixed;bottom:0;left:0;width:300px;color:#fcfcfc;background:#1f1d1d;font-family:Lato,proxima-nova,Helvetica Neue,Arial,sans-serif;z-index:400}.rst-versions a{color:#2980b9;text-decoration:none}.rst-versions .rst-badge-small{display:none}.rst-versions .rst-current-version{padding:12px;background-color:#272525;display:block;text-align:right;font-size:90%;cursor:pointer;color:#27ae60}.rst-versions .rst-current-version:after{clear:both;content:"";display:block}.rst-versions .rst-current-version .fa{color:#fcfcfc}.rst-versions .rst-current-version .fa-book,.rst-versions .rst-current-version .icon-book{float:left}.rst-versions .rst-current-version.rst-out-of-date{background-color:#e74c3c;color:#fff}.rst-versions .rst-current-version.rst-active-old-version{background-color:#f1c40f;color:#000}.rst-versions.shift-up{height:auto;max-height:100%;overflow-y:scroll}.rst-versions.shift-up .rst-other-versions{display:block}.rst-versions .rst-other-versions{font-size:90%;padding:12px;color:grey;display:none}.rst-versions .rst-other-versions hr{display:block;height:1px;border:0;margin:20px 0;padding:0;border-top:1px solid #413d3d}.rst-versions .rst-other-versions dd{display:inline-block;margin:0}.rst-versions .rst-other-versions dd a{display:inline-block;padding:6px;color:#fcfcfc}.rst-versions.rst-badge{width:auto;bottom:20px;right:20px;left:auto;border:none;max-width:300px;max-height:90%}.rst-versions.rst-badge .fa-book,.rst-versions.rst-badge .icon-book{float:none;line-height:30px}.rst-versions.rst-badge.shift-up .rst-current-version{text-align:right}.rst-versions.rst-badge.shift-up .rst-current-version .fa-book,.rst-versions.rst-badge.shift-up .rst-current-version .icon-book{float:left}.rst-versions.rst-badge>.rst-current-version{width:auto;height:30px;line-height:30px;padding:0 6px;display:block;text-align:center}@media screen and (max-width:768px){.rst-versions{width:85%;display:none}.rst-versions.shift{display:block}} -------------------------------------------------------------------------------- /_build/html/genindex.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | Index — pentest-standard 1.1 documentation 7 | 8 | 9 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 57 | 58 |
62 | 63 |
64 |
65 |
66 |
    67 |
  • »
  • 68 |
  • Index
  • 69 |
  • 70 |
  • 71 |
72 |
73 |
74 |
75 |
76 | 77 | 78 |

Index

79 | 80 |
81 | 82 |
83 | 84 | 85 |
86 |
87 |
88 | 89 |
90 | 91 |
92 |

© Copyright 2016, The PTES Team.

93 |
94 | 95 | Built with Sphinx using a 96 | theme 97 | provided by Read the Docs. 98 | 99 | 100 |
101 |
102 |
103 |
104 |
105 | 110 | 111 | 112 | -------------------------------------------------------------------------------- /_build/html/_static/js/theme.js: -------------------------------------------------------------------------------- 1 | !function(n){var e={};function t(i){if(e[i])return e[i].exports;var o=e[i]={i:i,l:!1,exports:{}};return n[i].call(o.exports,o,o.exports,t),o.l=!0,o.exports}t.m=n,t.c=e,t.d=function(n,e,i){t.o(n,e)||Object.defineProperty(n,e,{enumerable:!0,get:i})},t.r=function(n){"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(n,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(n,"__esModule",{value:!0})},t.t=function(n,e){if(1&e&&(n=t(n)),8&e)return n;if(4&e&&"object"==typeof n&&n&&n.__esModule)return n;var i=Object.create(null);if(t.r(i),Object.defineProperty(i,"default",{enumerable:!0,value:n}),2&e&&"string"!=typeof n)for(var o in n)t.d(i,o,function(e){return n[e]}.bind(null,o));return i},t.n=function(n){var e=n&&n.__esModule?function(){return n.default}:function(){return n};return t.d(e,"a",e),e},t.o=function(n,e){return Object.prototype.hasOwnProperty.call(n,e)},t.p="",t(t.s=0)}([function(n,e,t){t(1),n.exports=t(3)},function(n,e,t){(function(){var e="undefined"!=typeof window?window.jQuery:t(2);n.exports.ThemeNav={navBar:null,win:null,winScroll:!1,winResize:!1,linkScroll:!1,winPosition:0,winHeight:null,docHeight:null,isRunning:!1,enable:function(n){var t=this;void 0===n&&(n=!0),t.isRunning||(t.isRunning=!0,e((function(e){t.init(e),t.reset(),t.win.on("hashchange",t.reset),n&&t.win.on("scroll",(function(){t.linkScroll||t.winScroll||(t.winScroll=!0,requestAnimationFrame((function(){t.onScroll()})))})),t.win.on("resize",(function(){t.winResize||(t.winResize=!0,requestAnimationFrame((function(){t.onResize()})))})),t.onResize()})))},enableSticky:function(){this.enable(!0)},init:function(n){n(document);var e=this;this.navBar=n("div.wy-side-scroll:first"),this.win=n(window),n(document).on("click","[data-toggle='wy-nav-top']",(function(){n("[data-toggle='wy-nav-shift']").toggleClass("shift"),n("[data-toggle='rst-versions']").toggleClass("shift")})).on("click",".wy-menu-vertical .current ul li a",(function(){var t=n(this);n("[data-toggle='wy-nav-shift']").removeClass("shift"),n("[data-toggle='rst-versions']").toggleClass("shift"),e.toggleCurrent(t),e.hashChange()})).on("click","[data-toggle='rst-current-version']",(function(){n("[data-toggle='rst-versions']").toggleClass("shift-up")})),n("table.docutils:not(.field-list,.footnote,.citation)").wrap("
"),n("table.docutils.footnote").wrap("
"),n("table.docutils.citation").wrap("
"),n(".wy-menu-vertical ul").not(".simple").siblings("a").each((function(){var t=n(this);expand=n(''),expand.on("click",(function(n){return e.toggleCurrent(t),n.stopPropagation(),!1})),t.prepend(expand)}))},reset:function(){var n=encodeURI(window.location.hash)||"#";try{var e=$(".wy-menu-vertical"),t=e.find('[href="'+n+'"]');if(0===t.length){var i=$('.document [id="'+n.substring(1)+'"]').closest("div.section");0===(t=e.find('[href="#'+i.attr("id")+'"]')).length&&(t=e.find('[href="#"]'))}if(t.length>0){$(".wy-menu-vertical .current").removeClass("current").attr("aria-expanded","false"),t.addClass("current").attr("aria-expanded","true"),t.closest("li.toctree-l1").parent().addClass("current").attr("aria-expanded","true");for(let n=1;n<=10;n++)t.closest("li.toctree-l"+n).addClass("current").attr("aria-expanded","true");t[0].scrollIntoView()}}catch(n){console.log("Error expanding nav for anchor",n)}},onScroll:function(){this.winScroll=!1;var n=this.win.scrollTop(),e=n+this.winHeight,t=this.navBar.scrollTop()+(n-this.winPosition);n<0||e>this.docHeight||(this.navBar.scrollTop(t),this.winPosition=n)},onResize:function(){this.winResize=!1,this.winHeight=this.win.height(),this.docHeight=$(document).height()},hashChange:function(){this.linkScroll=!0,this.win.one("hashchange",(function(){this.linkScroll=!1}))},toggleCurrent:function(n){var e=n.closest("li");e.siblings("li.current").removeClass("current").attr("aria-expanded","false"),e.siblings().find("li.current").removeClass("current").attr("aria-expanded","false");var t=e.find("> ul li");t.length&&(t.removeClass("current").attr("aria-expanded","false"),e.toggleClass("current").attr("aria-expanded",(function(n,e){return"true"==e?"false":"true"})))}},"undefined"!=typeof window&&(window.SphinxRtdTheme={Navigation:n.exports.ThemeNav,StickyNav:n.exports.ThemeNav}),function(){for(var n=0,e=["ms","moz","webkit","o"],t=0;t 2 | 3 | 4 | 5 | 6 | Search — pentest-standard 1.1 documentation 7 | 8 | 9 | 10 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 60 | 61 |
65 | 66 |
67 |
68 |
69 |
    70 |
  • »
  • 71 |
  • Search
  • 72 |
  • 73 |
  • 74 |
75 |
76 |
77 |
78 |
79 | 80 | 87 | 88 | 89 |
90 | 91 |
92 | 93 |
94 |
95 |
96 | 97 |
98 | 99 |
100 |

© Copyright 2016, The PTES Team.

101 |
102 | 103 | Built with Sphinx using a 104 | theme 105 | provided by Read the Docs. 106 | 107 | 108 |
109 |
110 |
111 |
112 |
113 | 118 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | -------------------------------------------------------------------------------- /source/FAQ: -------------------------------------------------------------------------------- 1 | == Penetration Testing Execution Standard - the FAQ == 2 | 3 | 4 | ==== '''Q''': What is this "Penetration Testing Execution Standard"? ==== 5 | '''A''': It is a new standard designed to provide both businesses and security 6 | service providers with a common language and scope for performing 7 | penetration testing (i.e. Security evaluations). It started early in 2009 following a discussion that sparked between some of the founding members over the value (or lack of) of penetration testing in the industry. 8 | 9 | ===='''Q''': Who is involved with this standard?==== 10 | '''A''': We are a group of information security practitioners from all areas of 11 | the industry (I.e. Financial Institutions, Service Providers, Security 12 | Vendors). The group currently consists of: 13 | *[http://twitter.com/indi303 Chris Nickerson], CEO - [http://www.lares.com Lares Consulting]. 14 | *[http://twitter.com/hackingdave Dave Kennedy], President/CEO - [https://www.trustedsec.com/blog/ blog] [https://www.trustedsec.com/ TrustedSec] . 15 | *[http://twitter.com/chrisjohnriley Chris John Riley], IT Security Analyst - [http://blog.c22.cc blog] Raiffeisen Informatik GmbH. 16 | *[http://twitter.com/infosecmafia Eric Smith], Partner - [http://www.lares.com Lares Consulting]. 17 | *[[User:iamit|Iftach Ian Amit]], Director of Services - [http://www.iamit.org/blog blog] [http://www.ioactive.com IOActive]. 18 | *[http://www.pentest-standard.org/index.php?title=User:drew Andrew Rabie], Wizard - [http://www.avon.com/ Avon Products Inc]. 19 | *[http://twitter.com/stfn42 Stefan Friedli], Senior Security Consultant - [http://www.scip.ch scip AG]. 20 | *[[User:Meeas|Justin Searle]], Senior Security Analyst - [http://www.inguardians.com InGuardians]. 21 | *[http://twitter.com/kaospunk Brandon Knight], Senior Security Consultant - [http://www.securestate.com/ SecureState] . 22 | *[http://twitter.com/carnal0wnage Chris Gates], Senior Security Consultant - [http://carnal0wnage.attackresearch.com/ blog] [http://www.lares.com Lares Consulting]. 23 | *[http://twitter.com/j0emccray Joe McCray], CEO - Strategic Security. 24 | *[http://twitter.com/Carlos_Perez Carlos Perez], Lead Vulnerability Research Engineer - Tenable Security. 25 | *[http://twitter.com/strandjs John Strand], Owner - Black Hills Information Security. 26 | *[http://twitter.com/steve_tornio Steve Tornio], Senior Consultant - Sunera LLC. 27 | *[http://twitter.com/c7five Nick Percoco], Senior Vice President - SpiderLabs at Trustwave. 28 | *[http://twitter.com/daveshackleford Dave Shackelford], Security Consultant, SANS Instructor. 29 | *[http://twitter.com/attackresearch Val Smith] - Attack Research. 30 | *[http://twitter.com/digininja Robin Wood], Senior Security Engineer - [http://www.digininja.org/ blog] [http://www.randomstorm.com RandomStorm]. 31 | *[http://twitter.com/wimremes Wim Remes], Security Consultant - EY Belgium. 32 | *[http://twitter.com/isdpodcast Rick Hayes], Force Practice Lead - [https://www.trustedsec.com/ TrustedSec] . 33 | 34 | ===='''Q''': So is this a closed group or can I join in?==== 35 | '''A''': We started this with about 6 people, the first in-person meeting held 36 | almost 20. We would love more insight and down-to-earth opinions so if you 37 | can contribute please feel free to email us. 38 | 39 | ===='''Q''': Is this going to be a formal standard?==== 40 | '''A''': We are aiming to create an actual standard so that businesses can have 41 | a baseline of what is needed when they get a pentest as well as an understanding of what type of testing they require or would provide value to their business. The lack of 42 | standardization now is only hurting the industry as businesses are getting 43 | low-quality work done, and practitioners lack guidance in terms of what is 44 | needed to provide quality service. 45 | 46 | ===='''Q''': Is the standard going to include all possible pentest scenarios?==== 47 | '''A''': While we can't possibly cover all scenarios, the standard is going to 48 | define a baseline for the minimum that is required from a basic pentest, 49 | as well as several "levels" on top of it that provide more comprehensive 50 | activities required for organizations with higher security needs. The 51 | different levels would also be defined as per the industry in which they 52 | should be the baseline for. 53 | 54 | ===='''Q''': Is this effort going to standardize the reporting as well?==== 55 | '''A''': Yes. We feel that providing a standard for the test without defining 56 | how the report is provided would be useless. We will define both executive 57 | (business) reporting as well as technical reporting as an integrated part 58 | of the standard. 59 | 60 | ===='''Q''': Who is the intended audience for this standard/project?==== 61 | '''A''': Two main communities: businesses that require the service, and service providers. For businesses the goal is to enable them to demand a specific baseline of work as part of a pentest. For service providers the goal is to provide a baseline for the kinds of activities needed, what should be taken into account as part of the pentest from scoping through reporting and deliverables. 62 | 63 | ===='''Q''': Is there a mindmap version of the original sections?==== 64 | '''A''': Following popular demand, we have _a_ version of the mindmap used when creating the first drafts of the standard available for download [http://iamit.org/docs/Penetration_Testing_Execution_Standard.mm here] (in FreeMind format). 65 | 66 | -------------------------------------------------------------------------------- /faq.rst: -------------------------------------------------------------------------------- 1 | .. _faq: 2 | 3 | *** 4 | FAQ 5 | *** 6 | 7 | **Q**: What is this "Penetration Testing Execution Standard"? 8 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 9 | 10 | **A**: It is a new standard designed to provide both businesses and 11 | security service providers with a common language and scope for 12 | performing penetration testing (i.e. Security evaluations). It started 13 | early in 2009 following a discussion that sparked between some of the 14 | founding members over the value (or lack of) of penetration testing in 15 | the industry. 16 | 17 | **Q**: Who is involved with this standard? 18 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 19 | 20 | **A**: We are a group of information security practitioners from all 21 | areas of the industry (I.e. Financial Institutions, Service Providers, 22 | Security Vendors). The group currently consists of: 23 | 24 | - `Chris Nickerson `__, CEO - `Lares 25 | Consulting `__. 26 | - `Dave Kennedy `__, President/CEO - 27 | `blog `__ 28 | `TrustedSec `__ . 29 | - `Chris John Riley `__, IT Security 30 | Analyst - `blog `__ Raiffeisen Informatik GmbH. 31 | - `Eric Smith `__, Partner - `Lares 32 | Consulting `__. 33 | - `Iftach Ian Amit `__, Director of Services - 34 | `blog `__ 35 | `IOActive `__. 36 | - `Andrew 37 | Rabie `__, 38 | Wizard - `Avon Products Inc `__. 39 | - `Stefan Friedli `__, Senior Security 40 | Consultant - `scip AG `__. 41 | - `Justin Searle `__, Senior Security Analyst - 42 | `InGuardians `__. 43 | - `Brandon Knight `__, Senior Security 44 | Consultant - `SecureState `__ . 45 | - `Chris Gates `__, Senior Security 46 | Consultant - `blog `__ 47 | `Lares Consulting `__. 48 | - `Joe McCray `__, CEO - Strategic 49 | Security. 50 | - `Carlos Perez `__, Lead 51 | Vulnerability Research Engineer - Tenable Security. 52 | - `John Strand `__, Owner - Black Hills 53 | Information Security. 54 | - `Steve Tornio `__, Senior Consultant 55 | - Sunera LLC. 56 | - `Nick Percoco `__, Senior Vice President - 57 | SpiderLabs at Trustwave. 58 | - `Dave Shackelford `__, Security 59 | Consultant, SANS Instructor. 60 | - `Val Smith `__ - Attack Research. 61 | - `Robin Wood `__, Senior Security 62 | Engineer - `blog `__ 63 | `RandomStorm `__. 64 | - `Wim Remes `__, Security Consultant - EY 65 | Belgium. 66 | - `Rick Hayes `__, Force Practice Lead - 67 | `TrustedSec `__ . 68 | 69 | **Q**: So is this a closed group or can I join in? 70 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 71 | 72 | **A**: We started this with about 6 people, the first in-person meeting 73 | held almost 20. We would love more insight and down-to-earth opinions so 74 | if you can contribute please feel free to email us. 75 | 76 | **Q**: Is this going to be a formal standard? 77 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 78 | 79 | **A**: We are aiming to create an actual standard so that businesses can 80 | have a baseline of what is needed when they get a pentest as well as an 81 | understanding of what type of testing they require or would provide 82 | value to their business. The lack of standardization now is only hurting 83 | the industry as businesses are getting low-quality work done, and 84 | practitioners lack guidance in terms of what is needed to provide 85 | quality service. 86 | 87 | **Q**: Is the standard going to include all possible pentest scenarios? 88 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 89 | 90 | **A**: While we can't possibly cover all scenarios, the standard is 91 | going to define a baseline for the minimum that is required from a basic 92 | pentest, as well as several "levels" on top of it that provide more 93 | comprehensive activities required for organizations with higher security 94 | needs. The different levels would also be defined as per the industry in 95 | which they should be the baseline for. 96 | 97 | **Q**: Is this effort going to standardize the reporting as well? 98 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 99 | 100 | **A**: Yes. We feel that providing a standard for the test without 101 | defining how the report is provided would be useless. We will define 102 | both executive (business) reporting as well as technical reporting as an 103 | integrated part of the standard. 104 | 105 | **Q**: Who is the intended audience for this standard/project? 106 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 107 | 108 | **A**: Two main communities: businesses that require the service, and 109 | service providers. For businesses the goal is to enable them to demand a 110 | specific baseline of work as part of a pentest. For service providers 111 | the goal is to provide a baseline for the kinds of activities needed, 112 | what should be taken into account as part of the pentest from scoping 113 | through reporting and deliverables. 114 | 115 | **Q**: Is there a mindmap version of the original sections? 116 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 117 | 118 | **A**: Following popular demand, we have \_a\_ version of the mindmap 119 | used when creating the first drafts of the standard available for 120 | download 121 | `here `__ 122 | (in FreeMind format). 123 | -------------------------------------------------------------------------------- /_build/html/_sources/faq.txt: -------------------------------------------------------------------------------- 1 | .. _faq: 2 | 3 | *** 4 | FAQ 5 | *** 6 | 7 | **Q**: What is this "Penetration Testing Execution Standard"? 8 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 9 | 10 | **A**: It is a new standard designed to provide both businesses and 11 | security service providers with a common language and scope for 12 | performing penetration testing (i.e. Security evaluations). It started 13 | early in 2009 following a discussion that sparked between some of the 14 | founding members over the value (or lack of) of penetration testing in 15 | the industry. 16 | 17 | **Q**: Who is involved with this standard? 18 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 19 | 20 | **A**: We are a group of information security practitioners from all 21 | areas of the industry (I.e. Financial Institutions, Service Providers, 22 | Security Vendors). The group currently consists of: 23 | 24 | - `Chris Nickerson `__, CEO - `Lares 25 | Consulting `__. 26 | - `Dave Kennedy `__, President/CEO - 27 | `blog `__ 28 | `TrustedSec `__ . 29 | - `Chris John Riley `__, IT Security 30 | Analyst - `blog `__ Raiffeisen Informatik GmbH. 31 | - `Eric Smith `__, Partner - `Lares 32 | Consulting `__. 33 | - `Iftach Ian Amit `__, Director of Services - 34 | `blog `__ 35 | `IOActive `__. 36 | - `Andrew 37 | Rabie `__, 38 | Wizard - `Avon Products Inc `__. 39 | - `Stefan Friedli `__, Senior Security 40 | Consultant - `scip AG `__. 41 | - `Justin Searle `__, Senior Security Analyst - 42 | `InGuardians `__. 43 | - `Brandon Knight `__, Senior Security 44 | Consultant - `SecureState `__ . 45 | - `Chris Gates `__, Senior Security 46 | Consultant - `blog `__ 47 | `Lares Consulting `__. 48 | - `Joe McCray `__, CEO - Strategic 49 | Security. 50 | - `Carlos Perez `__, Lead 51 | Vulnerability Research Engineer - Tenable Security. 52 | - `John Strand `__, Owner - Black Hills 53 | Information Security. 54 | - `Steve Tornio `__, Senior Consultant 55 | - Sunera LLC. 56 | - `Nick Percoco `__, Senior Vice President - 57 | SpiderLabs at Trustwave. 58 | - `Dave Shackelford `__, Security 59 | Consultant, SANS Instructor. 60 | - `Val Smith `__ - Attack Research. 61 | - `Robin Wood `__, Senior Security 62 | Engineer - `blog `__ 63 | `RandomStorm `__. 64 | - `Wim Remes `__, Security Consultant - EY 65 | Belgium. 66 | - `Rick Hayes `__, Force Practice Lead - 67 | `TrustedSec `__ . 68 | 69 | **Q**: So is this a closed group or can I join in? 70 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 71 | 72 | **A**: We started this with about 6 people, the first in-person meeting 73 | held almost 20. We would love more insight and down-to-earth opinions so 74 | if you can contribute please feel free to email us. 75 | 76 | **Q**: Is this going to be a formal standard? 77 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 78 | 79 | **A**: We are aiming to create an actual standard so that businesses can 80 | have a baseline of what is needed when they get a pentest as well as an 81 | understanding of what type of testing they require or would provide 82 | value to their business. The lack of standardization now is only hurting 83 | the industry as businesses are getting low-quality work done, and 84 | practitioners lack guidance in terms of what is needed to provide 85 | quality service. 86 | 87 | **Q**: Is the standard going to include all possible pentest scenarios? 88 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 89 | 90 | **A**: While we can't possibly cover all scenarios, the standard is 91 | going to define a baseline for the minimum that is required from a basic 92 | pentest, as well as several "levels" on top of it that provide more 93 | comprehensive activities required for organizations with higher security 94 | needs. The different levels would also be defined as per the industry in 95 | which they should be the baseline for. 96 | 97 | **Q**: Is this effort going to standardize the reporting as well? 98 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 99 | 100 | **A**: Yes. We feel that providing a standard for the test without 101 | defining how the report is provided would be useless. We will define 102 | both executive (business) reporting as well as technical reporting as an 103 | integrated part of the standard. 104 | 105 | **Q**: Who is the intended audience for this standard/project? 106 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 107 | 108 | **A**: Two main communities: businesses that require the service, and 109 | service providers. For businesses the goal is to enable them to demand a 110 | specific baseline of work as part of a pentest. For service providers 111 | the goal is to provide a baseline for the kinds of activities needed, 112 | what should be taken into account as part of the pentest from scoping 113 | through reporting and deliverables. 114 | 115 | **Q**: Is there a mindmap version of the original sections? 116 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 117 | 118 | **A**: Following popular demand, we have \_a\_ version of the mindmap 119 | used when creating the first drafts of the standard available for 120 | download 121 | `here `__ 122 | (in FreeMind format). 123 | -------------------------------------------------------------------------------- /_build/html/media.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | Media — pentest-standard 1.1 documentation 8 | 9 | 10 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 59 | 60 |
64 | 65 |
66 |
67 |
68 | 75 |
76 |
77 |
78 |
79 | 80 |
81 |

Media

82 |

Here is some of the media releases since the birth of PTES.

83 |

Zdnet

84 |

InfoSecInstitute

85 |

Chris John Riley 86 | Blog

87 |

Iftach Ian Amit (iiamit) 88 | Blog

89 |

Dave Kennedy (ReL1K) 90 | Blog

91 |

Security Justice Podcast

92 |

Blip.tv

93 |

Zonbi.org

94 |

InfoSecIsland

95 |

Zonbi.org

96 |

Aluc.TV 97 | Podcast

98 |

ISDPodcast 99 | 1

100 |

ISDPodcast 101 | 2

102 |

Securabit 103 | Podcast

104 |

Source Boston session on 105 | PTES and the video 106 | interview

107 |
108 | 109 | 110 |
111 |
112 |
115 | 116 |
117 | 118 |
119 |

© Copyright 2016, The PTES Team.

120 |
121 | 122 | Built with Sphinx using a 123 | theme 124 | provided by Read the Docs. 125 | 126 | 127 |
128 |
129 |
130 |
131 |
132 | 137 | 138 | 139 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | # Makefile for Sphinx documentation 2 | # 3 | 4 | # You can set these variables from the command line. 5 | SPHINXOPTS = 6 | SPHINXBUILD = sphinx-build 7 | PAPER = 8 | BUILDDIR = _build 9 | 10 | # Internal variables. 11 | PAPEROPT_a4 = -D latex_paper_size=a4 12 | PAPEROPT_letter = -D latex_paper_size=letter 13 | ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) . 14 | # the i18n builder cannot share the environment and doctrees with the others 15 | I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) . 16 | 17 | .PHONY: help 18 | help: 19 | @echo "Please use \`make ' where is one of" 20 | @echo " html to make standalone HTML files" 21 | @echo " dirhtml to make HTML files named index.html in directories" 22 | @echo " singlehtml to make a single large HTML file" 23 | @echo " pickle to make pickle files" 24 | @echo " json to make JSON files" 25 | @echo " htmlhelp to make HTML files and a HTML help project" 26 | @echo " qthelp to make HTML files and a qthelp project" 27 | @echo " applehelp to make an Apple Help Book" 28 | @echo " devhelp to make HTML files and a Devhelp project" 29 | @echo " epub to make an epub" 30 | @echo " epub3 to make an epub3" 31 | @echo " latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter" 32 | @echo " latexpdf to make LaTeX files and run them through pdflatex" 33 | @echo " latexpdfja to make LaTeX files and run them through platex/dvipdfmx" 34 | @echo " text to make text files" 35 | @echo " man to make manual pages" 36 | @echo " texinfo to make Texinfo files" 37 | @echo " info to make Texinfo files and run them through makeinfo" 38 | @echo " gettext to make PO message catalogs" 39 | @echo " changes to make an overview of all changed/added/deprecated items" 40 | @echo " xml to make Docutils-native XML files" 41 | @echo " pseudoxml to make pseudoxml-XML files for display purposes" 42 | @echo " linkcheck to check all external links for integrity" 43 | @echo " doctest to run all doctests embedded in the documentation (if enabled)" 44 | @echo " coverage to run coverage check of the documentation (if enabled)" 45 | @echo " dummy to check syntax errors of document sources" 46 | 47 | .PHONY: clean 48 | clean: 49 | rm -rf $(BUILDDIR)/* 50 | 51 | .PHONY: html 52 | html: 53 | $(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html 54 | @echo 55 | @echo "Build finished. The HTML pages are in $(BUILDDIR)/html." 56 | 57 | .PHONY: dirhtml 58 | dirhtml: 59 | $(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml 60 | @echo 61 | @echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml." 62 | 63 | .PHONY: singlehtml 64 | singlehtml: 65 | $(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml 66 | @echo 67 | @echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml." 68 | 69 | .PHONY: pickle 70 | pickle: 71 | $(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle 72 | @echo 73 | @echo "Build finished; now you can process the pickle files." 74 | 75 | .PHONY: json 76 | json: 77 | $(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json 78 | @echo 79 | @echo "Build finished; now you can process the JSON files." 80 | 81 | .PHONY: htmlhelp 82 | htmlhelp: 83 | $(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp 84 | @echo 85 | @echo "Build finished; now you can run HTML Help Workshop with the" \ 86 | ".hhp project file in $(BUILDDIR)/htmlhelp." 87 | 88 | .PHONY: qthelp 89 | qthelp: 90 | $(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp 91 | @echo 92 | @echo "Build finished; now you can run "qcollectiongenerator" with the" \ 93 | ".qhcp project file in $(BUILDDIR)/qthelp, like this:" 94 | @echo "# qcollectiongenerator $(BUILDDIR)/qthelp/ThePenetrationTestingExecutionStandard.qhcp" 95 | @echo "To view the help file:" 96 | @echo "# assistant -collectionFile $(BUILDDIR)/qthelp/ThePenetrationTestingExecutionStandard.qhc" 97 | 98 | .PHONY: applehelp 99 | applehelp: 100 | $(SPHINXBUILD) -b applehelp $(ALLSPHINXOPTS) $(BUILDDIR)/applehelp 101 | @echo 102 | @echo "Build finished. The help book is in $(BUILDDIR)/applehelp." 103 | @echo "N.B. You won't be able to view it unless you put it in" \ 104 | "~/Library/Documentation/Help or install it in your application" \ 105 | "bundle." 106 | 107 | .PHONY: devhelp 108 | devhelp: 109 | $(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp 110 | @echo 111 | @echo "Build finished." 112 | @echo "To view the help file:" 113 | @echo "# mkdir -p $$HOME/.local/share/devhelp/ThePenetrationTestingExecutionStandard" 114 | @echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/ThePenetrationTestingExecutionStandard" 115 | @echo "# devhelp" 116 | 117 | .PHONY: epub 118 | epub: 119 | $(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub 120 | @echo 121 | @echo "Build finished. The epub file is in $(BUILDDIR)/epub." 122 | 123 | .PHONY: epub3 124 | epub3: 125 | $(SPHINXBUILD) -b epub3 $(ALLSPHINXOPTS) $(BUILDDIR)/epub3 126 | @echo 127 | @echo "Build finished. The epub3 file is in $(BUILDDIR)/epub3." 128 | 129 | .PHONY: latex 130 | latex: 131 | $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex 132 | @echo 133 | @echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex." 134 | @echo "Run \`make' in that directory to run these through (pdf)latex" \ 135 | "(use \`make latexpdf' here to do that automatically)." 136 | 137 | .PHONY: latexpdf 138 | latexpdf: 139 | $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex 140 | @echo "Running LaTeX files through pdflatex..." 141 | $(MAKE) -C $(BUILDDIR)/latex all-pdf 142 | @echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex." 143 | 144 | .PHONY: latexpdfja 145 | latexpdfja: 146 | $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex 147 | @echo "Running LaTeX files through platex and dvipdfmx..." 148 | $(MAKE) -C $(BUILDDIR)/latex all-pdf-ja 149 | @echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex." 150 | 151 | .PHONY: text 152 | text: 153 | $(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text 154 | @echo 155 | @echo "Build finished. The text files are in $(BUILDDIR)/text." 156 | 157 | .PHONY: man 158 | man: 159 | $(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man 160 | @echo 161 | @echo "Build finished. The manual pages are in $(BUILDDIR)/man." 162 | 163 | .PHONY: texinfo 164 | texinfo: 165 | $(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo 166 | @echo 167 | @echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo." 168 | @echo "Run \`make' in that directory to run these through makeinfo" \ 169 | "(use \`make info' here to do that automatically)." 170 | 171 | .PHONY: info 172 | info: 173 | $(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo 174 | @echo "Running Texinfo files through makeinfo..." 175 | make -C $(BUILDDIR)/texinfo info 176 | @echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo." 177 | 178 | .PHONY: gettext 179 | gettext: 180 | $(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale 181 | @echo 182 | @echo "Build finished. The message catalogs are in $(BUILDDIR)/locale." 183 | 184 | .PHONY: changes 185 | changes: 186 | $(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes 187 | @echo 188 | @echo "The overview file is in $(BUILDDIR)/changes." 189 | 190 | .PHONY: linkcheck 191 | linkcheck: 192 | $(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck 193 | @echo 194 | @echo "Link check complete; look for any errors in the above output " \ 195 | "or in $(BUILDDIR)/linkcheck/output.txt." 196 | 197 | .PHONY: doctest 198 | doctest: 199 | $(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest 200 | @echo "Testing of doctests in the sources finished, look at the " \ 201 | "results in $(BUILDDIR)/doctest/output.txt." 202 | 203 | .PHONY: coverage 204 | coverage: 205 | $(SPHINXBUILD) -b coverage $(ALLSPHINXOPTS) $(BUILDDIR)/coverage 206 | @echo "Testing of coverage in the sources finished, look at the " \ 207 | "results in $(BUILDDIR)/coverage/python.txt." 208 | 209 | .PHONY: xml 210 | xml: 211 | $(SPHINXBUILD) -b xml $(ALLSPHINXOPTS) $(BUILDDIR)/xml 212 | @echo 213 | @echo "Build finished. The XML files are in $(BUILDDIR)/xml." 214 | 215 | .PHONY: pseudoxml 216 | pseudoxml: 217 | $(SPHINXBUILD) -b pseudoxml $(ALLSPHINXOPTS) $(BUILDDIR)/pseudoxml 218 | @echo 219 | @echo "Build finished. The pseudo-XML files are in $(BUILDDIR)/pseudoxml." 220 | 221 | .PHONY: dummy 222 | dummy: 223 | $(SPHINXBUILD) -b dummy $(ALLSPHINXOPTS) $(BUILDDIR)/dummy 224 | @echo 225 | @echo "Build finished. Dummy builder generates no files." 226 | -------------------------------------------------------------------------------- /make.bat: -------------------------------------------------------------------------------- 1 | @ECHO OFF 2 | 3 | REM Command file for Sphinx documentation 4 | 5 | if "%SPHINXBUILD%" == "" ( 6 | set SPHINXBUILD=sphinx-build 7 | ) 8 | set BUILDDIR=_build 9 | set ALLSPHINXOPTS=-d %BUILDDIR%/doctrees %SPHINXOPTS% . 10 | set I18NSPHINXOPTS=%SPHINXOPTS% . 11 | if NOT "%PAPER%" == "" ( 12 | set ALLSPHINXOPTS=-D latex_paper_size=%PAPER% %ALLSPHINXOPTS% 13 | set I18NSPHINXOPTS=-D latex_paper_size=%PAPER% %I18NSPHINXOPTS% 14 | ) 15 | 16 | if "%1" == "" goto help 17 | 18 | if "%1" == "help" ( 19 | :help 20 | echo.Please use `make ^` where ^ is one of 21 | echo. html to make standalone HTML files 22 | echo. dirhtml to make HTML files named index.html in directories 23 | echo. singlehtml to make a single large HTML file 24 | echo. pickle to make pickle files 25 | echo. json to make JSON files 26 | echo. htmlhelp to make HTML files and a HTML help project 27 | echo. qthelp to make HTML files and a qthelp project 28 | echo. devhelp to make HTML files and a Devhelp project 29 | echo. epub to make an epub 30 | echo. epub3 to make an epub3 31 | echo. latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter 32 | echo. text to make text files 33 | echo. man to make manual pages 34 | echo. texinfo to make Texinfo files 35 | echo. gettext to make PO message catalogs 36 | echo. changes to make an overview over all changed/added/deprecated items 37 | echo. xml to make Docutils-native XML files 38 | echo. pseudoxml to make pseudoxml-XML files for display purposes 39 | echo. linkcheck to check all external links for integrity 40 | echo. doctest to run all doctests embedded in the documentation if enabled 41 | echo. coverage to run coverage check of the documentation if enabled 42 | echo. dummy to check syntax errors of document sources 43 | goto end 44 | ) 45 | 46 | if "%1" == "clean" ( 47 | for /d %%i in (%BUILDDIR%\*) do rmdir /q /s %%i 48 | del /q /s %BUILDDIR%\* 49 | goto end 50 | ) 51 | 52 | 53 | REM Check if sphinx-build is available and fallback to Python version if any 54 | %SPHINXBUILD% 1>NUL 2>NUL 55 | if errorlevel 9009 goto sphinx_python 56 | goto sphinx_ok 57 | 58 | :sphinx_python 59 | 60 | set SPHINXBUILD=python -m sphinx.__init__ 61 | %SPHINXBUILD% 2> nul 62 | if errorlevel 9009 ( 63 | echo. 64 | echo.The 'sphinx-build' command was not found. Make sure you have Sphinx 65 | echo.installed, then set the SPHINXBUILD environment variable to point 66 | echo.to the full path of the 'sphinx-build' executable. Alternatively you 67 | echo.may add the Sphinx directory to PATH. 68 | echo. 69 | echo.If you don't have Sphinx installed, grab it from 70 | echo.http://sphinx-doc.org/ 71 | exit /b 1 72 | ) 73 | 74 | :sphinx_ok 75 | 76 | 77 | if "%1" == "html" ( 78 | %SPHINXBUILD% -b html %ALLSPHINXOPTS% %BUILDDIR%/html 79 | if errorlevel 1 exit /b 1 80 | echo. 81 | echo.Build finished. The HTML pages are in %BUILDDIR%/html. 82 | goto end 83 | ) 84 | 85 | if "%1" == "dirhtml" ( 86 | %SPHINXBUILD% -b dirhtml %ALLSPHINXOPTS% %BUILDDIR%/dirhtml 87 | if errorlevel 1 exit /b 1 88 | echo. 89 | echo.Build finished. The HTML pages are in %BUILDDIR%/dirhtml. 90 | goto end 91 | ) 92 | 93 | if "%1" == "singlehtml" ( 94 | %SPHINXBUILD% -b singlehtml %ALLSPHINXOPTS% %BUILDDIR%/singlehtml 95 | if errorlevel 1 exit /b 1 96 | echo. 97 | echo.Build finished. The HTML pages are in %BUILDDIR%/singlehtml. 98 | goto end 99 | ) 100 | 101 | if "%1" == "pickle" ( 102 | %SPHINXBUILD% -b pickle %ALLSPHINXOPTS% %BUILDDIR%/pickle 103 | if errorlevel 1 exit /b 1 104 | echo. 105 | echo.Build finished; now you can process the pickle files. 106 | goto end 107 | ) 108 | 109 | if "%1" == "json" ( 110 | %SPHINXBUILD% -b json %ALLSPHINXOPTS% %BUILDDIR%/json 111 | if errorlevel 1 exit /b 1 112 | echo. 113 | echo.Build finished; now you can process the JSON files. 114 | goto end 115 | ) 116 | 117 | if "%1" == "htmlhelp" ( 118 | %SPHINXBUILD% -b htmlhelp %ALLSPHINXOPTS% %BUILDDIR%/htmlhelp 119 | if errorlevel 1 exit /b 1 120 | echo. 121 | echo.Build finished; now you can run HTML Help Workshop with the ^ 122 | .hhp project file in %BUILDDIR%/htmlhelp. 123 | goto end 124 | ) 125 | 126 | if "%1" == "qthelp" ( 127 | %SPHINXBUILD% -b qthelp %ALLSPHINXOPTS% %BUILDDIR%/qthelp 128 | if errorlevel 1 exit /b 1 129 | echo. 130 | echo.Build finished; now you can run "qcollectiongenerator" with the ^ 131 | .qhcp project file in %BUILDDIR%/qthelp, like this: 132 | echo.^> qcollectiongenerator %BUILDDIR%\qthelp\ThePenetrationTestingExecutionStandard.qhcp 133 | echo.To view the help file: 134 | echo.^> assistant -collectionFile %BUILDDIR%\qthelp\ThePenetrationTestingExecutionStandard.ghc 135 | goto end 136 | ) 137 | 138 | if "%1" == "devhelp" ( 139 | %SPHINXBUILD% -b devhelp %ALLSPHINXOPTS% %BUILDDIR%/devhelp 140 | if errorlevel 1 exit /b 1 141 | echo. 142 | echo.Build finished. 143 | goto end 144 | ) 145 | 146 | if "%1" == "epub" ( 147 | %SPHINXBUILD% -b epub %ALLSPHINXOPTS% %BUILDDIR%/epub 148 | if errorlevel 1 exit /b 1 149 | echo. 150 | echo.Build finished. The epub file is in %BUILDDIR%/epub. 151 | goto end 152 | ) 153 | 154 | if "%1" == "epub3" ( 155 | %SPHINXBUILD% -b epub3 %ALLSPHINXOPTS% %BUILDDIR%/epub3 156 | if errorlevel 1 exit /b 1 157 | echo. 158 | echo.Build finished. The epub3 file is in %BUILDDIR%/epub3. 159 | goto end 160 | ) 161 | 162 | if "%1" == "latex" ( 163 | %SPHINXBUILD% -b latex %ALLSPHINXOPTS% %BUILDDIR%/latex 164 | if errorlevel 1 exit /b 1 165 | echo. 166 | echo.Build finished; the LaTeX files are in %BUILDDIR%/latex. 167 | goto end 168 | ) 169 | 170 | if "%1" == "latexpdf" ( 171 | %SPHINXBUILD% -b latex %ALLSPHINXOPTS% %BUILDDIR%/latex 172 | cd %BUILDDIR%/latex 173 | make all-pdf 174 | cd %~dp0 175 | echo. 176 | echo.Build finished; the PDF files are in %BUILDDIR%/latex. 177 | goto end 178 | ) 179 | 180 | if "%1" == "latexpdfja" ( 181 | %SPHINXBUILD% -b latex %ALLSPHINXOPTS% %BUILDDIR%/latex 182 | cd %BUILDDIR%/latex 183 | make all-pdf-ja 184 | cd %~dp0 185 | echo. 186 | echo.Build finished; the PDF files are in %BUILDDIR%/latex. 187 | goto end 188 | ) 189 | 190 | if "%1" == "text" ( 191 | %SPHINXBUILD% -b text %ALLSPHINXOPTS% %BUILDDIR%/text 192 | if errorlevel 1 exit /b 1 193 | echo. 194 | echo.Build finished. The text files are in %BUILDDIR%/text. 195 | goto end 196 | ) 197 | 198 | if "%1" == "man" ( 199 | %SPHINXBUILD% -b man %ALLSPHINXOPTS% %BUILDDIR%/man 200 | if errorlevel 1 exit /b 1 201 | echo. 202 | echo.Build finished. The manual pages are in %BUILDDIR%/man. 203 | goto end 204 | ) 205 | 206 | if "%1" == "texinfo" ( 207 | %SPHINXBUILD% -b texinfo %ALLSPHINXOPTS% %BUILDDIR%/texinfo 208 | if errorlevel 1 exit /b 1 209 | echo. 210 | echo.Build finished. The Texinfo files are in %BUILDDIR%/texinfo. 211 | goto end 212 | ) 213 | 214 | if "%1" == "gettext" ( 215 | %SPHINXBUILD% -b gettext %I18NSPHINXOPTS% %BUILDDIR%/locale 216 | if errorlevel 1 exit /b 1 217 | echo. 218 | echo.Build finished. The message catalogs are in %BUILDDIR%/locale. 219 | goto end 220 | ) 221 | 222 | if "%1" == "changes" ( 223 | %SPHINXBUILD% -b changes %ALLSPHINXOPTS% %BUILDDIR%/changes 224 | if errorlevel 1 exit /b 1 225 | echo. 226 | echo.The overview file is in %BUILDDIR%/changes. 227 | goto end 228 | ) 229 | 230 | if "%1" == "linkcheck" ( 231 | %SPHINXBUILD% -b linkcheck %ALLSPHINXOPTS% %BUILDDIR%/linkcheck 232 | if errorlevel 1 exit /b 1 233 | echo. 234 | echo.Link check complete; look for any errors in the above output ^ 235 | or in %BUILDDIR%/linkcheck/output.txt. 236 | goto end 237 | ) 238 | 239 | if "%1" == "doctest" ( 240 | %SPHINXBUILD% -b doctest %ALLSPHINXOPTS% %BUILDDIR%/doctest 241 | if errorlevel 1 exit /b 1 242 | echo. 243 | echo.Testing of doctests in the sources finished, look at the ^ 244 | results in %BUILDDIR%/doctest/output.txt. 245 | goto end 246 | ) 247 | 248 | if "%1" == "coverage" ( 249 | %SPHINXBUILD% -b coverage %ALLSPHINXOPTS% %BUILDDIR%/coverage 250 | if errorlevel 1 exit /b 1 251 | echo. 252 | echo.Testing of coverage in the sources finished, look at the ^ 253 | results in %BUILDDIR%/coverage/python.txt. 254 | goto end 255 | ) 256 | 257 | if "%1" == "xml" ( 258 | %SPHINXBUILD% -b xml %ALLSPHINXOPTS% %BUILDDIR%/xml 259 | if errorlevel 1 exit /b 1 260 | echo. 261 | echo.Build finished. The XML files are in %BUILDDIR%/xml. 262 | goto end 263 | ) 264 | 265 | if "%1" == "pseudoxml" ( 266 | %SPHINXBUILD% -b pseudoxml %ALLSPHINXOPTS% %BUILDDIR%/pseudoxml 267 | if errorlevel 1 exit /b 1 268 | echo. 269 | echo.Build finished. The pseudo-XML files are in %BUILDDIR%/pseudoxml. 270 | goto end 271 | ) 272 | 273 | if "%1" == "dummy" ( 274 | %SPHINXBUILD% -b dummy %ALLSPHINXOPTS% %BUILDDIR%/dummy 275 | if errorlevel 1 exit /b 1 276 | echo. 277 | echo.Build finished. Dummy builder generates no files. 278 | goto end 279 | ) 280 | 281 | :end 282 | -------------------------------------------------------------------------------- /_build/html/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | The Penetration Testing Execution Standard — pentest-standard 1.1 documentation 8 | 9 | 10 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 63 | 64 |
68 | 69 |
70 |
71 |
72 |
    73 |
  • »
  • 74 |
  • The Penetration Testing Execution Standard
  • 75 |
  • 76 | View page source 77 |
  • 78 |
79 |
80 |
81 |
82 |
83 | 84 |
85 |

The Penetration Testing Execution Standard

86 |
87 |

High Level Organization of the Standard

88 |

Fork Disclaimer: Note that this is an unofficial fork, the goal for which is to experiment with an alternative platform for the standard. The official PTES can be located at http://pentest-standard.org/.

89 |

The penetration testing execution standard consists of seven (7) main 90 | sections. These cover everything related to a penetration test - from 91 | the initial communication and reasoning behind a pentest, through the 92 | intelligence gathering and threat modeling phases where testers are 93 | working behind the scenes in order to get a better understanding of the 94 | tested organization, through vulnerability research, exploitation and 95 | post exploitation, where the technical security expertise of the testers 96 | come to play and combine with the business understanding of the 97 | engagement, and finally to the reporting, which captures the entire 98 | process, in a manner that makes sense to the customer and provides the 99 | most value to it.

100 |

This version can be considered a v1.0 as the core elements of the 101 | standard are solidified, and have been “road tested” for over a year 102 | through the industry. A v2.0 is in the works soon, and will provide more 103 | granular work in terms of “levels” - as in intensity levels at which 104 | each of the elements of a penetration test can be performed at. As no 105 | pentest is like another, and testing will range from the more mundane 106 | web application or network test, to a full-on red team engagement, said 107 | levels will enable an organization to define how much sophistication 108 | they expect their adversary to exhibit, and enable the tester to step up 109 | the intensity on those areas where the organization needs them the most. 110 | Some of the initial work on “levels” can be seen in the intelligence 111 | gathering section.

112 |

Following are the main sections defined by the standard as the basis for 113 | penetration testing execution:

114 |
    115 |
  1. Pre-engagement Interactions

  2. 116 |
  3. Intelligence Gathering

  4. 117 |
  5. Threat Modeling

  6. 118 |
  7. Vulnerability Analysis

  8. 119 |
  9. Exploitation

  10. 120 |
  11. Post Exploitation

  12. 121 |
  13. Reporting

  14. 122 |
123 |

As the standard does not provide any technical guidelines as far as how 124 | to execute an actual pentest, we have also created a technical guide to 125 | accompany the standard itself. The technical gude can be reached via the 126 | link below:

127 | 130 |

For more information on what this standard is, please visit:

131 |
    132 |
  • FAQ

  • 133 |
134 |
135 |
136 | 137 | 138 |
139 |
140 |
144 | 145 |
146 | 147 |
148 |

© Copyright 2016, The PTES Team.

149 |
150 | 151 | Built with Sphinx using a 152 | theme 153 | provided by Read the Docs. 154 | 155 | 156 |
157 |
158 |
159 |
160 |
161 | 166 | 167 | 168 | -------------------------------------------------------------------------------- /_build/html/_static/doctools.js: -------------------------------------------------------------------------------- 1 | /* 2 | * doctools.js 3 | * ~~~~~~~~~~~ 4 | * 5 | * Sphinx JavaScript utilities for all documentation. 6 | * 7 | * :copyright: Copyright 2007-2021 by the Sphinx team, see AUTHORS. 8 | * :license: BSD, see LICENSE for details. 9 | * 10 | */ 11 | 12 | /** 13 | * select a different prefix for underscore 14 | */ 15 | $u = _.noConflict(); 16 | 17 | /** 18 | * make the code below compatible with browsers without 19 | * an installed firebug like debugger 20 | if (!window.console || !console.firebug) { 21 | var names = ["log", "debug", "info", "warn", "error", "assert", "dir", 22 | "dirxml", "group", "groupEnd", "time", "timeEnd", "count", "trace", 23 | "profile", "profileEnd"]; 24 | window.console = {}; 25 | for (var i = 0; i < names.length; ++i) 26 | window.console[names[i]] = function() {}; 27 | } 28 | */ 29 | 30 | /** 31 | * small helper function to urldecode strings 32 | * 33 | * See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/decodeURIComponent#Decoding_query_parameters_from_a_URL 34 | */ 35 | jQuery.urldecode = function(x) { 36 | if (!x) { 37 | return x 38 | } 39 | return decodeURIComponent(x.replace(/\+/g, ' ')); 40 | }; 41 | 42 | /** 43 | * small helper function to urlencode strings 44 | */ 45 | jQuery.urlencode = encodeURIComponent; 46 | 47 | /** 48 | * This function returns the parsed url parameters of the 49 | * current request. Multiple values per key are supported, 50 | * it will always return arrays of strings for the value parts. 51 | */ 52 | jQuery.getQueryParameters = function(s) { 53 | if (typeof s === 'undefined') 54 | s = document.location.search; 55 | var parts = s.substr(s.indexOf('?') + 1).split('&'); 56 | var result = {}; 57 | for (var i = 0; i < parts.length; i++) { 58 | var tmp = parts[i].split('=', 2); 59 | var key = jQuery.urldecode(tmp[0]); 60 | var value = jQuery.urldecode(tmp[1]); 61 | if (key in result) 62 | result[key].push(value); 63 | else 64 | result[key] = [value]; 65 | } 66 | return result; 67 | }; 68 | 69 | /** 70 | * highlight a given string on a jquery object by wrapping it in 71 | * span elements with the given class name. 72 | */ 73 | jQuery.fn.highlightText = function(text, className) { 74 | function highlight(node, addItems) { 75 | if (node.nodeType === 3) { 76 | var val = node.nodeValue; 77 | var pos = val.toLowerCase().indexOf(text); 78 | if (pos >= 0 && 79 | !jQuery(node.parentNode).hasClass(className) && 80 | !jQuery(node.parentNode).hasClass("nohighlight")) { 81 | var span; 82 | var isInSVG = jQuery(node).closest("body, svg, foreignObject").is("svg"); 83 | if (isInSVG) { 84 | span = document.createElementNS("http://www.w3.org/2000/svg", "tspan"); 85 | } else { 86 | span = document.createElement("span"); 87 | span.className = className; 88 | } 89 | span.appendChild(document.createTextNode(val.substr(pos, text.length))); 90 | node.parentNode.insertBefore(span, node.parentNode.insertBefore( 91 | document.createTextNode(val.substr(pos + text.length)), 92 | node.nextSibling)); 93 | node.nodeValue = val.substr(0, pos); 94 | if (isInSVG) { 95 | var rect = document.createElementNS("http://www.w3.org/2000/svg", "rect"); 96 | var bbox = node.parentElement.getBBox(); 97 | rect.x.baseVal.value = bbox.x; 98 | rect.y.baseVal.value = bbox.y; 99 | rect.width.baseVal.value = bbox.width; 100 | rect.height.baseVal.value = bbox.height; 101 | rect.setAttribute('class', className); 102 | addItems.push({ 103 | "parent": node.parentNode, 104 | "target": rect}); 105 | } 106 | } 107 | } 108 | else if (!jQuery(node).is("button, select, textarea")) { 109 | jQuery.each(node.childNodes, function() { 110 | highlight(this, addItems); 111 | }); 112 | } 113 | } 114 | var addItems = []; 115 | var result = this.each(function() { 116 | highlight(this, addItems); 117 | }); 118 | for (var i = 0; i < addItems.length; ++i) { 119 | jQuery(addItems[i].parent).before(addItems[i].target); 120 | } 121 | return result; 122 | }; 123 | 124 | /* 125 | * backward compatibility for jQuery.browser 126 | * This will be supported until firefox bug is fixed. 127 | */ 128 | if (!jQuery.browser) { 129 | jQuery.uaMatch = function(ua) { 130 | ua = ua.toLowerCase(); 131 | 132 | var match = /(chrome)[ \/]([\w.]+)/.exec(ua) || 133 | /(webkit)[ \/]([\w.]+)/.exec(ua) || 134 | /(opera)(?:.*version|)[ \/]([\w.]+)/.exec(ua) || 135 | /(msie) ([\w.]+)/.exec(ua) || 136 | ua.indexOf("compatible") < 0 && /(mozilla)(?:.*? rv:([\w.]+)|)/.exec(ua) || 137 | []; 138 | 139 | return { 140 | browser: match[ 1 ] || "", 141 | version: match[ 2 ] || "0" 142 | }; 143 | }; 144 | jQuery.browser = {}; 145 | jQuery.browser[jQuery.uaMatch(navigator.userAgent).browser] = true; 146 | } 147 | 148 | /** 149 | * Small JavaScript module for the documentation. 150 | */ 151 | var Documentation = { 152 | 153 | init : function() { 154 | this.fixFirefoxAnchorBug(); 155 | this.highlightSearchWords(); 156 | this.initIndexTable(); 157 | if (DOCUMENTATION_OPTIONS.NAVIGATION_WITH_KEYS) { 158 | this.initOnKeyListeners(); 159 | } 160 | }, 161 | 162 | /** 163 | * i18n support 164 | */ 165 | TRANSLATIONS : {}, 166 | PLURAL_EXPR : function(n) { return n === 1 ? 0 : 1; }, 167 | LOCALE : 'unknown', 168 | 169 | // gettext and ngettext don't access this so that the functions 170 | // can safely bound to a different name (_ = Documentation.gettext) 171 | gettext : function(string) { 172 | var translated = Documentation.TRANSLATIONS[string]; 173 | if (typeof translated === 'undefined') 174 | return string; 175 | return (typeof translated === 'string') ? translated : translated[0]; 176 | }, 177 | 178 | ngettext : function(singular, plural, n) { 179 | var translated = Documentation.TRANSLATIONS[singular]; 180 | if (typeof translated === 'undefined') 181 | return (n == 1) ? singular : plural; 182 | return translated[Documentation.PLURALEXPR(n)]; 183 | }, 184 | 185 | addTranslations : function(catalog) { 186 | for (var key in catalog.messages) 187 | this.TRANSLATIONS[key] = catalog.messages[key]; 188 | this.PLURAL_EXPR = new Function('n', 'return +(' + catalog.plural_expr + ')'); 189 | this.LOCALE = catalog.locale; 190 | }, 191 | 192 | /** 193 | * add context elements like header anchor links 194 | */ 195 | addContextElements : function() { 196 | $('div[id] > :header:first').each(function() { 197 | $('\u00B6'). 198 | attr('href', '#' + this.id). 199 | attr('title', _('Permalink to this headline')). 200 | appendTo(this); 201 | }); 202 | $('dt[id]').each(function() { 203 | $('\u00B6'). 204 | attr('href', '#' + this.id). 205 | attr('title', _('Permalink to this definition')). 206 | appendTo(this); 207 | }); 208 | }, 209 | 210 | /** 211 | * workaround a firefox stupidity 212 | * see: https://bugzilla.mozilla.org/show_bug.cgi?id=645075 213 | */ 214 | fixFirefoxAnchorBug : function() { 215 | if (document.location.hash && $.browser.mozilla) 216 | window.setTimeout(function() { 217 | document.location.href += ''; 218 | }, 10); 219 | }, 220 | 221 | /** 222 | * highlight the search words provided in the url in the text 223 | */ 224 | highlightSearchWords : function() { 225 | var params = $.getQueryParameters(); 226 | var terms = (params.highlight) ? params.highlight[0].split(/\s+/) : []; 227 | if (terms.length) { 228 | var body = $('div.body'); 229 | if (!body.length) { 230 | body = $('body'); 231 | } 232 | window.setTimeout(function() { 233 | $.each(terms, function() { 234 | body.highlightText(this.toLowerCase(), 'highlighted'); 235 | }); 236 | }, 10); 237 | $('') 239 | .appendTo($('#searchbox')); 240 | } 241 | }, 242 | 243 | /** 244 | * init the domain index toggle buttons 245 | */ 246 | initIndexTable : function() { 247 | var togglers = $('img.toggler').click(function() { 248 | var src = $(this).attr('src'); 249 | var idnum = $(this).attr('id').substr(7); 250 | $('tr.cg-' + idnum).toggle(); 251 | if (src.substr(-9) === 'minus.png') 252 | $(this).attr('src', src.substr(0, src.length-9) + 'plus.png'); 253 | else 254 | $(this).attr('src', src.substr(0, src.length-8) + 'minus.png'); 255 | }).css('display', ''); 256 | if (DOCUMENTATION_OPTIONS.COLLAPSE_INDEX) { 257 | togglers.click(); 258 | } 259 | }, 260 | 261 | /** 262 | * helper function to hide the search marks again 263 | */ 264 | hideSearchWords : function() { 265 | $('#searchbox .highlight-link').fadeOut(300); 266 | $('span.highlighted').removeClass('highlighted'); 267 | }, 268 | 269 | /** 270 | * make the url absolute 271 | */ 272 | makeURL : function(relativeURL) { 273 | return DOCUMENTATION_OPTIONS.URL_ROOT + '/' + relativeURL; 274 | }, 275 | 276 | /** 277 | * get the current relative url 278 | */ 279 | getCurrentURL : function() { 280 | var path = document.location.pathname; 281 | var parts = path.split(/\//); 282 | $.each(DOCUMENTATION_OPTIONS.URL_ROOT.split(/\//), function() { 283 | if (this === '..') 284 | parts.pop(); 285 | }); 286 | var url = parts.join('/'); 287 | return path.substring(url.lastIndexOf('/') + 1, path.length - 1); 288 | }, 289 | 290 | initOnKeyListeners: function() { 291 | $(document).keydown(function(event) { 292 | var activeElementType = document.activeElement.tagName; 293 | // don't navigate when in search box, textarea, dropdown or button 294 | if (activeElementType !== 'TEXTAREA' && activeElementType !== 'INPUT' && activeElementType !== 'SELECT' 295 | && activeElementType !== 'BUTTON' && !event.altKey && !event.ctrlKey && !event.metaKey 296 | && !event.shiftKey) { 297 | switch (event.keyCode) { 298 | case 37: // left 299 | var prevHref = $('link[rel="prev"]').prop('href'); 300 | if (prevHref) { 301 | window.location.href = prevHref; 302 | return false; 303 | } 304 | case 39: // right 305 | var nextHref = $('link[rel="next"]').prop('href'); 306 | if (nextHref) { 307 | window.location.href = nextHref; 308 | return false; 309 | } 310 | } 311 | } 312 | }); 313 | } 314 | }; 315 | 316 | // quick alias for translations 317 | _ = Documentation.gettext; 318 | 319 | $(document).ready(function() { 320 | Documentation.init(); 321 | }); 322 | -------------------------------------------------------------------------------- /source/Reporting: -------------------------------------------------------------------------------- 1 | == Overview == 2 | 3 | This document is intended to define the base criteria for penetration testing reporting. While it is highly encouraged to use your own customized and branded format, the following should provide a high level understanding of the items required within a report as 4 | well as a structure for the report to provide value to the reader. 5 | 6 | == Report Structure == 7 | 8 | The report is broken down into two (2) major sections in order to communicate the objectives, methods, and results of the testing conducted to various audiences. 9 | 10 | == The Executive Summary == 11 | 12 | This section will communicate to the reader the specific goals of the Penetration Test and the high level findings of the testing exercise. The intended audience will be those who are in charge of the oversight and strategic vision of the security program as well as any members of the organization which may be impacted by the identified/confirmed threats. The executive summary should contain most if not all of the following sections: 13 | 14 | '''Background:''' 15 | 16 | The background section should explain to the reader the overall purpose of the test. Details on the terms identified within the Pre Engagement section relating to risk, countermeasures, and testing goals should be present to connect the reader to the overall test objectives and the relative results. 17 | 18 | (Example: (CLIENT) tasked with performing an internal/external vulnerability assessment and penetration testing of specific systems located in (logical area or physical location). These systems have been identified as (risk ranking) and contain (data classification level) data which, if accessed inappropriately, could cause material harm to (Client). In an effort to test (CLIENT’s) ability to defend against direct and indirect attack, executed a comprehensive network vulnerability scan, Vulnerability conformation( <-insert attack types agreed upon->) exploitation of weakened services, client side attacks, browser side attacks (etc) The purpose of this assessment was to verify the effectiveness of the security controls put in place by (CLIENT) to secure business-critical information. This report represents the findings from the assessment and the associated remediation recommendations to help CLIENT strengthen its security posture. 19 | 20 | * If objectives were changed during the course of the testing then all changes must be listed in this section of the report. Additionally, the letter of amendment should be included in the appendix of the report and linked to from this section. 21 | 22 | '''Overall Posture:''' 23 | 24 | This area will be a narrative of the overall effectiveness of the test and the pentesters ability to achieve the goals set forth within the pre engagement sessions. A brief description of the Systemic (ex. Systemic issue= Lacking Effective Patch Management Process vs. Symptomatic= Found MS08-067 missing on xyz box) issues identified through the testing process as well as the ability to achieve access to the goal information and identify a potential impact to the business. 25 | 26 | '''Risk Ranking/Profile:''' 27 | 28 | The overall risk ranking/profile/score will be identified and explained in this area. In the pre engagement section the Pentester will identify the scoring mechanism and the individual mechanism for tracking/grading risk. Various methods from FAIR, DREAD, and other custom rankings will be consolidated into environmental scores and defined. 29 | 30 | [[image:reporting-risk-scale.png]] 31 | 32 | The “Overall Risk Score” for the (CLIENT) is currently a Seven (7). This rating implies an ELEVATED risk of security controls being compromised with the potential for material financial losses. The consultant determined this risk score based on one high risk and several medium risk vulnerabilities, along with the success of directed attack. The most severe vulnerability identified was the presence of default passwords in the corporate public facing website which allowed access to a number of sensitive documents and the ability to control content on the device. This vulnerability could lead to theft of user accounts, leakage of sensitive information, or full system compromise. Several lesser severe vulnerabilities could lead to theft of valid account credentials and leakage of information. 33 | 34 | '''General Findings:''' 35 | 36 | The general findings will provide a synopsis of the issues found during the penetration test in a basic and statistical format. Graphic representations of the targets tested, testing results, processes, attack scenarios, success rates, and other trendable metrics as defined within the pre engagement meeting should be present. In addition, the cause of the issues should be presented in an easy to read format. (ex. A graph showing the root cause of issues exploited) 37 | 38 | [[image:risk-origin.png]] 39 | 40 | If defined within the Pre engagement exercise, this area should also include metrics which depict the effectiveness of the countermeasures within the environment. (ex.. we ran x attacks and IPS blocked y. Other countermeasures should also have similar metrics of design vs. effectiveness.) 41 | 42 | '''Recommendation Summary:''' 43 | 44 | The recommendation section of the report should provide the reader with a high level understanding of the tasks needed to resolve the risks identified and the general level of effort required to implement the resolution path suggested. This section will also identify the weighting mechanisms used to prioritize the order of the road map following. 45 | 46 | '''Strategic Roadmap:''' 47 | 48 | Roadmaps should include a prioritized plan for remediation of the insecure items found and should be weighed against the business objectives/ level of potential impact. This section should map directly to the goals identified as well as the threat matrix created in the PTES-Threat modeling section. By breaking up into predefined time/objective based goals, this section will create a path of action to follow in various increments. Example: 49 | 50 | [[image:roadmap1.png]] 51 | 52 | [[image:roadmap2.png]] 53 | 54 | [[image:roadmap3.png]] 55 | 56 | == Technical Report == 57 | 58 | This section will communicate to the reader the technical details of the test and all of the aspects/components agreed upon as key success indicators within the pre engagement exercise. The technical report section will describe in detail the scope, information, attack path, impact and remediation suggestions of the test. 59 | 60 | '''Introduction:''' 61 | 62 | The introduction section of the technical report is intended to be an initial inventory of: 63 | *Personnel involved in the testing from both the Client and Penetration Testing Team 64 | *Contact information 65 | *Assets involved in testing 66 | *Objectives of Test 67 | *Scope of Test 68 | *Strength of Test 69 | *Approach 70 | *Threat/Grading Structure 71 | 72 | This section should be a reference for the specific resources involved in the testing and the overall technical scope of the test. 73 | 74 | '''Information Gathering:''' 75 | 76 | Intelligence gathering and information assessment are the foundations of a good penetration test. The more informed the tester is about the environment, the better the results of the test will be. In this section, a number of items should be written up to show the CLIENT the extent of public and private information available through the execution of the Intelligence gathering phase of PTES. At a minimum, the results identified should be presented in 4 basic categories: 77 | 78 | '''Passive Intelligence:''' 79 | 80 | Intelligence gathered from indirect analysis such as DNS,Google dorking for IP/infrastructure related information. This section will focus on the techniques used to profile the technology in the CLIENT environment WITHOUT sending any traffic directly to the assets. 81 | 82 | '''Active Intelligence:''' 83 | 84 | This section will show the methods and results of tasks such as infrastructure mapping, port scanning, and architecture assessment and other foot printing activities. This section will focus on the techniques used to profile the technology in the CLIENT environment by sending traffic DIRECTLY to the assets. 85 | 86 | '''Corporate Intelligence:''' 87 | 88 | Information about the structure of the organization, business units, market share, vertical, and other corporate functions should be mapped to both business process and the previously identified physical assets being tested. 89 | 90 | '''Personnel Intelligence:''' 91 | 92 | Any and all information found during the intelligence collection phase which maps users to the CLIENT organization. This section should show the techniques used to harvest intelligence such as public/private employee depots, mail repositories, org charts and other items leading to the connection of employee/company. 93 | 94 | '''Vulnerability Assessment:''' 95 | 96 | Vulnerability assessment is the act of identifying the POTENTIAL vulnerabilities which exist in a TEST and the threat classification of each threat. In this section, a definition of the methods used to identify the vulnerability as well as the evidence/classification of the vulnerability should be present. In addition this section should include: 97 | 98 | *Vulnerability Classification Levels 99 | *Technical Vulnerabilities 100 | **OSI Layer Vulns 101 | **Scanner Found 102 | **Manually identified 103 | **Overall Exposure 104 | *Logical Vulnerabilities 105 | **NON OSI Vuln 106 | **Type of vuln 107 | **How/Where it is found 108 | **Exposure 109 | *Summary of Results 110 | 111 | '''Exploitation/ Vulnerability Confirmation:''' 112 | 113 | Exploitation or Vulnerability confirmation is the act of triggering the vulnerabilities identified in the previous sections to gain a specified level of access to the target asset. This section should review, in detail, all of the steps taken to confirm the defined vulnerability as well as the following: 114 | 115 | *Exploitation Timeline 116 | *Targets selected for Exploitation 117 | *Exploitation Activities 118 | **Directed Attack 119 | ***Target Hosts unable to be Exploited 120 | ***Target Hosts able to be Exploited 121 | ****Individual Host Information 122 | ****Attacks conducted 123 | ****Attacks Successful 124 | ****Level of access Granted +escalation path 125 | ****Remediation 126 | *****Link to Vuln section reference 127 | *****Additional Mitigating technique 128 | *****Compensating control suggestion 129 | *Indirect Attack 130 | **Phishing 131 | ***Timeline/details of attack 132 | ***Targets identified 133 | ***Success/Fail ratio 134 | ***Level of access granted 135 | **Clientside 136 | ***Timeline/details of attack 137 | ***Targets identified 138 | ***Success/Fail ratio 139 | ***Level of access granted 140 | **Browser Side 141 | ***Timeline/details of attack 142 | ***Targets identified 143 | ***Success/Fail ratio 144 | ***Level of access granted 145 | 146 | '''Post Exploitation:''' 147 | 148 | One of the most critical items in all testing is the connection to ACTUAL impact on the CLIENT being tested. While the sections above relay the technical nature of the vulnerability and the ability to successfully take advantage of the flaw, the Post Exploitation section should tie the ability of exploitation to the actual risk to the business. In this area the following items should be evidenced through the use of screenshots, rich content retrieval, and examples of real world privileged user access: 149 | 150 | *Privilege Escalation path 151 | **Technique used 152 | *Acquisition of Critical Information Defined by client 153 | *Value of information 154 | *Access to core business systems 155 | *Access to compliance protected data sets 156 | *Additional Information/Systems Accessed 157 | *Ability of persistence 158 | *Ability for exfiltration 159 | *Countermeasure Effectiveness 160 | *: This section should cover the effectiveness of countermeasures that are in place on the systems in scope. It should include sections on both active (proactive) and passive (reactive) countermeasures, as well as detailed information on any incident response activities triggered during the testing phase. A listing of countermeasures that were effective in resisting assessment activities will help the CLIENT better tune detection systems and processes to handle future intrusion attempts. 161 | **Detection Capability 162 | ***FW/WAF/IDS/IPS 163 | ***Human 164 | ***DLP 165 | ***Log 166 | **Response & effectiveness 167 | 168 | '''Risk/Exposure:''' 169 | 170 | Once the direct impact to the business is qualified through the evidence existing in the vulnerability, exploitation and post exploitation sections, the risk quantification can be conducted. In this section the results above are combined with the risk values, information criticality, corporate valuation, and derived business impact from the pre engagement section. This will give the CLIENT the ability to identify, visualize and monetize the vulnerabilities found throughout the testing and effectively weight their resolution against the CLIENTS business objectives. This section will cover the business risk in the following subsections: 171 | 172 | *Evaluate incident frequency 173 | **probable event frequency 174 | **estimate threat capability (from 3 - threat modeling) 175 | **Estimate controls strength (6) 176 | **Compound vulnerability (5) 177 | **Level of skill required 178 | **Level of access required 179 | *Estimate loss magnitude per incident 180 | **Primary loss 181 | **Secondary loss 182 | **Identify risk root cause analysis 183 | ***Root Cause is never a patch 184 | ***Identify Failed Processes 185 | *Derive Risk 186 | **Threat 187 | **Vulnerability 188 | **Overlap 189 | 190 | '''Conclusion:''' 191 | 192 | Final overview of the test. It is suggested that this section echo portions of the overall test as well as support the growth of the CLIENT security posture. It should end on a positive note with the support and guidance to enable progress in the security program and a regimen of testing/security activity in the future to come. 193 | 194 | -------------------------------------------------------------------------------- /_build/html/_static/alabaster.css: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | @import url("basic.css"); 54 | 55 | /* -- page layout ----------------------------------------------------------- */ 56 | 57 | body { 58 | font-family: 'goudy old style', 'minion pro', 'bell mt', Georgia, 'Hiragino Mincho Pro', serif; 59 | font-size: 17px; 60 | background-color: #fff; 61 | color: #000; 62 | margin: 0; 63 | padding: 0; 64 | } 65 | 66 | 67 | div.document { 68 | width: 940px; 69 | margin: 30px auto 0 auto; 70 | } 71 | 72 | div.documentwrapper { 73 | float: left; 74 | width: 100%; 75 | } 76 | 77 | div.bodywrapper { 78 | margin: 0 0 0 220px; 79 | } 80 | 81 | div.sphinxsidebar { 82 | width: 220px; 83 | font-size: 14px; 84 | line-height: 1.5; 85 | } 86 | 87 | hr { 88 | border: 1px solid #B1B4B6; 89 | } 90 | 91 | div.body { 92 | background-color: #fff; 93 | color: #3E4349; 94 | padding: 0 30px 0 30px; 95 | } 96 | 97 | div.body > .section { 98 | text-align: left; 99 | } 100 | 101 | div.footer { 102 | width: 940px; 103 | margin: 20px auto 30px auto; 104 | font-size: 14px; 105 | color: #888; 106 | text-align: right; 107 | } 108 | 109 | div.footer a { 110 | color: #888; 111 | } 112 | 113 | p.caption { 114 | font-family: inherit; 115 | font-size: inherit; 116 | } 117 | 118 | 119 | div.relations { 120 | display: none; 121 | } 122 | 123 | 124 | div.sphinxsidebar a { 125 | color: #444; 126 | text-decoration: none; 127 | border-bottom: 1px dotted #999; 128 | } 129 | 130 | div.sphinxsidebar a:hover { 131 | border-bottom: 1px solid #999; 132 | } 133 | 134 | div.sphinxsidebarwrapper { 135 | padding: 18px 10px; 136 | } 137 | 138 | div.sphinxsidebarwrapper p.logo { 139 | padding: 0; 140 | margin: -10px 0 0 0px; 141 | text-align: center; 142 | } 143 | 144 | div.sphinxsidebarwrapper h1.logo { 145 | margin-top: -10px; 146 | text-align: center; 147 | margin-bottom: 5px; 148 | text-align: left; 149 | } 150 | 151 | div.sphinxsidebarwrapper h1.logo-name { 152 | margin-top: 0px; 153 | } 154 | 155 | div.sphinxsidebarwrapper p.blurb { 156 | margin-top: 0; 157 | font-style: normal; 158 | } 159 | 160 | div.sphinxsidebar h3, 161 | div.sphinxsidebar h4 { 162 | font-family: 'Garamond', 'Georgia', serif; 163 | color: #444; 164 | font-size: 24px; 165 | font-weight: normal; 166 | margin: 0 0 5px 0; 167 | padding: 0; 168 | } 169 | 170 | div.sphinxsidebar h4 { 171 | font-size: 20px; 172 | } 173 | 174 | div.sphinxsidebar h3 a { 175 | color: #444; 176 | } 177 | 178 | div.sphinxsidebar p.logo a, 179 | div.sphinxsidebar h3 a, 180 | div.sphinxsidebar p.logo a:hover, 181 | div.sphinxsidebar h3 a:hover { 182 | border: none; 183 | } 184 | 185 | div.sphinxsidebar p { 186 | color: #555; 187 | margin: 10px 0; 188 | } 189 | 190 | div.sphinxsidebar ul { 191 | margin: 10px 0; 192 | padding: 0; 193 | color: #000; 194 | } 195 | 196 | div.sphinxsidebar ul li.toctree-l1 > a { 197 | font-size: 120%; 198 | } 199 | 200 | div.sphinxsidebar ul li.toctree-l2 > a { 201 | font-size: 110%; 202 | } 203 | 204 | div.sphinxsidebar input { 205 | border: 1px solid #CCC; 206 | font-family: 'goudy old style', 'minion pro', 'bell mt', Georgia, 'Hiragino Mincho Pro', serif; 207 | font-size: 1em; 208 | } 209 | 210 | div.sphinxsidebar hr { 211 | border: none; 212 | height: 1px; 213 | color: #AAA; 214 | background: #AAA; 215 | 216 | text-align: left; 217 | margin-left: 0; 218 | width: 50%; 219 | } 220 | 221 | /* -- body styles ----------------------------------------------------------- */ 222 | 223 | a { 224 | color: #004B6B; 225 | text-decoration: underline; 226 | } 227 | 228 | a:hover { 229 | color: #6D4100; 230 | text-decoration: underline; 231 | } 232 | 233 | div.body h1, 234 | div.body h2, 235 | div.body h3, 236 | div.body h4, 237 | div.body h5, 238 | div.body h6 { 239 | font-family: 'Garamond', 'Georgia', serif; 240 | font-weight: normal; 241 | margin: 30px 0px 10px 0px; 242 | padding: 0; 243 | } 244 | 245 | div.body h1 { margin-top: 0; padding-top: 0; font-size: 240%; } 246 | div.body h2 { font-size: 180%; } 247 | div.body h3 { font-size: 150%; } 248 | div.body h4 { font-size: 130%; } 249 | div.body h5 { font-size: 100%; } 250 | div.body h6 { font-size: 100%; } 251 | 252 | a.headerlink { 253 | color: #DDD; 254 | padding: 0 4px; 255 | text-decoration: none; 256 | } 257 | 258 | a.headerlink:hover { 259 | color: #444; 260 | background: #EAEAEA; 261 | } 262 | 263 | div.body p, div.body dd, div.body li { 264 | line-height: 1.4em; 265 | } 266 | 267 | div.admonition { 268 | margin: 20px 0px; 269 | padding: 10px 30px; 270 | background-color: #EEE; 271 | border: 1px solid #CCC; 272 | } 273 | 274 | div.admonition tt.xref, div.admonition code.xref, div.admonition a tt { 275 | background-color: ; 276 | border-bottom: 1px solid #fafafa; 277 | } 278 | 279 | dd div.admonition { 280 | margin-left: -60px; 281 | padding-left: 60px; 282 | } 283 | 284 | div.admonition p.admonition-title { 285 | font-family: 'Garamond', 'Georgia', serif; 286 | font-weight: normal; 287 | font-size: 24px; 288 | margin: 0 0 10px 0; 289 | padding: 0; 290 | line-height: 1; 291 | } 292 | 293 | div.admonition p.last { 294 | margin-bottom: 0; 295 | } 296 | 297 | div.highlight { 298 | background-color: #fff; 299 | } 300 | 301 | dt:target, .highlight { 302 | background: #FAF3E8; 303 | } 304 | 305 | div.warning { 306 | background-color: #FCC; 307 | border: 1px solid #FAA; 308 | } 309 | 310 | div.danger { 311 | background-color: #FCC; 312 | border: 1px solid #FAA; 313 | -moz-box-shadow: 2px 2px 4px #D52C2C; 314 | -webkit-box-shadow: 2px 2px 4px #D52C2C; 315 | box-shadow: 2px 2px 4px #D52C2C; 316 | } 317 | 318 | div.error { 319 | background-color: #FCC; 320 | border: 1px solid #FAA; 321 | -moz-box-shadow: 2px 2px 4px #D52C2C; 322 | -webkit-box-shadow: 2px 2px 4px #D52C2C; 323 | box-shadow: 2px 2px 4px #D52C2C; 324 | } 325 | 326 | div.caution { 327 | background-color: #FCC; 328 | border: 1px solid #FAA; 329 | } 330 | 331 | div.attention { 332 | background-color: #FCC; 333 | border: 1px solid #FAA; 334 | } 335 | 336 | div.important { 337 | background-color: #EEE; 338 | border: 1px solid #CCC; 339 | } 340 | 341 | div.note { 342 | background-color: #EEE; 343 | border: 1px solid #CCC; 344 | } 345 | 346 | div.tip { 347 | background-color: #EEE; 348 | border: 1px solid #CCC; 349 | } 350 | 351 | div.hint { 352 | background-color: #EEE; 353 | border: 1px solid #CCC; 354 | } 355 | 356 | div.seealso { 357 | background-color: #EEE; 358 | border: 1px solid #CCC; 359 | } 360 | 361 | div.topic { 362 | background-color: #EEE; 363 | } 364 | 365 | p.admonition-title { 366 | display: inline; 367 | } 368 | 369 | p.admonition-title:after { 370 | content: ":"; 371 | } 372 | 373 | pre, tt, code { 374 | font-family: 'Consolas', 'Menlo', 'Deja Vu Sans Mono', 'Bitstream Vera Sans Mono', monospace; 375 | font-size: 0.9em; 376 | } 377 | 378 | .hll { 379 | background-color: #FFC; 380 | margin: 0 -12px; 381 | padding: 0 12px; 382 | display: block; 383 | } 384 | 385 | img.screenshot { 386 | } 387 | 388 | tt.descname, tt.descclassname, code.descname, code.descclassname { 389 | font-size: 0.95em; 390 | } 391 | 392 | tt.descname, code.descname { 393 | padding-right: 0.08em; 394 | } 395 | 396 | img.screenshot { 397 | -moz-box-shadow: 2px 2px 4px #EEE; 398 | -webkit-box-shadow: 2px 2px 4px #EEE; 399 | box-shadow: 2px 2px 4px #EEE; 400 | } 401 | 402 | table.docutils { 403 | border: 1px solid #888; 404 | -moz-box-shadow: 2px 2px 4px #EEE; 405 | -webkit-box-shadow: 2px 2px 4px #EEE; 406 | box-shadow: 2px 2px 4px #EEE; 407 | } 408 | 409 | table.docutils td, table.docutils th { 410 | border: 1px solid #888; 411 | padding: 0.25em 0.7em; 412 | } 413 | 414 | table.field-list, table.footnote { 415 | border: none; 416 | -moz-box-shadow: none; 417 | -webkit-box-shadow: none; 418 | box-shadow: none; 419 | } 420 | 421 | table.footnote { 422 | margin: 15px 0; 423 | width: 100%; 424 | border: 1px solid #EEE; 425 | background: #FDFDFD; 426 | font-size: 0.9em; 427 | } 428 | 429 | table.footnote + table.footnote { 430 | margin-top: -15px; 431 | border-top: none; 432 | } 433 | 434 | table.field-list th { 435 | padding: 0 0.8em 0 0; 436 | } 437 | 438 | table.field-list td { 439 | padding: 0; 440 | } 441 | 442 | table.field-list p { 443 | margin-bottom: 0.8em; 444 | } 445 | 446 | table.footnote td.label { 447 | width: .1px; 448 | padding: 0.3em 0 0.3em 0.5em; 449 | } 450 | 451 | table.footnote td { 452 | padding: 0.3em 0.5em; 453 | } 454 | 455 | dl { 456 | margin: 0; 457 | padding: 0; 458 | } 459 | 460 | dl dd { 461 | margin-left: 30px; 462 | } 463 | 464 | blockquote { 465 | margin: 0 0 0 30px; 466 | padding: 0; 467 | } 468 | 469 | ul, ol { 470 | /* Matches the 30px from the narrow-screen "li > ul" selector below */ 471 | margin: 10px 0 10px 30px; 472 | padding: 0; 473 | } 474 | 475 | pre { 476 | background: #EEE; 477 | padding: 7px 30px; 478 | margin: 15px 0px; 479 | line-height: 1.3em; 480 | } 481 | 482 | div.viewcode-block:target { 483 | background: #ffd; 484 | } 485 | 486 | dl pre, blockquote pre, li pre { 487 | margin-left: 0; 488 | padding-left: 30px; 489 | } 490 | 491 | dl dl pre { 492 | margin-left: -90px; 493 | padding-left: 90px; 494 | } 495 | 496 | tt, code { 497 | background-color: #ecf0f3; 498 | color: #222; 499 | /* padding: 1px 2px; */ 500 | } 501 | 502 | tt.xref, code.xref, a tt { 503 | background-color: #FBFBFB; 504 | border-bottom: 1px solid #fff; 505 | } 506 | 507 | a.reference { 508 | text-decoration: none; 509 | border-bottom: 1px dotted #004B6B; 510 | } 511 | 512 | /* Don't put an underline on images */ 513 | a.image-reference, a.image-reference:hover { 514 | border-bottom: none; 515 | } 516 | 517 | a.reference:hover { 518 | border-bottom: 1px solid #6D4100; 519 | } 520 | 521 | a.footnote-reference { 522 | text-decoration: none; 523 | font-size: 0.7em; 524 | vertical-align: top; 525 | border-bottom: 1px dotted #004B6B; 526 | } 527 | 528 | a.footnote-reference:hover { 529 | border-bottom: 1px solid #6D4100; 530 | } 531 | 532 | a:hover tt, a:hover code { 533 | background: #EEE; 534 | } 535 | 536 | 537 | @media screen and (max-width: 870px) { 538 | 539 | div.sphinxsidebar { 540 | display: none; 541 | } 542 | 543 | div.document { 544 | width: 100%; 545 | 546 | } 547 | 548 | div.documentwrapper { 549 | margin-left: 0; 550 | margin-top: 0; 551 | margin-right: 0; 552 | margin-bottom: 0; 553 | } 554 | 555 | div.bodywrapper { 556 | margin-top: 0; 557 | margin-right: 0; 558 | margin-bottom: 0; 559 | margin-left: 0; 560 | } 561 | 562 | ul { 563 | margin-left: 0; 564 | } 565 | 566 | li > ul { 567 | /* Matches the 30px from the "ul, ol" selector above */ 568 | margin-left: 30px; 569 | } 570 | 571 | .document { 572 | width: auto; 573 | } 574 | 575 | .footer { 576 | width: auto; 577 | } 578 | 579 | .bodywrapper { 580 | margin: 0; 581 | } 582 | 583 | .footer { 584 | width: auto; 585 | } 586 | 587 | .github { 588 | display: none; 589 | } 590 | 591 | 592 | 593 | } 594 | 595 | 596 | 597 | @media screen and (max-width: 875px) { 598 | 599 | body { 600 | margin: 0; 601 | padding: 20px 30px; 602 | } 603 | 604 | div.documentwrapper { 605 | float: none; 606 | background: #fff; 607 | } 608 | 609 | div.sphinxsidebar { 610 | display: block; 611 | float: none; 612 | width: 102.5%; 613 | margin: 50px -30px -20px -30px; 614 | padding: 10px 20px; 615 | background: #333; 616 | color: #FFF; 617 | } 618 | 619 | div.sphinxsidebar h3, div.sphinxsidebar h4, div.sphinxsidebar p, 620 | div.sphinxsidebar h3 a { 621 | color: #fff; 622 | } 623 | 624 | div.sphinxsidebar a { 625 | color: #AAA; 626 | } 627 | 628 | div.sphinxsidebar p.logo { 629 | display: none; 630 | } 631 | 632 | div.document { 633 | width: 100%; 634 | margin: 0; 635 | } 636 | 637 | div.footer { 638 | display: none; 639 | } 640 | 641 | div.bodywrapper { 642 | margin: 0; 643 | } 644 | 645 | div.body { 646 | min-height: 0; 647 | padding: 0; 648 | } 649 | 650 | .rtd_doc_footer { 651 | display: none; 652 | } 653 | 654 | .document { 655 | width: auto; 656 | } 657 | 658 | .footer { 659 | width: auto; 660 | } 661 | 662 | .footer { 663 | width: auto; 664 | } 665 | 666 | .github { 667 | display: none; 668 | } 669 | } 670 | 671 | 672 | /* misc. */ 673 | 674 | .revsys-inline { 675 | display: none!important; 676 | } 677 | 678 | /* Make nested-list/multi-paragraph items look better in Releases changelog 679 | * pages. Without this, docutils' magical list fuckery causes inconsistent 680 | * formatting between different release sub-lists. 681 | */ 682 | div#changelog > div.section > ul > li > p:only-child { 683 | margin-bottom: 0; 684 | } 685 | 686 | /* Hide fugly table cell borders in ..bibliography:: directive output */ 687 | table.docutils.citation, table.docutils.citation td, table.docutils.citation th { 688 | border: none; 689 | /* Below needed in some edge cases; if not applied, bottom shadows appear */ 690 | -moz-box-shadow: none; 691 | -webkit-box-shadow: none; 692 | box-shadow: none; 693 | } -------------------------------------------------------------------------------- /conf.py: -------------------------------------------------------------------------------- 1 | # -*- coding: utf-8 -*- 2 | # 3 | # The Penetration Testing Execution Standard documentation build configuration file, created by 4 | # sphinx-quickstart on Sun Oct 30 18:04:42 2016. 5 | # 6 | # This file is execfile()d with the current directory set to its 7 | # containing dir. 8 | # 9 | # Note that not all possible configuration values are present in this 10 | # autogenerated file. 11 | # 12 | # All configuration values have a default; values that are commented out 13 | # serve to show the default. 14 | 15 | # If extensions (or modules to document with autodoc) are in another directory, 16 | # add these directories to sys.path here. If the directory is relative to the 17 | # documentation root, use os.path.abspath to make it absolute, like shown here. 18 | # 19 | # import os 20 | # import sys 21 | # sys.path.insert(0, os.path.abspath('.')) 22 | 23 | import sphinx_rtd_theme 24 | 25 | # -- General configuration ------------------------------------------------ 26 | 27 | # If your documentation needs a minimal Sphinx version, state it here. 28 | # 29 | # needs_sphinx = '1.0' 30 | 31 | # Add any Sphinx extension module names here, as strings. They can be 32 | # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom 33 | # ones. 34 | extensions = [] 35 | 36 | # Add any paths that contain templates here, relative to this directory. 37 | templates_path = ['_templates'] 38 | 39 | # The suffix(es) of source filenames. 40 | # You can specify multiple suffix as a list of string: 41 | # 42 | # source_suffix = ['.rst', '.md'] 43 | source_suffix = '.rst' 44 | 45 | # The encoding of source files. 46 | # 47 | # source_encoding = 'utf-8-sig' 48 | 49 | # The master toctree document. 50 | master_doc = 'tree' 51 | 52 | # General information about the project. 53 | project = u'pentest-standard' 54 | copyright = u'2016, The PTES Team' 55 | author = u'The PTES Team' 56 | 57 | # The version info for the project you're documenting, acts as replacement for 58 | # |version| and |release|, also used in various other places throughout the 59 | # built documents. 60 | # 61 | # The short X.Y version. 62 | version = u'1.1' 63 | # The full version, including alpha/beta/rc tags. 64 | release = u'1.1' 65 | 66 | # The language for content autogenerated by Sphinx. Refer to documentation 67 | # for a list of supported languages. 68 | # 69 | # This is also used if you do content translation via gettext catalogs. 70 | # Usually you set "language" from the command line for these cases. 71 | language = None 72 | 73 | # There are two options for replacing |today|: either, you set today to some 74 | # non-false value, then it is used: 75 | # 76 | # today = '' 77 | # 78 | # Else, today_fmt is used as the format for a strftime call. 79 | # 80 | # today_fmt = '%B %d, %Y' 81 | 82 | # List of patterns, relative to source directory, that match files and 83 | # directories to ignore when looking for source files. 84 | # This patterns also effect to html_static_path and html_extra_path 85 | exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store'] 86 | 87 | # The reST default role (used for this markup: `text`) to use for all 88 | # documents. 89 | # 90 | # default_role = None 91 | 92 | # If true, '()' will be appended to :func: etc. cross-reference text. 93 | # 94 | # add_function_parentheses = True 95 | 96 | # If true, the current module name will be prepended to all description 97 | # unit titles (such as .. function::). 98 | # 99 | # add_module_names = True 100 | 101 | # If true, sectionauthor and moduleauthor directives will be shown in the 102 | # output. They are ignored by default. 103 | # 104 | # show_authors = False 105 | 106 | # The name of the Pygments (syntax highlighting) style to use. 107 | pygments_style = 'sphinx' 108 | 109 | # A list of ignored prefixes for module index sorting. 110 | # modindex_common_prefix = [] 111 | 112 | # If true, keep warnings as "system message" paragraphs in the built documents. 113 | # keep_warnings = False 114 | 115 | # If true, `todo` and `todoList` produce output, else they produce nothing. 116 | todo_include_todos = False 117 | 118 | 119 | # -- Options for HTML output ---------------------------------------------- 120 | 121 | # The theme to use for HTML and HTML Help pages. See the documentation for 122 | # a list of builtin themes. 123 | # 124 | #html_theme = 'alabaster' 125 | 126 | # Theme options are theme-specific and customize the look and feel of a theme 127 | # further. For a list of options available for each theme, see the 128 | # documentation. 129 | # 130 | # html_theme_options = {} 131 | 132 | # Add any paths that contain custom themes here, relative to this directory. 133 | # html_theme_path = [] 134 | 135 | # The name for this set of Sphinx documents. 136 | # " v documentation" by default. 137 | # 138 | # html_title = u'The Penetration Testing Execution Standard v1.1' 139 | 140 | # A shorter title for the navigation bar. Default is the same as html_title. 141 | # 142 | # html_short_title = None 143 | 144 | # The name of an image file (relative to this directory) to place at the top 145 | # of the sidebar. 146 | # 147 | # html_logo = None 148 | 149 | # The name of an image file (relative to this directory) to use as a favicon of 150 | # the docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32 151 | # pixels large. 152 | # 153 | # html_favicon = None 154 | 155 | # Add any paths that contain custom static files (such as style sheets) here, 156 | # relative to this directory. They are copied after the builtin static files, 157 | # so a file named "default.css" will overwrite the builtin "default.css". 158 | html_static_path = ['_static'] 159 | 160 | # Add any extra paths that contain custom files (such as robots.txt or 161 | # .htaccess) here, relative to this directory. These files are copied 162 | # directly to the root of the documentation. 163 | # 164 | # html_extra_path = [] 165 | 166 | # If not None, a 'Last updated on:' timestamp is inserted at every page 167 | # bottom, using the given strftime format. 168 | # The empty string is equivalent to '%b %d, %Y'. 169 | # 170 | # html_last_updated_fmt = None 171 | 172 | # If true, SmartyPants will be used to convert quotes and dashes to 173 | # typographically correct entities. 174 | # 175 | # html_use_smartypants = True 176 | 177 | # Custom sidebar templates, maps document names to template names. 178 | # 179 | # html_sidebars = {} 180 | 181 | # Additional templates that should be rendered to pages, maps page names to 182 | # template names. 183 | # 184 | # html_additional_pages = {} 185 | 186 | # If false, no module index is generated. 187 | # 188 | # html_domain_indices = True 189 | 190 | # If false, no index is generated. 191 | # 192 | # html_use_index = True 193 | 194 | # If true, the index is split into individual pages for each letter. 195 | # 196 | # html_split_index = False 197 | 198 | # If true, links to the reST sources are added to the pages. 199 | # 200 | # html_show_sourcelink = True 201 | 202 | # If true, "Created using Sphinx" is shown in the HTML footer. Default is True. 203 | # 204 | # html_show_sphinx = True 205 | 206 | # If true, "(C) Copyright ..." is shown in the HTML footer. Default is True. 207 | # 208 | # html_show_copyright = True 209 | 210 | # If true, an OpenSearch description file will be output, and all pages will 211 | # contain a tag referring to it. The value of this option must be the 212 | # base URL from which the finished HTML is served. 213 | # 214 | # html_use_opensearch = '' 215 | 216 | # This is the file name suffix for HTML files (e.g. ".xhtml"). 217 | # html_file_suffix = None 218 | 219 | # Language to be used for generating the HTML full-text search index. 220 | # Sphinx supports the following languages: 221 | # 'da', 'de', 'en', 'es', 'fi', 'fr', 'hu', 'it', 'ja' 222 | # 'nl', 'no', 'pt', 'ro', 'ru', 'sv', 'tr', 'zh' 223 | # 224 | # html_search_language = 'en' 225 | 226 | # A dictionary with options for the search language support, empty by default. 227 | # 'ja' uses this config value. 228 | # 'zh' user can custom change `jieba` dictionary path. 229 | # 230 | # html_search_options = {'type': 'default'} 231 | 232 | # The name of a javascript file (relative to the configuration directory) that 233 | # implements a search results scorer. If empty, the default will be used. 234 | # 235 | # html_search_scorer = 'scorer.js' 236 | 237 | # Output file base name for HTML help builder. 238 | htmlhelp_basename = 'ThePenetrationTestingExecutionStandarddoc' 239 | 240 | # -- Options for LaTeX output --------------------------------------------- 241 | 242 | latex_elements = { 243 | # The paper size ('letterpaper' or 'a4paper'). 244 | # 245 | # 'papersize': 'letterpaper', 246 | 247 | # The font size ('10pt', '11pt' or '12pt'). 248 | # 249 | # 'pointsize': '10pt', 250 | 251 | # Additional stuff for the LaTeX preamble. 252 | # 253 | # 'preamble': '', 254 | 255 | # Latex figure (float) alignment 256 | # 257 | # 'figure_align': 'htbp', 258 | } 259 | 260 | # Grouping the document tree into LaTeX files. List of tuples 261 | # (source start file, target name, title, 262 | # author, documentclass [howto, manual, or own class]). 263 | latex_documents = [ 264 | (master_doc, 'ThePenetrationTestingExecutionStandard.tex', u'The Penetration Testing Execution Standard Documentation', 265 | u'The PTES Team', 'manual'), 266 | ] 267 | 268 | # The name of an image file (relative to this directory) to place at the top of 269 | # the title page. 270 | # 271 | # latex_logo = None 272 | 273 | # For "manual" documents, if this is true, then toplevel headings are parts, 274 | # not chapters. 275 | # 276 | # latex_use_parts = False 277 | 278 | # If true, show page references after internal links. 279 | # 280 | # latex_show_pagerefs = False 281 | 282 | # If true, show URL addresses after external links. 283 | # 284 | # latex_show_urls = False 285 | 286 | # Documents to append as an appendix to all manuals. 287 | # 288 | # latex_appendices = [] 289 | 290 | # It false, will not define \strong, \code, itleref, \crossref ... but only 291 | # \sphinxstrong, ..., \sphinxtitleref, ... To help avoid clash with user added 292 | # packages. 293 | # 294 | # latex_keep_old_macro_names = True 295 | 296 | # If false, no module index is generated. 297 | # 298 | # latex_domain_indices = True 299 | 300 | 301 | # -- Options for manual page output --------------------------------------- 302 | 303 | # One entry per manual page. List of tuples 304 | # (source start file, name, description, authors, manual section). 305 | man_pages = [ 306 | (master_doc, 'thepenetrationtestingexecutionstandard', u'The Penetration Testing Execution Standard Documentation', 307 | [author], 1) 308 | ] 309 | 310 | # If true, show URL addresses after external links. 311 | # 312 | # man_show_urls = False 313 | 314 | 315 | # -- Options for Texinfo output ------------------------------------------- 316 | 317 | # Grouping the document tree into Texinfo files. List of tuples 318 | # (source start file, target name, title, author, 319 | # dir menu entry, description, category) 320 | texinfo_documents = [ 321 | (master_doc, 'ThePenetrationTestingExecutionStandard', u'The Penetration Testing Execution Standard Documentation', 322 | author, 'ThePenetrationTestingExecutionStandard', 'One line description of project.', 323 | 'Miscellaneous'), 324 | ] 325 | 326 | # Documents to append as an appendix to all manuals. 327 | # 328 | # texinfo_appendices = [] 329 | 330 | # If false, no module index is generated. 331 | # 332 | # texinfo_domain_indices = True 333 | 334 | # How to display URL addresses: 'footnote', 'no', or 'inline'. 335 | # 336 | # texinfo_show_urls = 'footnote' 337 | 338 | # If true, do not generate a @detailmenu in the "Top" node's menu. 339 | # 340 | # texinfo_no_detailmenu = False 341 | 342 | 343 | # -- Options for Epub output ---------------------------------------------- 344 | 345 | # Bibliographic Dublin Core info. 346 | epub_title = project 347 | epub_author = author 348 | epub_publisher = author 349 | epub_copyright = copyright 350 | 351 | # The basename for the epub file. It defaults to the project name. 352 | # epub_basename = project 353 | 354 | # The HTML theme for the epub output. Since the default themes are not 355 | # optimized for small screen space, using the same theme for HTML and epub 356 | # output is usually not wise. This defaults to 'epub', a theme designed to save 357 | # visual space. 358 | # 359 | # epub_theme = 'epub' 360 | 361 | # The language of the text. It defaults to the language option 362 | # or 'en' if the language is not set. 363 | # 364 | # epub_language = '' 365 | 366 | # The scheme of the identifier. Typical schemes are ISBN or URL. 367 | # epub_scheme = '' 368 | 369 | # The unique identifier of the text. This can be a ISBN number 370 | # or the project homepage. 371 | # 372 | # epub_identifier = '' 373 | 374 | # A unique identification for the text. 375 | # 376 | # epub_uid = '' 377 | 378 | # A tuple containing the cover image and cover page html template filenames. 379 | # 380 | # epub_cover = () 381 | 382 | # A sequence of (type, uri, title) tuples for the guide element of content.opf. 383 | # 384 | # epub_guide = () 385 | 386 | # HTML files that should be inserted before the pages created by sphinx. 387 | # The format is a list of tuples containing the path and title. 388 | # 389 | # epub_pre_files = [] 390 | 391 | # HTML files that should be inserted after the pages created by sphinx. 392 | # The format is a list of tuples containing the path and title. 393 | # 394 | # epub_post_files = [] 395 | 396 | # A list of files that should not be packed into the epub file. 397 | epub_exclude_files = ['search.html'] 398 | 399 | # The depth of the table of contents in toc.ncx. 400 | # 401 | # epub_tocdepth = 3 402 | 403 | # Allow duplicate toc entries. 404 | # 405 | # epub_tocdup = True 406 | 407 | # Choose between 'default' and 'includehidden'. 408 | # 409 | # epub_tocscope = 'default' 410 | 411 | # Fix unsupported image types using the Pillow. 412 | # 413 | # epub_fix_images = False 414 | 415 | # Scale large images. 416 | # 417 | # epub_max_image_width = 0 418 | 419 | # How to display URL addresses: 'footnote', 'no', or 'inline'. 420 | # 421 | # epub_show_urls = 'inline' 422 | 423 | # If false, no index is generated. 424 | # 425 | # epub_use_index = True 426 | 427 | ### PTES customer stuff 428 | 429 | html_theme = "sphinx_rtd_theme" 430 | 431 | html_theme_path = [sphinx_rtd_theme.get_html_theme_path()] 432 | 433 | -------------------------------------------------------------------------------- /_build/html/_static/js/modernizr.min.js: -------------------------------------------------------------------------------- 1 | /* Modernizr 2.6.2 (Custom Build) | MIT & BSD 2 | * Build: http://modernizr.com/download/#-fontface-backgroundsize-borderimage-borderradius-boxshadow-flexbox-hsla-multiplebgs-opacity-rgba-textshadow-cssanimations-csscolumns-generatedcontent-cssgradients-cssreflections-csstransforms-csstransforms3d-csstransitions-applicationcache-canvas-canvastext-draganddrop-hashchange-history-audio-video-indexeddb-input-inputtypes-localstorage-postmessage-sessionstorage-websockets-websqldatabase-webworkers-geolocation-inlinesvg-smil-svg-svgclippaths-touch-webgl-shiv-mq-cssclasses-addtest-prefixed-teststyles-testprop-testallprops-hasevent-prefixes-domprefixes-load 3 | */ 4 | ;window.Modernizr=function(a,b,c){function D(a){j.cssText=a}function E(a,b){return D(n.join(a+";")+(b||""))}function F(a,b){return typeof a===b}function G(a,b){return!!~(""+a).indexOf(b)}function H(a,b){for(var d in a){var e=a[d];if(!G(e,"-")&&j[e]!==c)return b=="pfx"?e:!0}return!1}function I(a,b,d){for(var e in a){var f=b[a[e]];if(f!==c)return d===!1?a[e]:F(f,"function")?f.bind(d||b):f}return!1}function J(a,b,c){var d=a.charAt(0).toUpperCase()+a.slice(1),e=(a+" "+p.join(d+" ")+d).split(" ");return F(b,"string")||F(b,"undefined")?H(e,b):(e=(a+" "+q.join(d+" ")+d).split(" "),I(e,b,c))}function K(){e.input=function(c){for(var d=0,e=c.length;d',a,""].join(""),l.id=h,(m?l:n).innerHTML+=f,n.appendChild(l),m||(n.style.background="",n.style.overflow="hidden",k=g.style.overflow,g.style.overflow="hidden",g.appendChild(n)),i=c(l,a),m?l.parentNode.removeChild(l):(n.parentNode.removeChild(n),g.style.overflow=k),!!i},z=function(b){var c=a.matchMedia||a.msMatchMedia;if(c)return c(b).matches;var d;return y("@media "+b+" { #"+h+" { position: absolute; } }",function(b){d=(a.getComputedStyle?getComputedStyle(b,null):b.currentStyle)["position"]=="absolute"}),d},A=function(){function d(d,e){e=e||b.createElement(a[d]||"div"),d="on"+d;var f=d in e;return f||(e.setAttribute||(e=b.createElement("div")),e.setAttribute&&e.removeAttribute&&(e.setAttribute(d,""),f=F(e[d],"function"),F(e[d],"undefined")||(e[d]=c),e.removeAttribute(d))),e=null,f}var a={select:"input",change:"input",submit:"form",reset:"form",error:"img",load:"img",abort:"img"};return d}(),B={}.hasOwnProperty,C;!F(B,"undefined")&&!F(B.call,"undefined")?C=function(a,b){return B.call(a,b)}:C=function(a,b){return b in a&&F(a.constructor.prototype[b],"undefined")},Function.prototype.bind||(Function.prototype.bind=function(b){var c=this;if(typeof c!="function")throw new TypeError;var d=w.call(arguments,1),e=function(){if(this instanceof e){var a=function(){};a.prototype=c.prototype;var f=new a,g=c.apply(f,d.concat(w.call(arguments)));return Object(g)===g?g:f}return c.apply(b,d.concat(w.call(arguments)))};return e}),s.flexbox=function(){return J("flexWrap")},s.canvas=function(){var a=b.createElement("canvas");return!!a.getContext&&!!a.getContext("2d")},s.canvastext=function(){return!!e.canvas&&!!F(b.createElement("canvas").getContext("2d").fillText,"function")},s.webgl=function(){return!!a.WebGLRenderingContext},s.touch=function(){var c;return"ontouchstart"in a||a.DocumentTouch&&b instanceof DocumentTouch?c=!0:y(["@media (",n.join("touch-enabled),("),h,")","{#modernizr{top:9px;position:absolute}}"].join(""),function(a){c=a.offsetTop===9}),c},s.geolocation=function(){return"geolocation"in navigator},s.postmessage=function(){return!!a.postMessage},s.websqldatabase=function(){return!!a.openDatabase},s.indexedDB=function(){return!!J("indexedDB",a)},s.hashchange=function(){return A("hashchange",a)&&(b.documentMode===c||b.documentMode>7)},s.history=function(){return!!a.history&&!!history.pushState},s.draganddrop=function(){var a=b.createElement("div");return"draggable"in a||"ondragstart"in a&&"ondrop"in a},s.websockets=function(){return"WebSocket"in a||"MozWebSocket"in a},s.rgba=function(){return D("background-color:rgba(150,255,150,.5)"),G(j.backgroundColor,"rgba")},s.hsla=function(){return D("background-color:hsla(120,40%,100%,.5)"),G(j.backgroundColor,"rgba")||G(j.backgroundColor,"hsla")},s.multiplebgs=function(){return D("background:url(https://),url(https://),red url(https://)"),/(url\s*\(.*?){3}/.test(j.background)},s.backgroundsize=function(){return J("backgroundSize")},s.borderimage=function(){return J("borderImage")},s.borderradius=function(){return J("borderRadius")},s.boxshadow=function(){return J("boxShadow")},s.textshadow=function(){return b.createElement("div").style.textShadow===""},s.opacity=function(){return E("opacity:.55"),/^0.55$/.test(j.opacity)},s.cssanimations=function(){return J("animationName")},s.csscolumns=function(){return J("columnCount")},s.cssgradients=function(){var a="background-image:",b="gradient(linear,left top,right bottom,from(#9f9),to(white));",c="linear-gradient(left top,#9f9, white);";return D((a+"-webkit- ".split(" ").join(b+a)+n.join(c+a)).slice(0,-a.length)),G(j.backgroundImage,"gradient")},s.cssreflections=function(){return J("boxReflect")},s.csstransforms=function(){return!!J("transform")},s.csstransforms3d=function(){var a=!!J("perspective");return a&&"webkitPerspective"in g.style&&y("@media (transform-3d),(-webkit-transform-3d){#modernizr{left:9px;position:absolute;height:3px;}}",function(b,c){a=b.offsetLeft===9&&b.offsetHeight===3}),a},s.csstransitions=function(){return J("transition")},s.fontface=function(){var a;return y('@font-face {font-family:"font";src:url("https://")}',function(c,d){var e=b.getElementById("smodernizr"),f=e.sheet||e.styleSheet,g=f?f.cssRules&&f.cssRules[0]?f.cssRules[0].cssText:f.cssText||"":"";a=/src/i.test(g)&&g.indexOf(d.split(" ")[0])===0}),a},s.generatedcontent=function(){var a;return y(["#",h,"{font:0/0 a}#",h,':after{content:"',l,'";visibility:hidden;font:3px/1 a}'].join(""),function(b){a=b.offsetHeight>=3}),a},s.video=function(){var a=b.createElement("video"),c=!1;try{if(c=!!a.canPlayType)c=new Boolean(c),c.ogg=a.canPlayType('video/ogg; codecs="theora"').replace(/^no$/,""),c.h264=a.canPlayType('video/mp4; codecs="avc1.42E01E"').replace(/^no$/,""),c.webm=a.canPlayType('video/webm; codecs="vp8, vorbis"').replace(/^no$/,"")}catch(d){}return c},s.audio=function(){var a=b.createElement("audio"),c=!1;try{if(c=!!a.canPlayType)c=new Boolean(c),c.ogg=a.canPlayType('audio/ogg; codecs="vorbis"').replace(/^no$/,""),c.mp3=a.canPlayType("audio/mpeg;").replace(/^no$/,""),c.wav=a.canPlayType('audio/wav; codecs="1"').replace(/^no$/,""),c.m4a=(a.canPlayType("audio/x-m4a;")||a.canPlayType("audio/aac;")).replace(/^no$/,"")}catch(d){}return c},s.localstorage=function(){try{return localStorage.setItem(h,h),localStorage.removeItem(h),!0}catch(a){return!1}},s.sessionstorage=function(){try{return sessionStorage.setItem(h,h),sessionStorage.removeItem(h),!0}catch(a){return!1}},s.webworkers=function(){return!!a.Worker},s.applicationcache=function(){return!!a.applicationCache},s.svg=function(){return!!b.createElementNS&&!!b.createElementNS(r.svg,"svg").createSVGRect},s.inlinesvg=function(){var a=b.createElement("div");return a.innerHTML="",(a.firstChild&&a.firstChild.namespaceURI)==r.svg},s.smil=function(){return!!b.createElementNS&&/SVGAnimate/.test(m.call(b.createElementNS(r.svg,"animate")))},s.svgclippaths=function(){return!!b.createElementNS&&/SVGClipPath/.test(m.call(b.createElementNS(r.svg,"clipPath")))};for(var L in s)C(s,L)&&(x=L.toLowerCase(),e[x]=s[L](),v.push((e[x]?"":"no-")+x));return e.input||K(),e.addTest=function(a,b){if(typeof a=="object")for(var d in a)C(a,d)&&e.addTest(d,a[d]);else{a=a.toLowerCase();if(e[a]!==c)return e;b=typeof b=="function"?b():b,typeof f!="undefined"&&f&&(g.className+=" "+(b?"":"no-")+a),e[a]=b}return e},D(""),i=k=null,function(a,b){function k(a,b){var c=a.createElement("p"),d=a.getElementsByTagName("head")[0]||a.documentElement;return c.innerHTML="x",d.insertBefore(c.lastChild,d.firstChild)}function l(){var a=r.elements;return typeof a=="string"?a.split(" "):a}function m(a){var b=i[a[g]];return b||(b={},h++,a[g]=h,i[h]=b),b}function n(a,c,f){c||(c=b);if(j)return c.createElement(a);f||(f=m(c));var g;return f.cache[a]?g=f.cache[a].cloneNode():e.test(a)?g=(f.cache[a]=f.createElem(a)).cloneNode():g=f.createElem(a),g.canHaveChildren&&!d.test(a)?f.frag.appendChild(g):g}function o(a,c){a||(a=b);if(j)return a.createDocumentFragment();c=c||m(a);var d=c.frag.cloneNode(),e=0,f=l(),g=f.length;for(;e",f="hidden"in a,j=a.childNodes.length==1||function(){b.createElement("a");var a=b.createDocumentFragment();return typeof a.cloneNode=="undefined"||typeof a.createDocumentFragment=="undefined"||typeof a.createElement=="undefined"}()}catch(c){f=!0,j=!0}})();var r={elements:c.elements||"abbr article aside audio bdi canvas data datalist details figcaption figure footer header hgroup mark meter nav output progress section summary time video",shivCSS:c.shivCSS!==!1,supportsUnknownElements:j,shivMethods:c.shivMethods!==!1,type:"default",shivDocument:q,createElement:n,createDocumentFragment:o};a.html5=r,q(b)}(this,b),e._version=d,e._prefixes=n,e._domPrefixes=q,e._cssomPrefixes=p,e.mq=z,e.hasEvent=A,e.testProp=function(a){return H([a])},e.testAllProps=J,e.testStyles=y,e.prefixed=function(a,b,c){return b?J(a,b,c):J(a,"pfx")},g.className=g.className.replace(/(^|\s)no-js(\s|$)/,"$1$2")+(f?" js "+v.join(" "):""),e}(this,this.document),function(a,b,c){function d(a){return"[object Function]"==o.call(a)}function e(a){return"string"==typeof a}function f(){}function g(a){return!a||"loaded"==a||"complete"==a||"uninitialized"==a}function h(){var a=p.shift();q=1,a?a.t?m(function(){("c"==a.t?B.injectCss:B.injectJs)(a.s,0,a.a,a.x,a.e,1)},0):(a(),h()):q=0}function i(a,c,d,e,f,i,j){function k(b){if(!o&&g(l.readyState)&&(u.r=o=1,!q&&h(),l.onload=l.onreadystatechange=null,b)){"img"!=a&&m(function(){t.removeChild(l)},50);for(var d in y[c])y[c].hasOwnProperty(d)&&y[c][d].onload()}}var j=j||B.errorTimeout,l=b.createElement(a),o=0,r=0,u={t:d,s:c,e:f,a:i,x:j};1===y[c]&&(r=1,y[c]=[]),"object"==a?l.data=c:(l.src=c,l.type=a),l.width=l.height="0",l.onerror=l.onload=l.onreadystatechange=function(){k.call(this,r)},p.splice(e,0,u),"img"!=a&&(r||2===y[c]?(t.insertBefore(l,s?null:n),m(k,j)):y[c].push(l))}function j(a,b,c,d,f){return q=0,b=b||"j",e(a)?i("c"==b?v:u,a,b,this.i++,c,d,f):(p.splice(this.i++,0,a),1==p.length&&h()),this}function k(){var a=B;return a.loader={load:j,i:0},a}var l=b.documentElement,m=a.setTimeout,n=b.getElementsByTagName("script")[0],o={}.toString,p=[],q=0,r="MozAppearance"in l.style,s=r&&!!b.createRange().compareNode,t=s?l:n.parentNode,l=a.opera&&"[object Opera]"==o.call(a.opera),l=!!b.attachEvent&&!l,u=r?"object":l?"script":"img",v=l?"script":u,w=Array.isArray||function(a){return"[object Array]"==o.call(a)},x=[],y={},z={timeout:function(a,b){return b.length&&(a.timeout=b[0]),a}},A,B;B=function(a){function b(a){var a=a.split("!"),b=x.length,c=a.pop(),d=a.length,c={url:c,origUrl:c,prefixes:a},e,f,g;for(f=0;f) exploitation of weakened services, client side attacks, 51 | browser side attacks (etc) The purpose of this assessment was to verify 52 | the effectiveness of the security controls put in place by (CLIENT) to 53 | secure business-critical information. This report represents the 54 | findings from the assessment and the associated remediation 55 | recommendations to help CLIENT strengthen its security posture. 56 | 57 | - If objectives were changed during the course of the testing then all 58 | changes must be listed in this section of the report. Additionally, 59 | the letter of amendment should be included in the appendix of the 60 | report and linked to from this section. 61 | 62 | **Overall Posture:** 63 | 64 | This area will be a narrative of the overall effectiveness of the test 65 | and the pentesters ability to achieve the goals set forth within the pre 66 | engagement sessions. A brief description of the Systemic (ex. Systemic 67 | issue= Lacking Effective Patch Management Process vs. Symptomatic= Found 68 | MS08-067 missing on xyz box) issues identified through the testing 69 | process as well as the ability to achieve access to the goal information 70 | and identify a potential impact to the business. 71 | 72 | **Risk Ranking/Profile:** 73 | 74 | The overall risk ranking/profile/score will be identified and explained 75 | in this area. In the pre engagement section the Pentester will identify 76 | the scoring mechanism and the individual mechanism for tracking/grading 77 | risk. Various methods from FAIR, DREAD, and other custom rankings will 78 | be consolidated into environmental scores and defined. 79 | 80 | image:reporting-risk-scale.png 81 | 82 | The “Overall Risk Score” for the (CLIENT) is currently a Seven (7). This 83 | rating implies an ELEVATED risk of security controls being compromised 84 | with the potential for material financial losses. The consultant 85 | determined this risk score based on one high risk and several medium 86 | risk vulnerabilities, along with the success of directed attack. The 87 | most severe vulnerability identified was the presence of default 88 | passwords in the corporate public facing website which allowed access to 89 | a number of sensitive documents and the ability to control content on 90 | the device. This vulnerability could lead to theft of user accounts, 91 | leakage of sensitive information, or full system compromise. Several 92 | lesser severe vulnerabilities could lead to theft of valid account 93 | credentials and leakage of information. 94 | 95 | **General Findings:** 96 | 97 | The general findings will provide a synopsis of the issues found during 98 | the penetration test in a basic and statistical format. Graphic 99 | representations of the targets tested, testing results, processes, 100 | attack scenarios, success rates, and other trendable metrics as defined 101 | within the pre engagement meeting should be present. In addition, the 102 | cause of the issues should be presented in an easy to read format. (ex. 103 | A graph showing the root cause of issues exploited) 104 | 105 | image:risk-origin.png 106 | 107 | If defined within the Pre engagement exercise, this area should also 108 | include metrics which depict the effectiveness of the countermeasures 109 | within the environment. (ex.. we ran x attacks and IPS blocked y. Other 110 | countermeasures should also have similar metrics of design vs. 111 | effectiveness.) 112 | 113 | **Recommendation Summary:** 114 | 115 | The recommendation section of the report should provide the reader with 116 | a high level understanding of the tasks needed to resolve the risks 117 | identified and the general level of effort required to implement the 118 | resolution path suggested. This section will also identify the weighting 119 | mechanisms used to prioritize the order of the road map following. 120 | 121 | **Strategic Roadmap:** 122 | 123 | Roadmaps should include a prioritized plan for remediation of the 124 | insecure items found and should be weighed against the business 125 | objectives/ level of potential impact. This section should map directly 126 | to the goals identified as well as the threat matrix created in the 127 | PTES-Threat modeling section. By breaking up into predefined 128 | time/objective based goals, this section will create a path of action to 129 | follow in various increments. Example: 130 | 131 | image:roadmap1.png 132 | 133 | image:roadmap2.png 134 | 135 | image:roadmap3.png 136 | 137 | Technical Report 138 | ---------------- 139 | 140 | This section will communicate to the reader the technical details of the 141 | test and all of the aspects/components agreed upon as key success 142 | indicators within the pre engagement exercise. The technical report 143 | section will describe in detail the scope, information, attack path, 144 | impact and remediation suggestions of the test. 145 | 146 | **Introduction:** 147 | 148 | The introduction section of the technical report is intended to be an 149 | initial inventory of: 150 | 151 | - Personnel involved in the testing from both the Client and 152 | Penetration Testing Team 153 | - Contact information 154 | - Assets involved in testing 155 | - Objectives of Test 156 | - Scope of Test 157 | - Strength of Test 158 | - Approach 159 | - Threat/Grading Structure 160 | 161 | This section should be a reference for the specific resources involved 162 | in the testing and the overall technical scope of the test. 163 | 164 | **Information Gathering:** 165 | 166 | Intelligence gathering and information assessment are the foundations of 167 | a good penetration test. The more informed the tester is about the 168 | environment, the better the results of the test will be. In this 169 | section, a number of items should be written up to show the CLIENT the 170 | extent of public and private information available through the execution 171 | of the Intelligence gathering phase of PTES. At a minimum, the results 172 | identified should be presented in 4 basic categories: 173 | 174 | **Passive Intelligence:** 175 | 176 | Intelligence gathered from indirect analysis such as DNS,Google dorking 177 | for IP/infrastructure related information. This section will focus on 178 | the techniques used to profile the technology in the CLIENT environment 179 | WITHOUT sending any traffic directly to the assets. 180 | 181 | **Active Intelligence:** 182 | 183 | This section will show the methods and results of tasks such as 184 | infrastructure mapping, port scanning, and architecture assessment and 185 | other foot printing activities. This section will focus on the 186 | techniques used to profile the technology in the CLIENT environment by 187 | sending traffic DIRECTLY to the assets. 188 | 189 | **Corporate Intelligence:** 190 | 191 | Information about the structure of the organization, business units, 192 | market share, vertical, and other corporate functions should be mapped 193 | to both business process and the previously identified physical assets 194 | being tested. 195 | 196 | **Personnel Intelligence:** 197 | 198 | Any and all information found during the intelligence collection phase 199 | which maps users to the CLIENT organization. This section should show 200 | the techniques used to harvest intelligence such as public/private 201 | employee depots, mail repositories, org charts and other items leading 202 | to the connection of employee/company. 203 | 204 | **Vulnerability Assessment:** 205 | 206 | Vulnerability assessment is the act of identifying the POTENTIAL 207 | vulnerabilities which exist in a TEST and the threat classification of 208 | each threat. In this section, a definition of the methods used to 209 | identify the vulnerability as well as the evidence/classification of the 210 | vulnerability should be present. In addition this section should 211 | include: 212 | 213 | - Vulnerability Classification Levels 214 | - Technical Vulnerabilities 215 | 216 | - OSI Layer Vulns 217 | - Scanner Found 218 | - Manually identified 219 | - Overall Exposure 220 | 221 | - Logical Vulnerabilities 222 | 223 | - NON OSI Vuln 224 | - Type of vuln 225 | - How/Where it is found 226 | - Exposure 227 | 228 | - Summary of Results 229 | 230 | **Exploitation/ Vulnerability Confirmation:** 231 | 232 | Exploitation or Vulnerability confirmation is the act of triggering the 233 | vulnerabilities identified in the previous sections to gain a specified 234 | level of access to the target asset. This section should review, in 235 | detail, all of the steps taken to confirm the defined vulnerability as 236 | well as the following: 237 | 238 | - Exploitation Timeline 239 | - Targets selected for Exploitation 240 | - Exploitation Activities 241 | 242 | - Directed Attack 243 | 244 | - Target Hosts unable to be Exploited 245 | - Target Hosts able to be Exploited 246 | 247 | - Individual Host Information 248 | - Attacks conducted 249 | - Attacks Successful 250 | - Level of access Granted +escalation path 251 | - Remediation 252 | 253 | - Link to Vuln section reference 254 | - Additional Mitigating technique 255 | - Compensating control suggestion 256 | 257 | - Indirect Attack 258 | 259 | - Phishing 260 | 261 | - Timeline/details of attack 262 | - Targets identified 263 | - Success/Fail ratio 264 | - Level of access granted 265 | 266 | - Clientside 267 | 268 | - Timeline/details of attack 269 | - Targets identified 270 | - Success/Fail ratio 271 | - Level of access granted 272 | 273 | - Browser Side 274 | 275 | - Timeline/details of attack 276 | - Targets identified 277 | - Success/Fail ratio 278 | - Level of access granted 279 | 280 | **Post Exploitation:** 281 | 282 | One of the most critical items in all testing is the connection to 283 | ACTUAL impact on the CLIENT being tested. While the sections above relay 284 | the technical nature of the vulnerability and the ability to 285 | successfully take advantage of the flaw, the Post Exploitation section 286 | should tie the ability of exploitation to the actual risk to the 287 | business. In this area the following items should be evidenced through 288 | the use of screenshots, rich content retrieval, and examples of real 289 | world privileged user access: 290 | 291 | - Privilege Escalation path 292 | 293 | - Technique used 294 | 295 | - Acquisition of Critical Information Defined by client 296 | - Value of information 297 | - Access to core business systems 298 | - Access to compliance protected data sets 299 | - Additional Information/Systems Accessed 300 | - Ability of persistence 301 | - Ability for exfiltration 302 | - Countermeasure Effectiveness 303 | 304 | This section should cover the effectiveness of countermeasures 305 | that are in place on the systems in scope. It should include 306 | sections on both active (proactive) and passive (reactive) 307 | countermeasures, as well as detailed information on any incident 308 | response activities triggered during the testing phase. A listing 309 | of countermeasures that were effective in resisting assessment 310 | activities will help the CLIENT better tune detection systems and 311 | processes to handle future intrusion attempts. 312 | 313 | - Detection Capability 314 | 315 | - FW/WAF/IDS/IPS 316 | - Human 317 | - DLP 318 | - Log 319 | 320 | - Response & effectiveness 321 | 322 | **Risk/Exposure:** 323 | 324 | Once the direct impact to the business is qualified through the evidence 325 | existing in the vulnerability, exploitation and post exploitation 326 | sections, the risk quantification can be conducted. In this section the 327 | results above are combined with the risk values, information 328 | criticality, corporate valuation, and derived business impact from the 329 | pre engagement section. This will give the CLIENT the ability to 330 | identify, visualize and monetize the vulnerabilities found throughout 331 | the testing and effectively weight their resolution against the CLIENTS 332 | business objectives. This section will cover the business risk in the 333 | following subsections: 334 | 335 | - Evaluate incident frequency 336 | 337 | - probable event frequency 338 | - estimate threat capability (from 3 - threat modeling) 339 | - Estimate controls strength (6) 340 | - Compound vulnerability (5) 341 | - Level of skill required 342 | - Level of access required 343 | 344 | - Estimate loss magnitude per incident 345 | 346 | - Primary loss 347 | - Secondary loss 348 | - Identify risk root cause analysis 349 | 350 | - Root Cause is never a patch 351 | - Identify Failed Processes 352 | 353 | - Derive Risk 354 | 355 | - Threat 356 | - Vulnerability 357 | - Overlap 358 | 359 | **Conclusion:** 360 | 361 | Final overview of the test. It is suggested that this section echo 362 | portions of the overall test as well as support the growth of the CLIENT 363 | security posture. It should end on a positive note with the support and 364 | guidance to enable progress in the security program and a regimen of 365 | testing/security activity in the future to come. 366 | -------------------------------------------------------------------------------- /_build/html/_sources/reporting.txt: -------------------------------------------------------------------------------- 1 | .. _reporting: 2 | 3 | ********* 4 | Reporting 5 | ********* 6 | 7 | Overview 8 | -------- 9 | 10 | This document is intended to define the base criteria for penetration 11 | testing reporting. While it is highly encouraged to use your own 12 | customized and branded format, the following should provide a high level 13 | understanding of the items required within a report as well as a 14 | structure for the report to provide value to the reader. 15 | 16 | Report Structure 17 | ---------------- 18 | 19 | The report is broken down into two (2) major sections in order to 20 | communicate the objectives, methods, and results of the testing 21 | conducted to various audiences. 22 | 23 | The Executive Summary 24 | --------------------- 25 | 26 | This section will communicate to the reader the specific goals of the 27 | Penetration Test and the high level findings of the testing exercise. 28 | The intended audience will be those who are in charge of the oversight 29 | and strategic vision of the security program as well as any members of 30 | the organization which may be impacted by the identified/confirmed 31 | threats. The executive summary should contain most if not all of the 32 | following sections: 33 | 34 | **Background:** 35 | 36 | The background section should explain to the reader the overall purpose 37 | of the test. Details on the terms identified within the Pre Engagement 38 | section relating to risk, countermeasures, and testing goals should be 39 | present to connect the reader to the overall test objectives and the 40 | relative results. 41 | 42 | (Example: (CLIENT) tasked with performing an internal/external 43 | vulnerability assessment and penetration testing of specific systems 44 | located in (logical area or physical location). These systems have been 45 | identified as (risk ranking) and contain (data classification level) 46 | data which, if accessed inappropriately, could cause material harm to 47 | (Client). In an effort to test (CLIENT’s) ability to defend against 48 | direct and indirect attack, executed a comprehensive network 49 | vulnerability scan, Vulnerability conformation( <-insert attack types 50 | agreed upon->) exploitation of weakened services, client side attacks, 51 | browser side attacks (etc) The purpose of this assessment was to verify 52 | the effectiveness of the security controls put in place by (CLIENT) to 53 | secure business-critical information. This report represents the 54 | findings from the assessment and the associated remediation 55 | recommendations to help CLIENT strengthen its security posture. 56 | 57 | - If objectives were changed during the course of the testing then all 58 | changes must be listed in this section of the report. Additionally, 59 | the letter of amendment should be included in the appendix of the 60 | report and linked to from this section. 61 | 62 | **Overall Posture:** 63 | 64 | This area will be a narrative of the overall effectiveness of the test 65 | and the pentesters ability to achieve the goals set forth within the pre 66 | engagement sessions. A brief description of the Systemic (ex. Systemic 67 | issue= Lacking Effective Patch Management Process vs. Symptomatic= Found 68 | MS08-067 missing on xyz box) issues identified through the testing 69 | process as well as the ability to achieve access to the goal information 70 | and identify a potential impact to the business. 71 | 72 | **Risk Ranking/Profile:** 73 | 74 | The overall risk ranking/profile/score will be identified and explained 75 | in this area. In the pre engagement section the Pentester will identify 76 | the scoring mechanism and the individual mechanism for tracking/grading 77 | risk. Various methods from FAIR, DREAD, and other custom rankings will 78 | be consolidated into environmental scores and defined. 79 | 80 | image:reporting-risk-scale.png 81 | 82 | The “Overall Risk Score” for the (CLIENT) is currently a Seven (7). This 83 | rating implies an ELEVATED risk of security controls being compromised 84 | with the potential for material financial losses. The consultant 85 | determined this risk score based on one high risk and several medium 86 | risk vulnerabilities, along with the success of directed attack. The 87 | most severe vulnerability identified was the presence of default 88 | passwords in the corporate public facing website which allowed access to 89 | a number of sensitive documents and the ability to control content on 90 | the device. This vulnerability could lead to theft of user accounts, 91 | leakage of sensitive information, or full system compromise. Several 92 | lesser severe vulnerabilities could lead to theft of valid account 93 | credentials and leakage of information. 94 | 95 | **General Findings:** 96 | 97 | The general findings will provide a synopsis of the issues found during 98 | the penetration test in a basic and statistical format. Graphic 99 | representations of the targets tested, testing results, processes, 100 | attack scenarios, success rates, and other trendable metrics as defined 101 | within the pre engagement meeting should be present. In addition, the 102 | cause of the issues should be presented in an easy to read format. (ex. 103 | A graph showing the root cause of issues exploited) 104 | 105 | image:risk-origin.png 106 | 107 | If defined within the Pre engagement exercise, this area should also 108 | include metrics which depict the effectiveness of the countermeasures 109 | within the environment. (ex.. we ran x attacks and IPS blocked y. Other 110 | countermeasures should also have similar metrics of design vs. 111 | effectiveness.) 112 | 113 | **Recommendation Summary:** 114 | 115 | The recommendation section of the report should provide the reader with 116 | a high level understanding of the tasks needed to resolve the risks 117 | identified and the general level of effort required to implement the 118 | resolution path suggested. This section will also identify the weighting 119 | mechanisms used to prioritize the order of the road map following. 120 | 121 | **Strategic Roadmap:** 122 | 123 | Roadmaps should include a prioritized plan for remediation of the 124 | insecure items found and should be weighed against the business 125 | objectives/ level of potential impact. This section should map directly 126 | to the goals identified as well as the threat matrix created in the 127 | PTES-Threat modeling section. By breaking up into predefined 128 | time/objective based goals, this section will create a path of action to 129 | follow in various increments. Example: 130 | 131 | image:roadmap1.png 132 | 133 | image:roadmap2.png 134 | 135 | image:roadmap3.png 136 | 137 | Technical Report 138 | ---------------- 139 | 140 | This section will communicate to the reader the technical details of the 141 | test and all of the aspects/components agreed upon as key success 142 | indicators within the pre engagement exercise. The technical report 143 | section will describe in detail the scope, information, attack path, 144 | impact and remediation suggestions of the test. 145 | 146 | **Introduction:** 147 | 148 | The introduction section of the technical report is intended to be an 149 | initial inventory of: 150 | 151 | - Personnel involved in the testing from both the Client and 152 | Penetration Testing Team 153 | - Contact information 154 | - Assets involved in testing 155 | - Objectives of Test 156 | - Scope of Test 157 | - Strength of Test 158 | - Approach 159 | - Threat/Grading Structure 160 | 161 | This section should be a reference for the specific resources involved 162 | in the testing and the overall technical scope of the test. 163 | 164 | **Information Gathering:** 165 | 166 | Intelligence gathering and information assessment are the foundations of 167 | a good penetration test. The more informed the tester is about the 168 | environment, the better the results of the test will be. In this 169 | section, a number of items should be written up to show the CLIENT the 170 | extent of public and private information available through the execution 171 | of the Intelligence gathering phase of PTES. At a minimum, the results 172 | identified should be presented in 4 basic categories: 173 | 174 | **Passive Intelligence:** 175 | 176 | Intelligence gathered from indirect analysis such as DNS,Google dorking 177 | for IP/infrastructure related information. This section will focus on 178 | the techniques used to profile the technology in the CLIENT environment 179 | WITHOUT sending any traffic directly to the assets. 180 | 181 | **Active Intelligence:** 182 | 183 | This section will show the methods and results of tasks such as 184 | infrastructure mapping, port scanning, and architecture assessment and 185 | other foot printing activities. This section will focus on the 186 | techniques used to profile the technology in the CLIENT environment by 187 | sending traffic DIRECTLY to the assets. 188 | 189 | **Corporate Intelligence:** 190 | 191 | Information about the structure of the organization, business units, 192 | market share, vertical, and other corporate functions should be mapped 193 | to both business process and the previously identified physical assets 194 | being tested. 195 | 196 | **Personnel Intelligence:** 197 | 198 | Any and all information found during the intelligence collection phase 199 | which maps users to the CLIENT organization. This section should show 200 | the techniques used to harvest intelligence such as public/private 201 | employee depots, mail repositories, org charts and other items leading 202 | to the connection of employee/company. 203 | 204 | **Vulnerability Assessment:** 205 | 206 | Vulnerability assessment is the act of identifying the POTENTIAL 207 | vulnerabilities which exist in a TEST and the threat classification of 208 | each threat. In this section, a definition of the methods used to 209 | identify the vulnerability as well as the evidence/classification of the 210 | vulnerability should be present. In addition this section should 211 | include: 212 | 213 | - Vulnerability Classification Levels 214 | - Technical Vulnerabilities 215 | 216 | - OSI Layer Vulns 217 | - Scanner Found 218 | - Manually identified 219 | - Overall Exposure 220 | 221 | - Logical Vulnerabilities 222 | 223 | - NON OSI Vuln 224 | - Type of vuln 225 | - How/Where it is found 226 | - Exposure 227 | 228 | - Summary of Results 229 | 230 | **Exploitation/ Vulnerability Confirmation:** 231 | 232 | Exploitation or Vulnerability confirmation is the act of triggering the 233 | vulnerabilities identified in the previous sections to gain a specified 234 | level of access to the target asset. This section should review, in 235 | detail, all of the steps taken to confirm the defined vulnerability as 236 | well as the following: 237 | 238 | - Exploitation Timeline 239 | - Targets selected for Exploitation 240 | - Exploitation Activities 241 | 242 | - Directed Attack 243 | 244 | - Target Hosts unable to be Exploited 245 | - Target Hosts able to be Exploited 246 | 247 | - Individual Host Information 248 | - Attacks conducted 249 | - Attacks Successful 250 | - Level of access Granted +escalation path 251 | - Remediation 252 | 253 | - Link to Vuln section reference 254 | - Additional Mitigating technique 255 | - Compensating control suggestion 256 | 257 | - Indirect Attack 258 | 259 | - Phishing 260 | 261 | - Timeline/details of attack 262 | - Targets identified 263 | - Success/Fail ratio 264 | - Level of access granted 265 | 266 | - Clientside 267 | 268 | - Timeline/details of attack 269 | - Targets identified 270 | - Success/Fail ratio 271 | - Level of access granted 272 | 273 | - Browser Side 274 | 275 | - Timeline/details of attack 276 | - Targets identified 277 | - Success/Fail ratio 278 | - Level of access granted 279 | 280 | **Post Exploitation:** 281 | 282 | One of the most critical items in all testing is the connection to 283 | ACTUAL impact on the CLIENT being tested. While the sections above relay 284 | the technical nature of the vulnerability and the ability to 285 | successfully take advantage of the flaw, the Post Exploitation section 286 | should tie the ability of exploitation to the actual risk to the 287 | business. In this area the following items should be evidenced through 288 | the use of screenshots, rich content retrieval, and examples of real 289 | world privileged user access: 290 | 291 | - Privilege Escalation path 292 | 293 | - Technique used 294 | 295 | - Acquisition of Critical Information Defined by client 296 | - Value of information 297 | - Access to core business systems 298 | - Access to compliance protected data sets 299 | - Additional Information/Systems Accessed 300 | - Ability of persistence 301 | - Ability for exfiltration 302 | - Countermeasure Effectiveness 303 | 304 | This section should cover the effectiveness of countermeasures 305 | that are in place on the systems in scope. It should include 306 | sections on both active (proactive) and passive (reactive) 307 | countermeasures, as well as detailed information on any incident 308 | response activities triggered during the testing phase. A listing 309 | of countermeasures that were effective in resisting assessment 310 | activities will help the CLIENT better tune detection systems and 311 | processes to handle future intrusion attempts. 312 | 313 | - Detection Capability 314 | 315 | - FW/WAF/IDS/IPS 316 | - Human 317 | - DLP 318 | - Log 319 | 320 | - Response & effectiveness 321 | 322 | **Risk/Exposure:** 323 | 324 | Once the direct impact to the business is qualified through the evidence 325 | existing in the vulnerability, exploitation and post exploitation 326 | sections, the risk quantification can be conducted. In this section the 327 | results above are combined with the risk values, information 328 | criticality, corporate valuation, and derived business impact from the 329 | pre engagement section. This will give the CLIENT the ability to 330 | identify, visualize and monetize the vulnerabilities found throughout 331 | the testing and effectively weight their resolution against the CLIENTS 332 | business objectives. This section will cover the business risk in the 333 | following subsections: 334 | 335 | - Evaluate incident frequency 336 | 337 | - probable event frequency 338 | - estimate threat capability (from 3 - threat modeling) 339 | - Estimate controls strength (6) 340 | - Compound vulnerability (5) 341 | - Level of skill required 342 | - Level of access required 343 | 344 | - Estimate loss magnitude per incident 345 | 346 | - Primary loss 347 | - Secondary loss 348 | - Identify risk root cause analysis 349 | 350 | - Root Cause is never a patch 351 | - Identify Failed Processes 352 | 353 | - Derive Risk 354 | 355 | - Threat 356 | - Vulnerability 357 | - Overlap 358 | 359 | **Conclusion:** 360 | 361 | Final overview of the test. It is suggested that this section echo 362 | portions of the overall test as well as support the growth of the CLIENT 363 | security posture. It should end on a positive note with the support and 364 | guidance to enable progress in the security program and a regimen of 365 | testing/security activity in the future to come. 366 | -------------------------------------------------------------------------------- /_build/html/faq.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | FAQ — pentest-standard 1.1 documentation 8 | 9 | 10 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 70 | 71 |
75 | 76 |
77 |
78 |
79 | 86 |
87 |
88 |
89 |
90 | 91 |
92 |

FAQ

93 |
94 |

Q: What is this “Penetration Testing Execution Standard”?

95 |

A: It is a new standard designed to provide both businesses and 96 | security service providers with a common language and scope for 97 | performing penetration testing (i.e. Security evaluations). It started 98 | early in 2009 following a discussion that sparked between some of the 99 | founding members over the value (or lack of) of penetration testing in 100 | the industry.

101 |
102 |
103 |

Q: Who is involved with this standard?

104 |

A: We are a group of information security practitioners from all 105 | areas of the industry (I.e. Financial Institutions, Service Providers, 106 | Security Vendors). The group currently consists of:

107 | 153 |
154 |
155 |

Q: So is this a closed group or can I join in?

156 |

A: We started this with about 6 people, the first in-person meeting 157 | held almost 20. We would love more insight and down-to-earth opinions so 158 | if you can contribute please feel free to email us.

159 |
160 |
161 |

Q: Is this going to be a formal standard?

162 |

A: We are aiming to create an actual standard so that businesses can 163 | have a baseline of what is needed when they get a pentest as well as an 164 | understanding of what type of testing they require or would provide 165 | value to their business. The lack of standardization now is only hurting 166 | the industry as businesses are getting low-quality work done, and 167 | practitioners lack guidance in terms of what is needed to provide 168 | quality service.

169 |
170 |
171 |

Q: Is the standard going to include all possible pentest scenarios?

172 |

A: While we can’t possibly cover all scenarios, the standard is 173 | going to define a baseline for the minimum that is required from a basic 174 | pentest, as well as several “levels” on top of it that provide more 175 | comprehensive activities required for organizations with higher security 176 | needs. The different levels would also be defined as per the industry in 177 | which they should be the baseline for.

178 |
179 |
180 |

Q: Is this effort going to standardize the reporting as well?

181 |

A: Yes. We feel that providing a standard for the test without 182 | defining how the report is provided would be useless. We will define 183 | both executive (business) reporting as well as technical reporting as an 184 | integrated part of the standard.

185 |
186 |
187 |

Q: Who is the intended audience for this standard/project?

188 |

A: Two main communities: businesses that require the service, and 189 | service providers. For businesses the goal is to enable them to demand a 190 | specific baseline of work as part of a pentest. For service providers 191 | the goal is to provide a baseline for the kinds of activities needed, 192 | what should be taken into account as part of the pentest from scoping 193 | through reporting and deliverables.

194 |
195 |
196 |

Q: Is there a mindmap version of the original sections?

197 |

A: Following popular demand, we have _a_ version of the mindmap 198 | used when creating the first drafts of the standard available for 199 | download 200 | here 201 | (in FreeMind format).

202 |
203 |
204 | 205 | 206 |
207 |
208 |
212 | 213 |
214 | 215 |
216 |

© Copyright 2016, The PTES Team.

217 |
218 | 219 | Built with Sphinx using a 220 | theme 221 | provided by Read the Docs. 222 | 223 | 224 |
225 |
226 |
227 |
228 |
229 | 234 | 235 | 236 | --------------------------------------------------------------------------------