Simple basic principles of IT security

Preface

IT security nowadays is a huge area of operation. People working in ITSec are swamped with terms. The Market has also a large amount of security products.

While the admin thinks about how to integrate the new NetxGen2-SIEM-Firewall according to ITIL and must take the GDPR into account and also must urgently bother with APT, attackers are breaking into the web server by exploiting a long forgotten Wordpress plug-in.

It is time to liberate from the confusion of terms and the product glut of the ITSec industry. Time to take a step back and think about which basic principles form the essence of IT security.

1. Know your system

Get to know your system as good as possible. When you don't know your system you can't defend it. Understand which components and services your system is using. If you notice an unnecessary service, disable it (see also point 2. Keep your system small and simple). Identify which risks emerge by running those services.

Don't rely solely on external support (e.g. by the manufacturer). This will make you dependent on this support and can lead to catastrophic results, if the support doesn't answer or can't fix the problem. Using open source software can help because open source software is usually well-documented and therefore it's functionality can be learned easily.

Document your systems and components. A good overview is important to see where weak spots could arise.

Prevent that attackers know your systems better than you do. Use encryption in communication and on storage, if appropriate.

Watch system messages and system logs. Often they contain valuable hints. Even about where measures are still necessary.

2. Keep your system small and simple

Systems and applications should be as small and simple as possible. Complexity is the enemy of security. Always use the simplest system possible. On the one hand, this avoids complexity and, on the other, this saves resources.

Do not add more components or features to a system than absolutely necessary. Do not run more services run than absolutely necessary. Avoid all unnecessary software. This way the attack surface is reduced, as well as the probability that something can go wrong. If the system is too complex already at delivery, adjust it. It is helpful in this regard to use open source software.

Example: Refrain from using as web interfaces for the administration of a firewall. The web interface requires an HTTP server and implements an interface to translate the entries in the web interface in command line commands for the firewall. These are two additional but unnecessary attack vectors. Instead, learn to use the command line directly.

(Excursus: OpenBSD is considered the safest operating system in the world, not least because it is very slim compared to other operating systems. The Linux kernel consists of nearly 30 million lines of code, the OpenBSD kernel has just 2.9 million lines, thus 10% of the magnitude of the Linux kernel.)

Almost the same applies to data: delete sensitive data when it is no longer needed. Do not store data when it is not needed.

When granting permissions minimalism should prevail as well. Give each person and each process only the permissions that are absolutely necessary.

3. Use well-documented, open and common systems

This is a prerequisite for knowing what you are using. Avoid the use of “black boxes” whose contents you do not know. Again, it is an advantage to use open source software. Common and widely used open source software is well documented and the source code is open. However, avoid exotic software that hardly anyone uses and is poorly documented. Use robust and stable systems that are well tested.

4. Use information and communication

All too easily one isolates into a filter bubble and gets barely any information from the world out there, while attackers are constantly learning about new opportunities.

Interconnect with the “community”, i.e. with people who are facing similar problems. Communicate with them, e.g. via mailing lists. Go to community events focusing on security (but not on pure product promotional events from manufacturers). Good local addresses are often Linux User Groups and “LinuxFest” events.

Find out about new security vulnerabilities using CERTs and security mailing lists. This is a prerequisite for knowing your system (point 1.).

5. Check your systems

In order to know if your systems are running correctly and safe they need to be checked. Use monitoring to check your systems. Define parameters within which your systems should run. If a system is running outside these parameters, there should be alarm messages.

Observe system logs (see also point 2). Keep logs simple (in text format) and centralize logging. Use filters for log messages, so you will not be overwhelmed by the flood of messages.

Use information (see point 4.) to check if your systems have security vulnerabilities. Patch the systems fast, because attackers know the vulnerability at latest the same time as the patch is published.

6. Isolate your systems

Large all-in-one systems are often comfortable and convenient to use. Unfortunately, they are also very complex and therefore offer a large attack surface.

Systems and functions should therefore be separated as much as possible. This way, in case of problems, only one component is affected. Separate systems from each other on different levels. Use different network segments where appropriate. Use different hosts for individual services. Use virtualization, not containerization.

(Excursus: Although everyone is talking about Docker, Docker and other container systems should not be used for productive systems. Containers do run in the same kernelspace as the container host and other containers on it, meaning that if one container is successfully attacked, other containers running on the same physical machine are also affected. Containers do not provide sufficient isolation).

Use interfaces to establish communication between the isolated system and inspect them.

Each component should always do exactly one job, and this one well. Do not use universalists, but specialists. But do not forget that these should be simple and small.

7. Make your systems fault-tolerant

Ask for each system: “What if it fails? Is the entire structure affected, or can it continue to function without the system? “Create an emergency plan that tells you what to do when failures do occur. Because sooner or later every system will be disrupted or fail.

For critical systems, make sure that a backup system is promptly available (for example, design it as a highly available system). Current data needs up-to-date backups and should be able to be restored in a timely manner.

The smaller and simpler the systems are (point 2.) the easier they are to be made fault-tolerant. The isolation (point 6.) also helps to easily set up fault-tolerant systems.

Security measures can fail also. When an account or certificate is compromised, there must be measures to counteract the risks involved.

8. Pay attention to proportionality

Security costs time, money and effort. At each previous point one should ask oneself: Is that still proportionate?

You do not buy a 1000 $ safe to store 100 $ in it. It is therefore important to consider what the security measure is intended to protect and what effect the measure will have on operation. The database with the results of the company football team certainly needs less protection than the database containing the company patents (both are on the same server? Then you have disregarded point 6.)

A good way to determine the proportionality are the following questions:

  1. Does the system need to be protected and how far should protection measures go?
  2. Which safeguard has the least impact on ongoing operations?
  3. Which is the simplest and most cost-effective solution for the security measure? (Hint: often the answer is “open source software”).

Conclusion

Each of these basic principles is an important module. However, they are all more effective when they work together. If you memorize these basic principles, they can help you bring order into the flood of buzzwords from the itsec industry and to keep an overview of your network.

Knowing the systems, separating them, keeping them small and simple, and checking them can make the NextGen2 SIEM firewall obsolete. If you know the principles, you do not necessarily have to know ITIL and ISO 27001 in detail – much of what is in those standards are simply the outcome from the principles.

Further reading: The Information Security Practice Principles, Craig Jackson, Scott Russell, and Susan Sons, University Center for Applied Cybersecurity Research

© Henry Jensen 2019, licensed under CC-BY-SA 4.0