The aim of Red Team Assessments is to holistically review the security of a company. This includes pretty much all TOM (technical-organizational measures), including the detection of attacks and the response to attacks. If TOM are not in place, they cannot be audited. Therefore, Red Team engagements make sense if an organization already has more than basic security measures in place – or at least dedicated security personnel (Blue Team, SOC, Security Administrators, Security Operations etc.). At the very least, a penetration test should already have been performed on the company’s own infrastructure, both externally (external penetration test) and internally (internal penetration test).
- Preparation phase
- Defining test objectives (critical functions and critical assets)
- Creation of a test plan, permitted procedures and non-permitted tactics and techniques (TTPs)
- Test phase (roughly oriented on the so-called ’Cyber Kill Chain‘ and MITRE ATT&CK)
- Target intelligence gathering (consisting of target intelligence via OSINT/WEBINT/GEOINT/SOCMINT etc., footprinting, attack surface mapping, fingerprinting, scanning, and manual analysis
- Preparation and Weaponization (setting up infrastructure, preparing malware, creating social engineering scripts, creating phishing scenarios etc.)
- Breakthrough from the outside (in various ways: exploitation of external vulnerabilities, social engineering, physical intrusion, phishing, malware etc.)
- Persistence and C2: Permanent nesting in the target network and establishing communication channels
- Lateral Movement and Privilege Escalation: spreading in the target network and increasing privileges
- Objective Achievement: access to Critical Functions or Critical Assets
- Final and follow-up phase
- Creation of a detailed report with all findings, security problems, and comprehensive recommendations for remediation
- On customer request: repetition of individual attack steps or Purple Team Workshop
- Consulting and final discussions
NSIDE has already gained extensive experience with the Amazon cloud (Amazon AWS) as well as the Microsoft cloud (Microsoft Azure). Here, we have already tested complicated setups that rely heavily on cloud-native mechanisms and services. We have also conducted security tests in other clouds.
NSIDE counts companies from all sectors of the economy as well as the public sector among its customers. Some examples of industries with which we regularly carry out projects include:
- Energy producers and utilities
- Finance, banking and insurance
- Industry, manufacturing and engineering
- Telecommunications and ISPs
- Law enforcement
- Universities and technical colleges
- Public administrations (cities, counties)
- Media (print, television and online)
- and many more.
We are pleased to be able to contribute to security in almost all sectors in Germany.
Vulnerability scans are suitable if you want to check a large number of systems as quickly as possible for very basic or easy-to-find vulnerabilities. A vulnerability scan is an appropriate tool when speed, efficiency or automation are required. If, however, a test object (whether a single system, an application, an environment, or an entire network) is to be checked in depth for security problems, vulnerability scans are usually not sufficient. Automated vulnerability scans may miss many vulnerabilities.
Generally speaking, no. For some purposes, an automated penetration test may work well. It is also true that some aspects can even be carried out more efficiently and thoroughly by automated tools – we recommend the use of automated approaches in some situations as well. But, in general, the quality of a (well-executed) manual penetration test will always be higher than that of an automated one. The reason is actually quite simple: security vulnerabilities arise from situations that an architect or developer of the system did not foresee – how could an automated tool suddenly be able to anticipate them? Not for nothing is a penetration test considered to be a creative process – similar to software development. In your experience, how well has automating creative processes worked so far?
In our experience, Red Team tests should not be conducted with a duration of less than 40 person days in order for them to generate meaningful insights and results. According to the TIBER framework for Ethical Red Teaming, the testing phase of a Red Team engagement should be expected to last approximately 16 to 18 weeks, with approximately 4 to 6 on Intelligence and 12 on Red Teaming. This equates to approximately 20 to 30 person days for Intelligence and approximately 60 person days for Red Teaming. NSIDE tries to adapt these guidelines to the respective customer and to work as efficiently as possible. Nevertheless, it is important not to undercut these values too much.
It depends on what the goal is. Do I want to put all my organization’s security measures to the most realistic test possible? Do I want to find out what risks attacks really pose to my company, whether and how attackers could gain access to my most important data and systems? Then you should opt for a Red Team Assessment. Or do I want to strengthen and train my defenses and Blue Team (or SOC or administrators) as quickly as possible in a collaborative, open exercise? Do I want to strengthen my own defenses and discover blind spots as quickly as possible? Then I should have a Purple Team project conducted for my organization.
Our employees have obtained a variety of different certifications in the field of IT security. These include – but are not limited to – the following:
- OSCP (Offensive Security Certified Professional)
- OSWE (Offensive Security Web Expert)
- OSWP (Offensive Security Wireless Professional)
Penetration tests are useful in the following circumstances:
I want to obtain a reliable statement about the technical security of one or more technical systems, an application (web application, mobile app, or similar), a technical environment, or an entire network.
I would like to obtain a list as complete as possible of all technical vulnerabilities in the test object (one or more technical systems, application (web application, mobile app, or similar), technical environment, entire network) so that I can subsequently close as many as possible.
I want to reduce technical security risks as far and as completely as possible.
I want to secure a system, application, environment, or network against hacker attacks.
I want to protect my data or my systems against unauthorized access and to subject this protection to a practical test.
A system that has already been checked by a penetration test in the past has been significantly changed or further developed.
A system that has already been penetration tested in the past has not been tested for a very long time.
Offensive Cyber Security is a term in IT security that describes taking the attacker’s point of view. NSIDE firmly believes that only in this way real security can be achieved. Knowledge about the attackers and their methods is essential to make IT security truly effective.
All in all, it can be said that penetration tests are more effective and find more vulnerabilities, whereas vulnerability scans are more efficient and faster. Unlike vulnerability scans, penetration tests also find vulnerabilities that require understanding of the test object and creativity or intelligence. We recommend vulnerability scans when a large number of test objects need to be scanned in a short time. They are not well suited for deep testing of a test object. Vulnerability scans can also strengthen and track your own security as a regular measure (e.g. once a month), but they are no substitute for penetration testing.
The test object of a Red Team Assessment is always an organization or organizational unit, whereas the test object of penetration testing is a technical development or environment. Red Team Assessments are also usually goal and statement driven: How can an intruder get to my ‘most valuable assets’ (Critical Assets) or compromise sensitive systems and business units (Critical Functions)? How good is my organization’s Cyber Resilience and Posture? In other words, how well can my team and its tools detect, block, and contain such attacks? What do my processes look like?
Pentests, on the other hand, are focused on detecting technical vulnerabilities. They try to disclose them as fully as possible, while Red Team Assessments act like aggressors and focus only on those vulnerabilities that would allow the intruder to reach his target – but in the area of technology, people and processes/organization.
The following table illustrates the differences between penetration testing and red teaming:
|Red Team Exercise||Penetrationstest|
|Test item||Organization or organizational unit||Technical systems, applications, environments, infrastructures.|
|Dimensions||Holistic: Technical, human, organizational.||Technical|
|Perspektivische focus||Strategic and tactical, as well as technically and operationally in part.||Technical-operational, in part strategic and tactical.|
|Test objective||To answer the question: “Can aggressors gain access to my ‘most valuable resources’ (Critical Assets) or gain control of my most important systems or business processes (Critical Functions)?” If so, how? What are my detection measures and countermeasures?||To detect as many technical vulnerabilities as possible|
|Statements and questions||How secure is my organization as a whole? What gateways do I have that help attackers gain Critical Assets and Critical Functions? How good are my response processes? How well can I proactively block attacks? How well can I detect and respond to attacks?||How secure is the test object and what vulnerabilities exist|
|Knowlege gain||What are my organization’s key technical, human, and organizational/process vulnerabilities? How well is my defense set up? What are the risks to my business as a whole?||What are my organization’s key technical, human, organizational/process vulnerabilities? How well is my defense set up? What are the risks to my business as a whole? What are the risks to the test object, the data stored on it, and their users? What exactly are the security vulnerabilities and how can I fix them?|
|Completeness||Key vulnerabilities of the organization in the area of technology, processes/organization, and people.||As complete as possible, uncovering as many technical vulnerabilities in the test object as possible.|
|Recommendations and results||Eliminate blind spots in detection, address vulnerabilities in the three dimensions (technical/process/organizational/human), strengthen response to attacks against the organization, improve proactive and preventive measures for corporate security, strengthen general defenses against attacks (cyber resilience and posture), improve processes, provide direction for security strategy, risk assessment||Securing the test object against hacker attacks and technical risks, recommendations and guidance on how to fix the vulnerabilities.|
|Attacker model||Professional human aggressors with malicious intent against my own organization||Any attacker|
|Insiders on client side||Only one or two key people, no one else||Project and system managers, no special restrictions.|
One of our employees was on the winning team (1st place) of the 2016 German Cyber Security Challenge (GCSC) and another of our employees took 1st place in the 2015 Center for Applied Security Technology (CAST) IT Security Award.
NSIDE uses a mixture of publicly available tools (open-source tools), commercial tools and in-house developments. Exactly which tools are used depends on the specific project but the number of tools is many dozens.
For phishing simulations, NSIDE uses a framework developed in-house. This allows us to perform phishings in compliance with all data protection regulations by tracking user behavior only anonymously and generating anonymous statistics. It also allows us to develop and quickly deploy new phishing scenarios and cover stories.
NSIDE reports always consist of the following four parts:
- Management Summary: Summary and explanation of all findings for a non-technical audience, including graphical evaluation, textual description of findings in simple language and strategic recommendations.
- Findings Table (Vulnerability Table): Listing of all security issues found, their causes, their impact and detailed recommendations for remediation.
- Test details: List of executed tests (test protocol) as well as the test results. This makes it possible to trace exactly which individual tests were carried out.
- Appendix: Test modalities, risk assessment scale and whatever else that does not fit into the other parts.