IT system security under GDPR

General Security of Applications

Application Architecture

Creating web systems (generally speaking – IT systems) is akin to building a house. Before we commence development work, we must prepare a plan and design the architecture.

What architecture is the best? This question cannot be answered definitively. Much depends on the environment in which the application operates.

Currently, an increasing number of applications are being built in the cloud. These are often large projects. The architecture of these applications consists of many microservices, which are several mini-applications responsible for individual services. Combined into one system, they provide a web application that we see in the browser. From the perspective of the performance of such an application, its scalability, or security, this is a significant advantage.

The remaining architectures do not rely on microservices. They are often three-tier, two-tier, or even single-tier applications. The layers of the application represent a physical or logical division of its components into individual functions. From a security standpoint, a three-layer division may be the most optimal. In practice, it looks like this: Application Data → Application Logic Server → Web Page

In this model, the only element publicly accessible to any Internet user should be the WWW part. This is the presentation layer, or the application layer, where the application interface resides. It is in this layer that the interaction between the user and the application occurs. This is also where all data collection from the user takes place.

The heart of the application is the server responsible for its direct operation and all operational logic. Therefore, this middle layer is often referred to as the application logic layer. At this level, all requests directed by users, which have passed through the web server and filtering mechanisms, are processed.

The foundation of every system is a database containing records that the application processes. The database is primarily responsible for storing data, but also, for example, any consents expressed by the user while using the system (such as consents for marketing communication).

It is important that the communication between the presentation layer and the database goes through the application logic layer. Proper implementation of the application logic layer can protect the application from SQL Injection attacks. Often, the two highest layers – the application server along with the web server – constitute a single physical entity, with separation occurring only at the logical level. For some systems, this may not pose a significant security flaw – of course, provided that traffic filtering is applied between the individual layers and the database is separated.

Security of Response Headers

Considerations regarding the security of headers should begin with an introduction to how HTTP communication works and what constitutes a request and a response.
Every action performed in a web application (e.g., logging in) triggers the sending of a so-called client request to the server "underneath." In response, we receive a server reply, and on the browser screen, we see the page displayed by the server. Each request and each response contains headers with information.

Headers sent by the application server can be a source of much information for attackers. Therefore, it is advisable to ensure that:

• headers do not contain sensitive information about components (e.g., the version of the server's operating system),
• the response includes the header: X-Content-Type-Options: nosniff,
• the response includes the header: Strict-Transport-Security (in every response and for every subdomain),
• the referrer-policy header is appropriately configured, as it may reveal information about the page from which the user was redirected, i.e., their previous location.

Hidden Directories

It is undoubtedly essential to disable directory listing when publicly sharing a web application. This can prevent potential viewing of the contents of directories and files on the server sequentially through the browser. It would be a gift for an attacker who could easily browse the server's files (and the application) and, consequently, come across sensitive data or information that would facilitate breaching the system's security.

It is also important to verify the access granted to directories and metadata of applications. Directories containing application configuration files, source code elements, or backups must not be publicly accessible. It is particularly important to ensure that metadata such as Thumbs.db, .DS_Store, .git, .svn is hidden. Access to such data should be restricted.

Input Data Verification

In the context of security, it is crucial for the application to verify input data. The absence of such a mechanism can lead to significant vulnerabilities, such as XSS vulnerabilities or SQL Injection.

It is essential to check all input data (e.g., data entered in form fields) based on an appropriate validation list that specifies what type of data may be present in a given field. A good practice is to verify data according to a schema. This means that the data in a specific field must have the appropriate length or specific characters. An example could be a field for entering a phone number.

All files uploaded by users should be stored outside of main folders, with restricted permissions. Such files should first undergo a detailed examination for the presence of malicious code. It is advisable that the application’s network layer does not accept files with compressed file extensions, backup files, or temporary files.

It is important to ensure that users can upload only a specific range of files (e.g., a specified format) to the application and cannot execute these files on the server. This will reduce the risk that a potential cybercriminal could easily add a so-called web shell (a small file allowing code execution on the server) to the server using just a browser and then execute it on that server.

WAF Firewall

The WAF (Web Application Firewall)  is one of the fundamental elements of web application security. It can be compared to a firewall protecting infrastructure, which is responsible for filtering and blocking unwanted traffic to the application. The application and the WAF operate in a similar manner.

According to the PCI DSS standard, the WAF is a point of enforcement for security policies placed between the web application and the client endpoint. This functionality can be implemented in software or hardware running on a device or on a typical server where a common operating system operates. It can be a standalone device or integrated with other network components.

 The WAF operates in two basic models:

• rule-based – similar to a “regular” firewall, the WAF uses a set of rules, allowing it to distinguish malicious requests from the overall requests,
• learning – based on user behavior, the WAF learns to distinguish malicious behaviors on its own and then automatically adds rules.

The rules that the WAF “knows” can be utilized in three modes:

• negative (blacklist) – the set rules aim to block clearly unwanted (malicious) traffic as well as traffic attempting to exploit specific vulnerabilities. This is the optimal operating mode for an application firewall operating in a public network. It can be effective, for example, in the case of DDoS attacks,
• positive (whitelist) – the WAF only allows specific traffic (configured in the rules). An example could be configuring the WAF to accept HTTP GET requests or requests only from specific IP addresses. This solution is likely to be effective in blocking various cyberattacks, but it may also block a significant amount of legitimate traffic. Therefore, this mode of operation of the WAF is best suited for protecting applications operating in an internal network, where there is a limited audience,
• hybrid – a combination of the two aforementioned modes. Whether the hybrid mode is suitable for publicly accessible applications or for internal applications depends on the configuration of the WAF.

When configuring the WAF, it is important to keep in mind that an attacker may attempt to bypass it in various ways, for example, by adding an appropriate header in the sent request.

Management of Updates and Vulnerabilities

Without a doubt, appropriate oversight of IT system updates and maintaining all current components that make up this system are among the pillars of its security. Criminals often scan web applications available online for their technical vulnerabilities existing in various places, such as servers on which the application is installed, libraries, etc. Regular updates will minimize the risk associated with the occurrence of technical vulnerabilities in the system, thereby limiting potential attack vectors against this system.

In addition to regular updates, administrators should ensure the verification of vulnerabilities in the application. Systems, especially those accessible on the open Internet, should be periodically scanned for the existence of vulnerabilities. The frequency of scanning should be determined after conducting an internal risk analysis. Subsequently, based on the adopted plan for addressing identified vulnerabilities, administrators should focus on either eliminating or mitigating them.

It is also worthwhile to periodically engage in a higher level of vulnerability assessment provided by penetration testing. During such tests, auditors examine the application for the existence of vulnerabilities and attempt to breach its security. The tests conclude with a report that shows what specific vulnerabilities exist in the system and how they should be eliminated. By eliminating vulnerabilities, we reduce the likelihood that a criminal will encounter them and attempt to exploit them to breach our system.

Authentication Security

Contemporary systems should be characterized by the implementation of strong user authentication principles. This means creating a login policy resistant to brute-force password cracking attempts, guessing, comparison, or incorrect resetting.

The security principles of systems should also take into account situations where a user's password is compromised or when the user simply forgets it.

Password Policy

Let us start with the basics – the password set by the user must be strong. Many of us remember the rule: “eight characters, a mix of upper and lower case letters, a digit, and a special character make a strong password.” While this may have been true at one time, currently, a password created according to this rule is relatively easy to crack. A good password is one that has an appropriate length. It is generally accepted that this is at least 12 characters. We must remember that computers are becoming increasingly powerful, and therefore, in some time, even this length may no longer be sufficient.

It is worth considering the implementation of mechanisms that block users from setting already compromised, or at least the most commonly used passwords. Such lists are available on the Internet, for example: https://github.com/danielmiessler/SecLists/tree/master/Passwords.

How else can we secure the authentication process? In practice, password attacks can be limited by blocking user account login after several incorrect password attempts. After the first five failed login attempts, we can allow for a temporary account lock (e.g., 30 minutes). After the next cycle of unsuccessful logins, the ability to unlock the account of a given user should only be available to the administrator of the system. To block attempts at brute-forcing the password in the system, during the account unlocking process, the administrator should thoroughly verify the identity of the user.

Two-Factor Authentication

A user who wants to prove their identity in the system should use not only something they know (i.e., a password) but also something they have (e.g., a key or token). This is due to a simple reason – passwords, or rather their hashes, leak. User passwords are often compromised as a result of phishing attacks. An additional layer of security in the authentication mechanism ensures that even if an unauthorized person gains access to the password, they will not be able to log into the system because they will not possess the second factor.

There are many methods of two-factor authentication (2FA). Currently, the four most popular methods are:

• SMS codes,
• a call to the user's phone,
• authentication applications,
• U2F keys.

Let us examine their advantages and disadvantages.

Let us begin with the methods in which a code is used as a second authentication factor. In the case of an SMS code, the system sends it to a phone number. The user must then enter it to confirm their identity. Some authentication applications also operate based on code generation – the generated code must be entered into the system by the user. The principle itself seems quite simple, cost-effective, and secure – after all, the code arrives at our phone number or we generate it ourselves. Unfortunately, reality (especially in the digital world) is much more complex. Criminals often use tools that allow them to intercept all the information we enter into the system in real-time (e.g., using tools that operate on the principle of reverse proxy). It is therefore easy to deduce that if we were to fall victim to such an attack, the thief would first take over our login and password, and then the generated code – and would manage to log in before us. It is worth noting that an additional burden when using SMS codes is the risk of SIM-SWAP attacks. As a result, an unauthorized person can take over our phone number, and consequently, receive SMS messages and calls.

Some authentication applications operate on different principles – they simply send a notification of a login attempt requesting approval. If this request is not accepted in the application, access to the account will not be possible. This protects the user in case their password is "only" compromised and an unauthorized person attempts to log in. However, it does not protect them against attempts to capture the password in real-time (similar to methods using codes). When an unsuspecting user tries to access their account at the same time as a criminal, it is likely that the criminal will send a request to the application for the victim to approve their login.

At this moment, U2F keys are the safest option. Why? The answer is simple: no methods have been found to compromise them so far. Even if someone knows the password, they cannot in any way take over the U2F key, as it is a physical device that is inserted into the computer. It is important to remember to block the user's ability to use other two-factor authentication methods when they configure the U2F key. If alternative authentication methods were available, a criminal could exploit them.

The only issues arising from the use of U2F keys are their high cost and low convenience of use. For this reason, organizations often choose to use other methods (SMS codes or authentication applications). However, if for some reason we cannot or do not want to implement physical keys as a security measure, it is worth considering other methods (SMS codes or applications) despite the risks. Not every attacker is capable of intercepting SMS codes or signals from applications, so it is much better to have any form of multi-factor authentication configured than to have none at all.

Account Enumeration

How should the system behave when the input information provided by the user does not match the actual data assigned to the identity of a specific person? Of course, the login mechanisms should reject the access attempt. It is also important to pay attention to the feedback provided to the person attempting to log in (authorized or not). Mistakes are often made in this regard. Criminals exploit poorly configured systems to first obtain information on whether there is any account in the system for a given login. After the criminal submits the input data, the system returns feedback such as: “The account does not exist” – in the case of an incorrect login or “Invalid password provided” – when the login exists in the system, but the provided password is incorrect.

It is therefore irrelevant whether the system received an incorrect login or an incorrect password. In response to the user, the system must not indicate which part of the data was incorrect. The "Production" system should return a message such as: "Incorrect login details provided" or "Email address or password is invalid."

Monitoring Account Activity

Monitoring account activity in systems is a very important element of the security structure. The login procedure should be configured to immediately alert administrators or security teams about suspicious activities on the user account or attempts to breach system security and log in. Suspicious accounts should then be blocked, and passwords for those accounts should be reset.

Users should also have access to their login history. It is beneficial when, after logging into the system, the user receives information about both the previous successful login and any failed attempts to access the account. With such a solution, they can check whether any unauthorized person has attempted to gain access to their account. In the event that the user identifies a failed or – worse – a successful login, they have the option to change their password and check the activity on their account.

Password Reminder

It may seem that the password reminder mechanism has little to do with security requirements. However, it is a very important component of access management systems. There are two reasons:

• the user must have the ability to reset their password if they forget it, so they can work in the system, especially if they hold a key role in the execution of certain business processes,
• and most importantly – a cybercriminal who wants to gain access to the user's identity in the system can exploit a faulty password reminder mechanism to reset it, set their own password, and ultimately gain access to the system. It is therefore essential to ensure that when a user forgets their password, the link to change the password can only be sent to the address associated with their account.

Password Change

The user must have the ability to reset their password if they suspect that their current password has been compromised. This will allow them to secure their account against unauthorized access.

It is important that the identity management system element, which is the password change mechanism, is properly configured. A user who wishes to set a new password should first provide the previous one or confirm the change via email. This effectively protects against potential attacks – even if an unauthorized person gains access to the user's active session, they will not be able to set a new password without knowing the current one.

It should be taken into account that an attacker may have previously stolen the user's password, logged into the account, and attempted to change the password. Therefore, it is advisable to strengthen the password change mechanism with an additional security measure, such as two-factor authentication.

Session Management

Proper management of the user session is another requirement that the system must meet. A session combines stateless HTTP connections into a single entity. Thanks to it, we are able to distinguish users and learn what they have done in the system. The responsibility for this area is based on ensuring the uniqueness of the session and controlling its duration.

Generating and Maintaining Sessions

User sessions must be unique, meaning that session tokens must be individual for each session. New tokens should be generated each time during the authentication process. Particular attention should be paid to the security of session tokens and their storage.

A significant mistake is to expose tokens in the URL. This creates a potential risk of token manipulation, and consequently – the takeover of another user's session, meaning gaining access to their account bypassing the login process. A solution may be, for example, to store session tokens using Web Storage objects in HTML5 or appropriately secured cookies. When choosing this session management method, it is essential to ensure that:

• cookies have the "secure" flag set, which ensures they are transmitted only over HTTPS connections,
• cookies have the "HTTPOnly" flag set, which ensures they can only be read by the server (and not, for example, by JavaScript code),
• session tokens use the "__Host" prefix, which guarantees that cookies will be sent to the server that set them.

Closing Sessions

To terminate the session, it is necessary to invalidate the token. This can occur when the user selects the "logout" option or when the session expiration time elapses. This duration depends on the specifics of the system, including its purpose or the type of data being processed within it.

If we do not decide to close the session upon closing the browser, we should consider all potential risks to the users of our application, and then – based on this analysis – determine the maximum session duration. A good practice is to allow the user to view all active sessions and to close selected sessions or to limit the number of active sessions to one.

Cryptography

As is well known, all data, especially personal data, is the currency of the 21st century. It is important to remember that cryptography is constantly evolving. Therefore, both the security of algorithms and the length of the keys used should be verified.

Data at Rest

If the application contains data at rest, it should be encrypted. Consequently, when designing systems, the ability to change the algorithms used must be ensured. When selecting encryption and hashing methods, it is advisable to rely on established industry or government recommendations.

Data in Transit

All connections must be secured with encryption using the TLS 1.2 protocol or newer, with the latest version being recommended. It is important to ensure that client communication is always encrypted, and the use of such security measures should be mandatory (e.g., enforced via the HSTS protocol). It is worth remembering that encrypted communication should be required for all connections, including, for example, system management, API connections, or database connections.

Business Continuity

The security of the application is not only about ensuring the confidentiality and integrity of data but also about guaranteeing availability.

According to Article 32(1)(b) and (c) of the GDPR, the system must be designed to demonstrate:

• the ability to continuously ensure confidentiality, integrity, availability, and resilience,
• the ability to quickly restore the availability of personal data and access to it in the event of a physical or technical incident.

The basis for fulfilling the above obligations is backup copies. However, how can we manage the entire backup management process in the application? First and foremost, we should carefully consider which resources we want to include in the backup. It is certainly worth considering:

• databases,
• system data,
• website code,
• any configuration files,
• change histories,
• configurations specific to the production environment, such as security settings.

The most recommended method for creating backups is the 3-2-1 method. This involves creating three copies. They should be stored on two different media, and one of them should be kept off-site from the main storage location of production data (e.g., in the cloud). Ideally, the third copy should not have a permanent connection to the production system. This will help minimize the risk of the copy being destroyed, for example, in the event of attacks on the system and its working environment.

In addition to creating backups, it is also advisable to test them. This includes restoring the backup to ensure that everything proceeds correctly and that there will be a possibility of properly restoring the data if necessary.

Another issue to pay attention to during testing is the backup restoration time. It should be considered whether it is not too long. The backup restoration time should not exceed the maximum acceptable downtime for the system.

Logging and Monitoring Events

Logging and monitoring events is a crucial element of system management. It is a source of valuable information about errors or attempts to breach security and exploit technical vulnerabilities of the application.

When designing the monitoring process, care should be taken to ensure that logs (also known as event logs) contain only necessary information. This means that authentication data, session tokens, or other sensitive data, as defined by the organization's security policies and legal regulations (e.g., GDPR), should not be logged. However, all security events should be logged, including events related to authentication, access control errors, or input data validation.

To streamline the process of detecting unwanted events in logs, it is advisable to consider solutions that allow for their automatic analysis or correlation. For the aggregation and automation of logs, systems such as SIEM can be implemented to notify about the occurrence of anomalies in the system, as well as to correlate these events with similar occurrences in the environment.

It is essential in the entire event log management system that the logs are adequately secured against unauthorized access, deletion, and modification, for example, by sending them to a separate server that collects logs.

GDPR Requirements

The GDPR itself is not a technical act, and consequently, it does not impose specific guidelines that a given application must meet to be considered compliant with the regulations. And that is a good thing! Technology is constantly advancing, which means that the text of the regulation would need to be updated every few months. However, the GDPR provisions refer to the security of the systems or services being created and used.

Privacy by Design and Privacy by Default

Two sister principles arising from Article 25 of the GDPR – privacy by design and privacy by default – explicitly mandate that the systems being created are secure and provide maximum protection of users' privacy. Already during the design phase of the personal data protection system, measures should be implemented to protect the processed data and the privacy of individuals whose data is being processed from the very beginning. After the system is implemented, its default settings should anticipate the most advanced protections for personal data. The application settings should by default provide the minimum amount of information about the user.

How can the principle of privacy by design be practically implemented?

• A risk analysis for the system should be conducted. First, the creators should confront all threats and vulnerabilities with reality, that is, with the context in which the application will operate (such as on-premise or cloud environment, server version, vulnerabilities characteristic of the architecture, programming language, etc.). In the subsequent steps, they should implement safeguards that respond to specific threats. A good idea for verifying the completion of the threat analysis is penetration testing or vulnerability scanning.
• A Data Protection Impact Assessment (DPIA) should be conducted if required. Its purpose is to verify whether the user's privacy is adequately protected in the data processing process within the system.
• It is necessary to create appropriate project documentation that outlines how the requirements arising from the GDPR will be fulfilled.

Implementation of User Rights

Security is not the only aspect we must address when designing, implementing, and maintaining a system. The GDPR requires us to also safeguard the rights and freedoms of individuals using our services, namely the users whose data is contained within the system.

The system should provide users with the ability to delete their data (except in cases where the data controller processes data to fulfill a legal obligation, execute a contract, or assert their rights). Each user should also have the ability to freely export their data from the system (this applies to data processed based on consent or a contract, but does not include data processed under the authority or public interest). It is also beneficial for the user to have an interface through which they can edit their data (e.g., contact information). This will enable the exercise of their right to rectification of data.

Of course, when discussing the requirements of the GDPR, it is impossible not to mention the system's privacy policy. It informs users about how their data is processed and their rights under the GDPR.