Security

Our Security engineers collaborate in architecture workshops, particularly when it comes to planning new architecture and Security issues are raised. We support our clients in developing the right architecture for an infrastructure, which is ‘security-minded’ and supports the automation of security-relevant processes. This is about defining the right measure for protecting the use cases, which should then be rolled out to the infrastructure. At the end, a security concept is compiled.

Security is not a state – it’s a process. And this is why we offer the support and collaboration of a Security engineer in all security-relevant aspects from the design and development through to the final operating mode. The security engineer is your contact for all the team’s security-relevant questions and motivates the team to bear relevant issues in mind.

If an architecture has already been developed without the involvement of a Security engineer, we review this existing architecture in terms of its security aspects. During this review, we identify and classify the architecture’s risks and propose measures to improve the Security. This review can be used to prepare for a Security audit, for example.

A reconnaissance determines all the publically accessible information about an objective or company and analyses this for possible ‘information leaks’. This is because, before an attacker attacks a company, he tries to exploit any little pieces of information from public sources, e.g. addresses, emails, employees, financial circumstances, communication channels, technologies, DNS entries, business relationships, running systems or administrators. This information is often a gold mine because it can provide the attacker with information about internal procedures. We put ourselves in the role of a potential attacker and collect all the information about a company we can find on the internet.

Penetration tests are ideal for assessing the current Security status of a system or Web Application. When performing a penetration test, the publically accessible services and backend are examined specifically from the point of view of an attacker. The objective is to determine which vulnerabilities the attacker can identify and how far into the system he can actually penetrate. In addition, developers and administrators are given the assurance that security-relevant parts have been implemented correctly and the system has no known vulnerabilities. Primarily, however, these penetration tests constitute a sound basis on which our Security engineers (see also ‘Support by a Security engineer’) can help you to rectify vulnerabilities and improve systems to a suitably high level of security in the long term.

We establish an automated infrastructure, with which vulnerabilities are searched for and scanned automatically and at regular intervals – even during development or operation. The continual identification of vulnerabilities contributes to finding and closing vulnerabilities in good time before an attacker exploits an obvious vulnerability. For example, the OWASP top 10 risks can be automatically sought in a Web Application.

Nowadays, software has countless external dependencies on libraries, frameworks and modules. With this multitude of dependencies, it is very difficult to maintain an overview of unsecure dependencies or new vulnerabilities in these dependencies. Just one single vulnerability could lead to the entire system being at risk. A dependency check makes it possible to check whether countless dependencies of a software system have any known vulnerabilities.

To penetrate a system (web application, server, service, network, …), attackers often exploit known Security holes or misconfigurations. A vulnerability scan should prove that the system has no known vulnerabilities that an attacker could exploit or that could generally endanger the overall Security of a system. A scan for vulnerabilities should not be equated with a comprehensive penetration test, but can provide an initial analysis of the security of a system.

Nowadays, a large number of IT systems are accessible on the internet in the form of a web application or as an API, and even a single vulnerability can be enough for attackers to penetrate the system and cause damage. To make this risk manageable, software developers must be aware of the attack vectors in order to recognise and avoid typical vulnerabilities. This training addresses the typical requirements of web applications, creates awareness of the most common security risks and provides practical knowledge on countermeasures in theory and practice. This should enable companies to recognise and avoid typical vulnerabilities on their own.

It is only in the rarest of cases that a product or service is delivered or configured ‘securely’ ex works. This means the infrastructure, the service or the application is only as secure as its weakest link. When performing a hardening process, the configuration is examined for possible vulnerabilities or anomalies. The aim of the hardening process is to keep the attack surface as small as possible.

In the case of acute Security incidents, we can support companies in managing the incident and introducing practical measures (immediate, short-term, medium-term and long-term). Detailed post mortem analyses of successful intrusions are not our specialist field but we are happy to provide advice in selecting a competent service provider and initiating the measures from the results of the analysis.

We know from experience that attackers carry out automated scans dozens of times a day. For this reason, it is important to detect such an attack and take countermeasures as quickly as possible. IDS (intrusion detection systems) and IPS (intrusion prevention systems) are used to identify these scans. If these systems ascertain an attack pattern while observing the log files or packages, then the attacker is blocked and a message about the potential attack is sent to the person in charge.