Skip to main content

What are the Penetration Testing Methodologies? Explain it.

An open-source security testing methodology manual (OSSTMM) basically includes almost all the steps involved in a penetration test. The methodology employed for penetration test is concise yet it’s a cumbersome process which makes it difficult to implement it in our everyday life. Penetration tests, despite being tedious, demands a great deal of money out of company’s budgets for their completion which often are not met by a large number of organizations NIST, on the other hand, is more comprehensive than OSSTMM, and it’s something that you would be able to apply on a daily basis and in short engagements. The screenshot indicates the four steps of the methodology, namely, planning, discovery, attack, and reporting. The testing starts with the planning phase, where how the engagement is going to be performed is decided upon. This is followed by the discovery phase, which is divided into two parts—the first part includes information gathering, network scanning, service identification, and OS detection, and the second part involves vulnerability assessment. After the discovery phase comes the attack phase, which is the heart of every penetration test. If you are able to compromise a target and a new host is discovered, in case the system is dual-homed or is connected with multiple interfaces, you would go back to step 2, that is, discovery, and repeat it until no targets are left. The indicating arrows in the block phase and the attack phase to the reporting phase indicate that you plan something and you report it—you attack a target and report the results. The organization also has a more detailed version of the chart discussed earlier, which actually explains more about the attack phase. It consists of things such as “gaining access,” “escalating privileges,” “system browsing,” and “install additional tools.” We will go through each of these steps in detail in the following chapters.
As you might have noticed, both the methodologies focused more on performing a network penetration test rather than something specifically built for testing web applications. The OWASP testing methodology is what we follow for all “application penetration tests” we do here at the RHA InfoSEC. The OWASP testing guide basically contains almost everything that you would test a web application for. The methodology is comprehensive and is designed by some of the best web application security researchers


Comments

Popular posts from this blog

40 easy ways to make money quickly

On this page you'll find all the best ways to make money in your spare time whilst at university based on our own experience. We'll keep adding new ways to this page so go ahead and bookmark it. And please do share your own ideas in the comments! Top ways to make money online and offline No-risk matched betting Hands down the quickest way to make a  lot  of money (well, without breaking the law). Lots of students have genuinely made £100s from this technique. It's completely legal, risk free, tax free, and anyone can do it. It works by taking advantage of free bets regularly offered by betting sites through ‘matching' them at a betting exchange. Matched betting eliminates the risk (you are betting both  for  and  against  a certain outcome). This leaves you being able to squeeze out the free bet, which can be as much as £200! Multiply this by how many betting sites there are and you can quite easily come away with a profit of a few hundred poun...

How to write report in ethical hacking?

……..continue of report writing …….. 4. Correct spelling and grammar is important too. A misspelled word leaves a very negative impact upon the person who is reading your report. So, you should make sure that you proofread your report and perform spell-checks before submitting it to the client. 5. Always make sure that you use a consistent voice and style in writing a report. Changing the voice would create confusion in the reader; so you should choose one voice and style and stick to it throughout your report. 6. Make sure you spend time on eliminating false-positives (vulnerabilities that are actually not present), because false-negatives will always be there no matter what you do. Eliminating the false-positives would enhance the credibility of the report. 7. Perform a detailed analysis of the vulnerability to find out its root cause. A screenshot of a RAW http request or the screenshot that demonstrates the evidence of the finding would give a clear picture to the developer of the st...