This is the second part of the article Our customer guide I.

I want an offer, what do you need from me? (RFP)

If you already know exactly which penetration tests or security audits you are interested in, do not hesitate to contact us. You can also do this in a secure encrypted way – send us an S/MIME or PGP encrypted message ( you can find our keys here ) or contact us via the Signal application (at the number listed in our official contacts ). 

To be able to create a price offer for you, we will need some information from you.

We offer standard penetration tests for a fixed price which reflects our fixed workload. It should be noted that this type of penetration test is suitable for simple web sites or web applications. To answer a simple question: “Can a professional attacker hack my site in three days?”. It is therefore clearly unsuitable for larger or complex applications.

We can estimate the price of a comprehensive web security audit in three ways. The easiest (and fastest) way for you is to create a test account for us in the application you want to test. If you want to perform testing from the perspective of users with different roles, we need a separate test account for each role. Due to this we can estimate the complexity of the application, our expected workload, and therefore the final price. Unfortunately, sometimes it is impossible to provide us test access to the application (for example, the application may still be in development). In this case, there are two other ways to estimate the complexity of the application and thus our workload. The first way is to send us all the technical documentation for the given application, ideally with screenshots and detailed descriptions of each form. The second way is to answer a set of specific questions related to the application:

• What is an estimated number of pages? (ie unique “screens” or “routes”)
• What is the approximate number of form entries? (ie input “boxes” all over the site)
• Is SSL/TLS used?
• Is authentication used (is the authenticated part of the site tested)?
  • if yes, is multifactor authentication used?

• Is captcha used?
• Can you briefly describe the purpose and functionality of the application in 2-3 sentences?
• What is the number of user roles (from which perspective we do the testing)? If the roles are variable, we recommend creating 3-4 roles – the least and most privileged, the most exposed, etc.
• Is there technology in the solution that is prone to server-side memory management issues? (C / C ++)?
• Is a thick client used in the solution (Java applets, Silverlight, Flash, ActiveX, …)?
• Do you want to test the application for DoS vulnerabilities (not DDoS)?
• Are HTML5 features used, e.g. web sockets, local storage, etc.?
• Does the application use web services (SOAP or REST), other than those which are used by the front end (e.g. for third party integration)?
  • please provide us with documentation of these APIs in a standard format (WSDL, Swagger, Postman, API Blueprint, …)
  • if this is not possible, how many operations with how many parameters do these APIs implement?
  • is there a client (e.g., javascript web, mobile application, or at least a SOAP UI project) available for these web services that can generate legitimate API requests?
  • How is authentication handled?

• Is remote testing possible or is it necessary to be physically at the customer (onsite testing)?
• What should be the language of the final report?
• Where will the application be hosted during the test, own hardware / VPS / cloud / shared hosting (due to the consent or restrictions of the operator)?
• What environment will be used during testing (DEV / TEST, INT / UAT, PROD … (1: 1 the copy of production without “productional” data is recommended, dedicated only for penetration tests)?
• What is the preferred testing date / start date?

Based on these answers, we can then estimate our final workload and thus, the final price.

If you are interested in mobile application testing, then we need to ideally have access to the appropriate applications as well (they do not necessarily have to be in the Google Play / iOS repository, just binary APKs). The second option is to send all available technical documentation related to them. We also need a detailed description of the mobile application’s web services (the Swagger specification). This step is not necessary if you want to do black box application testing (in this case, we will find out the used methods, their inputs and outputs by listening to the communication of the application itself). 

For external penetration tests we need to know the number of tested IP addresses or IP ranges. It is ideally preferable for you to specify the operating systems in use or types of network devices. The network architecture map will also help us (not needed for blackbox tests). If it required that we perform a completely blackbox test and you do not want to tell us any information about the tested infrastructure, then this is also possible – but in this case we will use the upper price estimate of external penetration tests.

For internal penetration tests, we also need to know the number of tested IP addresses or IP ranges (or the number of sites if the testing takes place “onsite”). If you are running some very old systems which likely crash during an aggressive scan (this situation in itself is a security risk and should not occur), then it is possible to provide us with a list of IP addresses and we will omit them during testing.

For all of the above tests, if you want to perform aggressive DoS (Denial Of Service) tests, it is possible to agree on the exact time of testing (for example, on Sunday at 4:00 in the morning). 

Some customers want to implement distributed DoS attacks (DDoS). It should be noted here that these tests only make sense if they are performed from thousands of different IP addresses. Such a number of IP addresses are usually not owned by any IT security company. We can solve this by purchasing thousands of virtual servers with thousands of IP addresses from cloud providers (such as Amazon) for an agreed test period. However, this solution requires extra cost. Therefore, we do not usually perform distributed DoS attacks. Instead, we implement the so-called application DoS tests, the aim of which is to test whether we can halt the web application or system from a common home internet connection. It should be noted that sufficiently strong distributed DoS attacks can halt virtually any Internet service and can be very problematic to defend against them (in case of such a risk, we therefore recommend using solutions such as Cloudflare).

After an agreement with our ethical hackers taking into account their availability, together with our prepared offer you will obtain the time schedule of the testing itself. We are most congested at the end of the year, the least in spring or mid-summer. We have the best availability when performing web tests that can be performed by all our ethical hackers. We have the lowest availability for narrowly specialized security tests, which require special knowledge and can only be performed by some profiled experts. We therefore recommend booking specialized tests a few weeks to months in advance.

The last thing we need to know is in which language the offer itself and the final report should be created (in the case of English, we can cover it with the largest number of testers).

After you send us all the information needed to estimate the laboriousness of the testing itself, we will prepare a professional price offer for you in the following days. We make the offer as standard either in Slovak or in English, if necessary we can also make it in another language.

I opted for your services, let’s get to it! 

If our offer appealed to you, let us know, ideally by (encrypted) email.

It’s time to comment and sign a contract to give us permission to perform penetration tests or security audits of your applications, systems or network infrastructure.

In the 14 years of our existence, we have reached through extensive iterations a comprehensive 17-page “Vulnerability Assessment Agreement”, which contains all the necessary information to start testing smoothly and describes all possible non-standard situations which may occur during testing. It includes the exact date when the testing will be performed, the scope, the types of tests used, methodology etc. The contract defines exactly the rights and obligations of us and our customers. If you only order a standard penetration test, we can provide you with a simplified version of this extensive contract as part of minimizing bureaucracy. 

Many of our customers require the signing of a non-disclosure agreement (so-called NDA). In this case, it is possible to use our NDA contract template or we can also use your NDA contract template. In this case however, all new contracts (not just the NDA) are subject to review by our legal department, which will need a few days to analyze them and incorporate comments. It should be noted that some of our customers have unrealistic expectations in the NDA – for example, they want to sign a non-disclosure agreement for an indefinite period or propose huge contractual penalties, which are completely inadequate in the volume of services ordered.

You will find everything we know and what we cannot guarantee to our customers in this article.

If you have special requirements for performing tests or for a non-disclosure agreement, it should be taken into account that the signing of the agreement itself may be postponed by a few days (in this case, we will connect our legal department with your legal department). You may not have this problem if you choose to use our existing already fine-tuned contracts. We sincerely try to ensure that our agreements are not unilateral, and are balanced on both sides. As a customer, we want you not only now, but also in the future. 

The contract must also include contact information to your web application and system administrators in case the tested application crashes or stops working (this does not happen often, but it can happen).

The contract also specifies when and whether aggressive DoS tests will be performed at all (if required by the customer). 

To perform the tests, we need for you to deliver at least two test accounts in encrypted form, which we will use during testing. When multiple roles are used, we need at least two different test accounts for each role tested (this is necessary to correctly test the vertical and horizontal escalation of privileges in the case of authorization testing). If you want to test your application completely, we need to have instances of all user roles that can functionally cover all forms of the tested application.

After signing the contract, we automatically guarantee to the customer that we will reserve our dedicated testers for them at the time of the agreed testing. Since our testers participate in different projects of different customers at different times, it is necessary for the customer to allow us full testing at the agreed time. 

Since many of our testers are based abroad, some do not speak Slovak – only English, so if you choose English we can provide you with the greatest availability.

How to prepare a test environment and test accounts

An insufficiently well-prepared test environment on the part of the customer is, unfortunately, often a stumbling block due to which we are unable to start tests in time (and often subsequently pass deadlines for testing). If we do not meet the deadline due to this, we can only start the new tests when our testers have time again. This can cost a customer extra money and time.

Therefore, it is very important that the customer prepares a timely and proper testing environment. Since aggressive penetration testing can cause system, application, or data corruption, we prefer to perform tests primarily in a test or pre-production environment (that is, one that is as identical as possible to the production environment). It is also related to the fact that we want to minimize any liability for damages caused by our testing, which in principle we cannot bear. If a customer fears that our testing will cause their services to fail or data to be corrupted, they should do their best to have a test or pre-production environment where we can perform potentially aggressive testing. If they fail to provide this environment and therefore require testing in a production environment (which unfortunately sometimes happens), then they should have up-to-date backups and we should be able to contact the application or system administrators whenever the tested application crashes or stops. 

It is also important that during testing, the customer should not change or update the test environment in any way, as this may cause inconsistencies in our findings.

According to the signed contract, the customer should provide access to all our penetration testers by the date of the start of the testing itself and verify whether the VPN connection provided to us works as well as the test accounts themselves. If the login itself requires a second factor (OTP calculator / hardware token), then it is necessary to deliver it to us in time.

Testing is successful, what should I expect?

After providing us the test environment and test accounts, we start the tests as agreed. When it comes to testing in a test or pre-production environment, our testers can perform tests non-stop (preferred situation).

When it comes to testing the production environment, we can adapt to the customer’s time requirements (some require “controlled” testing so that testing does not adversely affect the functionality of the tested application, some require on-site testing so that administrators and application developers at the customer side can respond immediately to any questions from our testers).

If, during testing, we detect critical vulnerabilities in the tested application, system or infrastructure that could lead to leakage of sensitive information or malfunction, we will immediately contact (by phone or e-mail) the customer. This gives them the opportunity to fix it immediately. 

Critical as well as all less-critical vulnerabilities will be included by our testers in the final report, which is sent and presented to the customer at the end of testing.

The final report

At the end of each penetration test or security audit, you will receive a professionally prepared final report from us (in English or another supported language).

The beginning of the final report contains a management summary and test results for all tested applications, services or systems. The results include a list of detected vulnerabilities sorted by severity – from critical vulnerabilities, through high, medium, and low severity vulnerabilities. For each identified vulnerability, a detailed description, severity, and solutions for fixing the vulnerability are provided. If this vulnerability is not easy to fix, we will also mention a “workaround”, which will minimize the negative impact of the vulnerability as much as possible. Each vulnerability also includes optional references to the CVE, or other standardized description. 

The comprehensive web application security audit also includes a personal presentation of the results, which can also be done online and, if necessary, ordered for any other test performed. In this presentation, our testers will explain to application or system developers how these vulnerabilities can be exploited and, of course, fixed. We also cover how it is possible to prevent these vulnerabilities (security flaws) in the future.

The final report is valid as of the date of delivery to the customer. Unfortunately, after this time, we cannot guarantee that no new critical vulnerability will emerge that will be exploited. We therefore recommend performing repeated tests and including the application in the bug bounty program.

In the third part of the article, we will explain why repeated tests and bug bounty programs are important, what technology certificates ethical hackers should have, and what are the benefits of the test at a “free” voluntaryist company?