Our approach: Protect against the widest range of attacks
The PROSA approach is based on modeling behaviour and communication through your solution using a Domain-Specific Language (DSL) with which the logic and critical-security areas of the system under development can be represented. This semantics covers all aspects relevant to IT security in applications and layers of applications. This model can be either be integrated directly into your source code or be a separate model.
Based on the model developed the following testing process is carried out:
- The scope is identified through documentation review and interviews giving a first idea of the critical sections. This step benefits from a network representation of the underlying systems.
- Modeling relies on further documentation review to obtain detailed systems behaviour, uniform documentation, and eliminate implementation errors.
- Security Requirements are identified and validated. This contains the confidentiality and integrity goals of the model.
- Threats include the completion of eavesdropper simulations and attack landscaping. At this stage the full, active and passive, attack spectrum is used. As a result, possible threats are documented (description of attack behaviour).
- Risk Analysis contains a threats overview together with decision-making priorities. Risk documentation for each attack is generated.
With regulatory requirements such as the Payment Services Directive 2 (PSD2), we can help you identify the security requirements that are relevant to your solution. By following the PROSA approach you can link the regulatory requirements to a risk analysis of potential threats, which lets you prove that your solution is secure.
Saving money and improving code quality with PROSA
A common rule of thumb in computer security is that every 100 lines of source code contain ONE defect, representing a potential entry point for attackers to a system. Even more worrying is that systems are getting more and more complex, possibly containing dozens or hundreds of components spread across various servers and cloud services. Attackers are also getting more and more advanced. With PROSA you can analyze complex solutions and show what happens when an attacker is able to:
- listen in on the communication between your systems
- modify data sent to or from your systems
- change or destroy data locally on a system
- have access to crypto-keys, e.g. from an attack on onboarding
Designing applications following security principles allows to mitigate potential weaknesses. With the PROSA approach we can help you see the bigger picture of your security solution, and help you avoid potentially costly design errors:
PROSA compared with traditional methods
| Traditional approach | PROSA approach | Effect from PROSA estimate | |
|---|---|---|---|
| Modelling | 500-3000 pages of informal description, fragmented, on a component-by-component level | 3-10A4 pages with a precise, formal system description | 20x faster understanding of the system or new employees |
| Security requirements | General requirements, imprecise, not connected to concrete assets | Precise description of assets and security goals | 4x more requirements |
| Issues | Semi-manual and expert-based | Precise description of issues, dynamic simulations of attacks | 10 more threats and issues found |
| Risk | Experience-based | Provides a systematic index of threats based on issues | 4x aster process for estimating risks |
An asset can be a defined security asset, such as a payload, key identity or password.
An issue is a potential for misuse of a system, a partial compromise, an attack, etc