Basics and concepts of information security monitoring

What are security incidents? What should be collected and when should an alarm be raised?

Easy
10 min

What are security incidents?

Cybersecurity incidents are events or actions that indicate a possible security breach or threat in an organization's information systems. They can range from any suspicious login attempts to a serious data breach. Identifying cybersecurity incidents and handling them properly are essential parts of companies' and organizations' security policies. Monitoring and analyzing cybersecurity incidents help organizations identify and mitigate threats before they can cause significant damage.

Events come from many different sources, such as operating systems, security products (firewall, antivirus, ids/ips, etc.), applications, servers, databases, etc. logs.

What should be collected?

By default, all events involving information that needs to be protected should be recorded and stored. This is because when a cybersecurity breach occurs, you will be able to determine exactly what happened and assess the extent of the damage.

Let's consider the same scenario with this information and without it.

Scenario: You have 1000 business customers. A criminal hacks into your service and steals 200 lines of information in total from six different customers.

  • If you have good logs: You have to notify six business customers that their information has leaked and you can tell exactly what information has leaked and how much.
  • If you don't have good logs and don't know whose customer data has been stolen and how much, you will have to notify every thousand customers that their data may have been stolen and you don't know how much.

Where to raise an alert?

A cybersecurity alert should be made when a threatening situation is detected. There shouldn't be too many of these alerts to avoid alert fatigue, but on the other hand, there shouldn't be too few either because otherwise attacks may not be caught. Balance is important, and collecting the right logs and building an effective rule set require both technical expertise and a comprehensive understanding of the environment to be protected.

Every environment is unique, but here are some fairly universal examples of situations where an alarm should be raised.

Tiedonsiirron suojaaminen on kriittinen osa kyberturvallisuutta. Salattu tietoliikenne auttaa estämään tietojen luvatonta pääsyä ja varmistaa, että tiedot pysyvät turvassa.

HTTP messages to the background system that should not have been able to be sent through the user interface

This is one of the best and unfortunately least utilized ways to detect real attack attempts directly from the protected application itself. The method is as follows:

  • Create controls related to access management and input validation, both on the server side and the client side. In normal use, the input validation/access control controls on the server side should not be needed because they have already been verified on the client side.
  • If there are hits on those controls on the server side, it means that someone has bypassed the interface and sent HTTP messages directly (with burp, attack tool, etc.).
  • If this happens, raise the alarm immediately.
  • This approach also allows for automatic threat detection directly in the application. For example, the application can block a disruptive IP address after passing through 10 suspicious HTTP messages. Try scanning such an application with Burp :)

Matches to egress firewall rules

Alerting on hits of egress firewall rules is an excellent way to detect a very serious situation in which an attacker has already possibly executed arbitrary code in a protected environment, but establishing a command channel / data leakage attempt has been caught in an egress firewall rule.

This approach of course requires that network security controls are at a level where outbound traffic is blocked altogether. If they are, this alert should definitely be utilized.

Tervetuloa CyberSec-sivustolle!

WAF (Web Application Firewall) logs with the correct host header

If there is a WAF product in front of the application to be protected (as there should be), which automatically identifies and tries to prevent clearly malicious HTTP messages from reaching the protected application, its logs may be worth alarming. However, this is an important but, namely that WAF products catch noise coming from the Internet daily. However, the noise is typically directed at IP addresses, so the problem is easy to solve. Raise an alarm only when the host header matches the application's own URL. Then only targeted attacks are caught, and the noise can be left alone.

Tietojenkalastelu on yleinen huijausyritys, jossa pyritään hankkimaan henkilökohtaisia tietoja, kuten salasanoja ja luottokorttinumeroita, yleensä sähköpostitse tai verkkosivujen kautta.

Application error messages indicating injection vulnerability

Some application logs are ones that communicate a situation where the application may well have a serious vulnerability and that the attacker may well have just found it.

Let's take SQL injection as an example. It's possible that a developer has created a function where SQL is constructed insecurely, but the application has client-side control that transforms the input into a safe format. In this case, the error will never be revealed in normal use.

What happens when the application error log shows "SQL Syntax Error: Near ...WHERE..."? This could be a sign that an attacker has just tried to put a single quote in a parameter using Burp and the vulnerability has been revealed. It may not take many minutes before sqlmap is run and the database has changed ownership.

Cyber-uhkien kasvaessa on tärkeää suojata tietojärjestelmäsi asianmukaisesti. Tässä muutamia vinkkejä, jotka voivat auttaa sinua pienentämään riskiä joutua kyberhyökkäyksen kohteeksi:

Server environment malware protection alerts

Especially the server environment should be equipped with a HIDS/HIPS (host-based intrusion detection / prevention system) product such as Falco for Kubernetes/other container technologies or for example OSSEC for Linux servers. These products are able to detect deviations such as suspicious network connections, files, processes, or logins and generate alerts from them, and possibly even mitigate threats in real-time with products like fail2ban or OSSEC/Falco active response scripts.

Turvallisuusasiantuntijamme auttavat suojaamaan organisaatiotasi uhilta ja varmistavat, että tietosi pysyvät turvassa.

Workstation malware protection alerts

This may seem obvious, but when an alert comes from an employee's workstation, it may be necessary to quickly lock the employee's workstation. With EDR (endpoint detection and response) products, it is possible to centrally monitor alerts and, for example, temporarily isolate an infected workstation from the Internet.

Bottom line

Enabling effective cybersecurity monitoring requires creativity, technical expertise, and a comprehensive understanding of the target to be protected. In a large company, this complexity inevitably divides between several people and likely several different business units, making communication within the company critical.

Large companies have a SOC (security operations center) whose task is to correlate security events from the vast amount of events in the company and to search for patterns that indicate threats. By actively collaborating, for example, with developers from different units to first of all ensure that the applications and their operating environments produce the correct logs and secondly to convey information to the SOC about which alerts are indicators of real threats, the company's ability to detect threats becomes very good.

hakatemia pro

Ready to become an ethical hacker?
Start today.

As a member of Hakatemia you get unlimited access to Hakatemia modules, exercises and tools, and you get access to the Hakatemia Discord channel where you can ask for help from both instructors and other Hakatemia members.