An internal security review includes an overview of all servers, services and applications visible from individual network segments. At least part of the verification is performed several times from different points in the network. Namely, it makes sense to find out what is available from where.

An additional feature is an overview of the network topology and adequacy of internal filter settings as well as similar security mechanisms. The review provides information on:

• a complete inventory of servers, services and applications visible from specific network segments,
• the technical data contained within such services and applications that are visible to internal 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 internal security review does not necessarily include all manual methods, which are more suitable for a detailed detection of deficiencies in various web applications or other specific applications. As a rule, the service is focused on those defects that can be detected using different tools. The manual part is intended to validate these defects, which means its purpose is not so much to discover any new/additional ones.

This kind of review also does not include the DOS and similar attacks that can cause malfunction of the information system.

An internal security review is necessary and important mostly from two aspects:

• The internal users can always be a source of security threats. A dissatisfied user can quite easily acquire unauthorised access to important data and systems, as the internal security mechanisms are limited. It is important to know what an individual can be prone to misuse.
• External attackers can perform the attack through social engineering or perform other similar attacks to acquire access to users’ internal workstations. In the event of such attacks, it is really important to know what is visible from the internal workstation rather than to what degree can vulnerable services and applications be directly visible from the network (Internet).

The difference between an internal security review and an external security review is that the former is performed from different points in the internal network. At the same time, it includes a review of the documentation, verification of the security system settings, etc.

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 repeatedly discover new forms of misuse.

A general opinion is that such a review should be carried out when it comes to changes in the IT 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.

As a rule, the review is best carried out periodically. An internal security review should be carried out once every 6 months or at least every 12 months. It also makes sense to switch security review providers, as each contractor has their own experiences, tools and methodology.