Security testing in brief
Applications and systems are commonly assessed for security problems using penetration testing. A beloved child has many names, thus penetration testing is also called pentesting.
When companies and organizations are being tested, the exercise is called “red teaming”.
When testing the resilience of organizations’ information systems, it’s known as load testing – more generally addressed as “DDoS testing” in the IT security field.
All in all, it’s about testing for security. It is a permissible simulated attack that seeks to exploit an application, a system or human users in a way that could be harmful. Harm could be caused to the information system, the company’s business or to the employees or company’s customers.
What Mint Security delivers
The purpose of a pentest is to try and simulate the intentions of a real attacker and verify the operation of the target application in such an exceptional situation. The utilized testing criteria consists of well-known and generally accepted checklists — especially those created for web application security such as the OWASP Top 10.
Source code review may also be used to support penetration testing activities. If the source code is reviewed in more detail, the OWASP ASVS framework is often used as a formal guideline.
Red teaming is not just about physical intrusion into office buildings or diving into dumpsters. A red teaming assignment can also be implemented in the digital world. We start with a recon operation. Then we proceed in the most desirable or easiest way — against systems or people who use it. There are many dimensions to this kind of assignment; the most important being that the victim knows little or nothing about the various methods we use to achieve our goal.
A distributed denial of service attack (DDoS) is a way to test the technical resilience of information systems. When conducting this kind of an attack, details of the target environment must be known to-a-hair.
Practically anyone who is responsible for any part of the target system – be that telecommunications, infrastructure, servers, applications, databases – will be somehow involved in the actual exercise. Not to forget the various responsible persons and representatives of the client or the subscriber of the exercise.
Customer needs and challenges to be solved
Customer needs can be divided into following categories, which can also be evaluated as business cases of security testing:
- Checking the status of security controls — such as firewalls or authorization management — is needed to verify the required controls are in place and working as expected
- There is a need to understand the technical threats of the application and it’s environment, as well as exploitation and abuse opportunities, along with the involved risks
- Risk register needs to be enriched with up-to-date technical discoveries
- Organization’s tolerance or resilience to specific threats needs to be understood
- Security of an application produced by a third-party needs to be checked
- Security of a technical system supplied by a third party needs to be checked
- Fluent operation of a framework or standard, such as the controls in ISO 27001 Annex A, needs to be verified
- Company’s external threats and their enablers must be understood
In addition to implementing a technical perspective and a technically comprehensive test, our approach is to understand the business as well as the threat model. In this way, we will be able to communicate and help you with what our findings affect, how they can be exploited in practice – and how to stay protected.
More details about our methods and tools
Our goal is to deliver all our expertise to customers, to the full. We utilize all members of our team in the assignments if the situation demands it — and sometimes it does.
Each assignment also includes QA; we monitor the quality of our work and review results and reports before final delivery.
Although we use a lot of different tools, our testing is not fundamentally tool-driven. Our reports are not based on a single tool. We always strive to add value by thinking like our opponent, thus forming the perfect strategy for each assignment. We try to think like the hackers do.
Our Test Lead and resident hacker is Mr. Jarmo Puttonen. Jarmo is better known in the security scene as Putsi. Jarmo is one of Finland’s toughest security testers and he does both traditional security testing and bug bounty programs. Jarmo is Finland’s most successful bug bounty hacker and is constantly on the global Top-100 list on the HackerOne platform. In the Finnish bug bounty scene, Jarmo has gained fame and glory in the programs of LähiTapiola, Vero, Suomi.fi and the Population Data Services (VRK), just to mention a few. Jarmo has also worked as a software developer, which is why he has experience and knowledge of using different programming languages – and their weaknesses.
Let's do it together
We like to team up with the customer when planning the assignments. Test methods include, for example:
- One-off tests and inspections (or less than once per year)
- Continuous testing or exploratory testing (recon operations)
- Project testing (sprint testing as part of the development process)
The final design is always decided with the customer depending on the customer’s needs. We can also work together with the client’s team.
Just a pentest? We’ve got you covered.
For straightforward pentesting, we have a predefined three-tier model where we offer fixed pricing. Differences in the models are especially in threat modeling and in the scope of reports and reviews. In each model, all findings are delivered to customers.
The models are: Full, Agile and Limited
Models are suitable for testing a single web application or application entity (e.g. application + API). Larger entities are evaluated and individually customized in the Custom model.
Code review is rarely the only test method. Code review usually takes place as part of a pentesting assignment — as an additional supporting measure to testing. Furthermore, application code is not always comprehensively available.
However, we prefer automation in code review and are happy to use Veracode tools (SAST and SCA) to our advantage here. Veracode is a static analysis tool for continuous security testing, but we can also sell these assignments as part of a so-called single scans.
We use traditional pentesting applications such as Burp Suite. In addition, we use a variety of custom-made tools, depending on the assignment, target systems and technologies.
The following special tools can be licensed separately for each assignment:
- Holm Security Vulnerability Management Platform – one-time and continuous testing
- Holm Security Fraud Assessment – a phishing simulator that can be utilized as part of red teaming
- One-time static analysis of Veracode SAST and SCA applications and application code
- Redwolf – especially as a platform for DDoS testing, on the platform it is possible to make larger testing programs with a huge variety of tools
- Spamhaus Passive DNS – DNS search engine and database
In addition, we utilize various OSINT data sources to determine the attack surface in red teaming and recon assignments.
A common tool used to assess the security of a web application is penetration testing. Known also as pentest. Pentest is a “legal” simulated attack that seeks to use an application in a way that could be harmful to either the system, the data in the system, or the people who use the system.