Get best of the week

New information security standards: make life more difficult for attackers

In the field of IT and information security, the concept of benchmark has long been established - it is a technical standard for setting up a specific operating system, network equipment, or server software. Such documents usually describe what and how it should work in the company's infrastructure, what aspects of protection it affects, how to check and configure everything. It sounds short and clear, but in practice it turns out to be more difficult.

In this article we will talk about the problems of modern technical standards (benchmarks) of information security and how they can be solved.

What modern benchmarks look like


For each system, these standards are different. The most famous in the world are the CIS Benchmarks family standards developed under the auspices of the international organization CIS by the help of invited expert enthusiasts from around the world.

Typically, these standard ones include hundreds of requirements that describe including:

  • password length and complexity;
  • access rights to files of different types;
  • Recommended for enabling and disabling services.

Pros and Cons of Existing Technical Standards


Like any toolkit, security benchmarks are useful in that they increase the average level of infrastructure security. This is reflected in the fact that an infrastructure configured at least according to the main benchmark recommendations is much more difficult to crack - at least with pentesters (in a number of such cases they generally fail to achieve their goals because of time limits or acceptable attack targets or acceptable attack methods )

Since each such standard is quite large, it can simply be used as a reference or check list, according to which the equipment and software are configured.

Benchmarks recognized abroad are familiar to companies from different countries, therefore they are aware of their advantages and strive to fulfill the requirements specified in the documents.

But not everything is so smooth in practice: the application of standards familiar to all is not without problems. Here are just a few of them.

There are a lot of requirements


If both the OS and a couple of server applications are installed on some node, then you will need to apply several standards, and the total number of requirements can easily exceed 500. Here is a simple arithmetic for the case of a typical large organization:

  1. Workstations: more than 500 requirements for Windows and MS Office, the number of nodes - from a thousand.
  2. Servers: depending on the OS and installed server software, from 100 to 700 requirements per node, the number of nodes is hundreds.
  3. Network equipment: depending on the brand, model and functionality from 20 to 80 requirements per node, the number of nodes is hundreds.

The lower bound of the assessment is 500 thousand requirements for the entire infrastructure. It is logical that it is impossible to ensure compliance of all its units with all the requirements of such standards, as well as to track the fact of compliance with these requirements.

An important consequence also follows from the overly large number of requirements and nodes in the infrastructure under control: the duration and laboriousness of automated scanning, even parts of the infrastructure, as a rule, do not suit either IT administrators or information security specialists. In order to somehow check all the nodes, you have to go to various tricks: assign certain “technological windows” for different groups of nodes, scan less often than we would like.

At the same time, one still has to carefully monitor the availability of the network of remote branches and its bandwidth (in some cases it is satellite channels, which adds complexity), try not to get confused by the frequency of scans, and just find the time to solve the scanning problems that arise.

Difficult to prioritize


In standard sets of requirements, there is usually no division into more or less important ones; as a result, it is extremely difficult to select and implement only those that affect resistance to break-ins. There are some examples of attempts to introduce such a separation, but so far they are not very successful: CIS experts recently began to divide their requirements into two significance groups, but in the end both groups turned out to be very large anyway, and this step did not solve the problem.

A number of organizations are striving to create their own standards for secure settings based on CIS, the number of requirements in which is less than the original. However, in the case of companies in other areas, specialists often lack specialized knowledge.

It is not clear what exactly a particular requirement affects.


When reading the requirements of the standards, it is often not clear which of them are related to practical security and will help protect against hacking, and which are needed for everything to work correctly. To understand this, you need to understand at a deep level the system for which the benchmark is written.

There is no incentive to use technical standards


To achieve the requirements of many benchmarks on many nodes is a huge, complex and intense work. Moreover, if the IT specialist involved in infrastructure does not even understand what exactly will give the fulfillment of certain requirements to an already working system - there is no incentive to use this.

How to solve these problems: PT Essential standards


The main problems of today's standards in information security are their huge size and general non-specificity. If these two shortcomings are not eliminated, the benefits of such standards will always be limited.

To solve these problems, for various target systems, we have developed the standards of the new generation PT Essential (PTE) and implement them in MaxPatrol 8 . New documents were created on the basis of existing benchmarks (for example, CIS) and information about real security problems obtained from penetration testing by our experts. In doing so, we use the Pareto 20/80 principle — usually a smaller part of the requirements allows us to close a large number of possible security problems.

In practice, usually most of the penetration testing ends with the success of the attackers. One of the main reasons is that organizations do not follow even the simplest and most critical protection recommendations, including:

  • password complexity *,
  • password change frequency
  • Deprecated OS and software.

* The results of tests of the security level of systems conducted by Positive Technologies showed that the vast majority of passwords successfully selected during testing of password protection were compiled in a predictable way. Half of them were associated with various combinations of the month or season with numbers indicating the year (for example, Fduecn2019, Winter2019). Passwords of the type 123456, 1qaz! QAZ, Qwerty1213, which are made up of nearby keys on the keyboard, came in second place in terms of prevalence.

In the new standards, we tried to take into account the experience of the pentests conducted by our team in hundreds of companies to help them close at least the most obvious attack vectors. Even such basic actions seriously complicate the life of the attacker and make the attack on the company less attractive.

Here are the key differences between the new benchmarks:

  • Each of them contains a minimum of requirements - only those that directly affect the security of the system are included. The number of PTE requirements for each target system is N (N - from 3 to 10) times less than the CIS counterpart. As a result, they are proportionally reduced:
    • scan time
    • labor costs for analysis of scanning and elimination of found shortcomings.

  • For most requirements of the standard, CVSS metrics are assigned - similar to vulnerabilities. This allows you to immediately prioritize the elimination of shortcomings.
  • The description of all requirements describes the consequences that the organization may face if it does not fulfill it.

Below is a brief comparison of the CIS Benchmarks and PT Essential families:
CriterionCIS BenchmarksPT Essential (PTE)
Number of requirementsUp to 400 per standardNo more than 40 per standard
Incorporating requirements into the
secure configuration standard		Everything related
to
protection subsystem settings		Only that is
directly related to
hacking (protection against hacking)
Ability to prioritize
requirements		2 (
):
,


— CVSS
( )
,
.

,
,
.
—

( )

Here is an example of a PTE requirement (the examples below relate to UNIX systems; instead of separate standards for each UNIX-like operating system, a single standard has been created for all such systems supported by MaxPatrol 8):

Example requirement "Disable passwordless remote logon for rlogin / rsh"


  • The configured rlogin / rsh services allow you to log in without specifying a password.
  • They can be configured for all users (set in /etc/hosts.equiv), and individually for each user (in $ HOME / .rhosts).
  • With these settings, users can log in to the target server from the specified clients without entering a password on the target server.
  • In addition, R-subsystems suffer from ARP spoofing attacks, since the trust criterion is based only on client addresses.
  • Using these obsolete subsystems poses an extremely serious risk, so it is strongly recommended that they be disabled.
  • All application and system software using these tools support SSH as a much safer alternative.


CVSS: 3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (8.8)

Example requirement “Exclude dangerous commands from sudo settings”


Incorrect sudo settings may allow the user with the right to execute some (potentially dangerous) commands as root to the user:

  1. increase privileges in the system,
  2. overwrite system files, disrupting the system.

Potentially dangerous can be any command that allows you to:

  • write to an arbitrary (user-specified) file;
  • write to one of the system files;
  • destroy the file system or disk partition.

It is necessary to exclude dangerous commands from sudo settings.

CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (7.8)

« »


  • , , . , , — .
  • 755 , root ( ).
  • , , . root, .

CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (7.8)

Important : on a mandatory basis, each requirement contains guidance on resolving security flaws and checking for problems.

Conclusion


Technical standards in information security is an important tool to increase the level of infrastructure security, greatly complicating the life of attackers with proper implementation and good interaction between the IT and IS departments. However, many modern standards are too complex and voluminous for practical application.

It is much more convenient to use the standard PT Essential families - the new generation benchmarks that bring only the most important information and are based on the experience of hundreds of penetration tests. When implementing IT departments and information security specialists, it’s clear which requirements are most significant, where to start, and what problems can arise if these requirements are not met.

The application of PT Essential requirements allows you to quickly identify and resolve the most important security problems in the infrastructure with a noticeable reduction in the complexity and complexity of this process. So why not make life harder for pentesters and intruders? ..

More articles:


All Articles