What are penetration tests?

Penetration testing can be defined as a legitimate and authorized attempt to find andexploit security vulnerabilities in computer systems to improve the security of these systems. This process includes testing vulnerabilities as well as providing complete evidence of a so-called "vulnerability" attack. POC (proof of concept). This is to confirm that the reported security errors are usable. In addition, penetration tests end with specific recommendations. These include how to fix errors detected during a test. To sum up, this process is designed to help protect computers and networks from future attacks. Penetration tests are also known under names such as pentesty, PT, Hacking,Ethical Hacking,White Hat Hacking. An important selection is to see the difference between penetration tests and risk assessment or audits. The auditor asks , "do you have backups?" and the pentester informs you , "we have your backups" ????. Many people (and businesses) in the security community use these notions interchangeably.Risk assessment is a process of reviewing services and systems focusing on potential security issues, while penetration tests through exploitation and real attacks indicate security errors that actually exist. Conducting penetration tests goes beyond assessing vulnerabilities by simulating hacker activity and delivering ready-made attack vectors. Penetration tests can be divided into several categories, taking into account the following factors:

  • the level of knowledge available;
  • the scope of the test;
  • the composition of the test team;
  • how the tests are carried out;
  • location of the tests;
  • location in the SDLC cycle(development life cycle);

The following is a classification of penetration tests based on the above criteria: (a) the level of knowledge available:

  • blackbox – a method in which the tester has a minimum amount of information about the attacked system. Typically, this is only information about the scope of the tests. This is to simulate a hack attack from the outside (the attacker tries to hack into a system about which he knows nothing);
  • greybox – a method in which the tester has a certain level of knowledge about the system, but without access to the source codes. It typically has visibility into the data structure, e.g. through a low-privilege user account that is shared with it. This attack is intended to simulate a hacking attack from within the company (the attacker is an employee of the company, or has an account in the system);
  • whitebox – a method in which the test person has full access to the technical documentation. This test is mainly intended to review the source code and locate security errors in it;

(b) the scope of the test:

  • invasive tests, which consist in simulating a real attack, e.g. modifying data or blocking the service. They thus affect the functioning of the system;
  • non-invasive tests, which are the opposite of invasive tests, so they do not affect the functioning of the system. They rely on finding vulnerabilities without practical verification, e.g. by reviewing the source code.

(c) the composition of the test team:

  • tests carried out by the company's internal employees;
  • third-party research;
  • tests carried out by mixed composition, i.e. internal employees of the company and employees of a third party;

(d) how the tests are carried out:

  • expert tests, carried out manually, that is, manually by a qualified specialist;
  • automated tests carried out using dedicated tools e.g. network scanners, source code analyzers;
  • mixed tests involved both manual and automated tests;

(e) test locations:

  • internal tests, consist of simulating an attack from within the company bypassing security such as firewalls, most often using intranets;
  • external tests, consist of simulations on an external attack, e.g. via the Internet. In this case, the attacker has in his way to overcome firewall mechanisms or application filters;

(f) system development lifecycle (SDLC):

  • tests during software development. so-called test driven development;
  • acceptance tests, performed on the already created software.

Chcesz wiedzieć więcej?

Zapisz się i bądź informowany o nowych postach.

Nigdy nie podam, nie wymienię ani nie sprzedam Twojego adresu e-mail. W każdej chwili możesz zrezygnować z subskrypcji.

Bookmark the permalink.

Podziel się swoją opinią na temat artykułu