The external security review includes an overview of all servers, services and applications that are visible from the Internet and located at an IP address which has been publicly declared to belong to the client. The review provides information on:

• a complete inventory of servers, services and applications visible from the Internet,
• the technical data contained within these services, and applications that are visible to external users,
• a summary of the security assessment and the results of the security deficiency malpractice test,
• an overview of the detected and confirmed security deficiencies, including a more detailed description, an indication of the potential consequences of the abuse, and recommendations/instructions for their removal.

The external security review does not apply to applications and services hosed by third parties (example: the website of the contracting entity hosted by a provider of such service).

Furthermore, it does not necessarily include all manual methods, which are primarily used for more detailed detection of deficiencies in various web applications or other specific applications. As a rule, the service is limited to those defects that can be detected using different tools. The manual part is then intended to validate these defects, which means its purpose is not so much to discover any new/additional ones.

An external security review does not include documentation, security system settings, and source code for various applications. All these activities are included in other types of security checks.

It also does not include the DOS attack verifications (deficiencies that represent an attacker’s ability to disrupt the service operation).

Besides targeting only those parts of the system that are visible or accessible from the Internet, there are certain differences when it comes to the approach and methodology.

Testing is based on the use of different tools, which is important in comparing results and minimising the falsely perceived deficiencies (i.e. false-positives), as well as minimising the possibility of overlooking a specific deficiency (i.e. false-negative).

Manual work is primarily used to check further for perceived vulnerabilities rather than to detect new ones.

Since the service is based on the use of tools, it is aimed at detecting vulnerabilities arising from the operating system versions and/or services, as well as settings that directly affect the service operation. As a rule, specific defects unique to the contracting authority are not verified through such reviews.

One should always strive to confirm the perceived safety deficiencies. The method of perceiving deficiencies is based on two principles:

• During the execution, an attempt is made to determine the version of the operating system or the service. Once this information is obtained, all possible deficiencies of the system can also be known. However, these deficiencies may be real or indirect, i.e. false-positives. The servers and services accessible from the Internet are generally well protected, which means that it is not always possible to determine the exact version of the software. Sometimes, this information is only partially identifiable or even false, which makes it likely that the identified defects are, in fact, false.
• Another principle of identifying deficiencies is by actually testing the responses of applications and services. However, these responses generally look for symptoms rather than directly checking for deficiencies.

Therefore, the detected defects should always be checked in order to perform a precise review of the actual ones. In doing so, the unnecessary alerts are avoided, which gives credibility to the report.

The actual possibility of misuse in specific defects is always checked manually, as it is often necessary to use a specific parameter in the malpractice test, or else the malpractice test must be carried out in different ways.

A detailed written report consisting of two parts, which are presented in the form of a workshop:

• Management report
  It is a concise overview for executives, providing the basic cybersecurity information.
• Technical report
  It details the scope of perceived vulnerabilities and provides a description and assessment of the consequences, as well as the potential for abuse, while also detailing an overview of realistic misuse scenarios and recommendations for their abolition.

The answer is at any time. Public services are regularly targeted by attackers, which is why the risk of misuse is constant.

Here are some of the excuses or reasons for not performing the review that we often hear and that are extremely dangerous in terms of guaranteeing security:

• We plan to renovate the firewall next year, so it is best to carry out a review at that time. But what about security until such time?
• We do not have anything of the sort on our Internet network. Our website is hosted. As a company, we are less interesting to hackers, which is why a review is unnecessary. That is, of course, not true! Often, the Internet network reveals much more than the client is aware of. The fact also remains that attackers are never not interested in you. For example, they can exploit your weakness to further attack larger systems.
• We did a review a few years ago, but it showed nothing special. We have not changed anything since, so we are probably still safe. Again, not true! Attackers are constantly finding new ways of abuse.

A general opinion is that such a review should be carried out when it comes to changes in the environment. However, this is not necessarily true. Even if nothing changes in the system, the probability of a breach can still increase. Attackers are constantly discovering new ways of attacking web applications, so just because something was safe yesterday it might not be safe today.

It is in fact quite the opposite. If you have “not changed anything” in the system, it means you also failed to introduce new patches and upgrades of the operating systems and servers in the recent period, which makes the need for such a review even greater.