We can help you with regulatory compliance
There is a lot of uncertainty around new solutions for Strong Customer Authentication and with new requirements for security and pribacy.
We can help you prove that you conform to any kind of regulatory framework, including giving a formal proof that your solution is secure on a fundamental design level.
For frameworks such as the “Regulatory Technical Standards on strong customer authentication and secure communication under PSD2” we already have templates that can help you speed up the process of documenting compliance, but our process can be adapted to any kind of regulation.
We can help you with compliance and evaluation processes together with one of our partners or as a consultancy supported project where we can help write and document your solution, together with your experts.
We normally follow an iterative process, where we go through the following steps as many times as required:
1. Scope analysis
Here we filter out the systems and protocols that are within scope of the analysis. We identify key stakeholders, such as developers and security architects, and identify the relevant regulatory frameworks.
- Review documentation
- Perform interviews
- Identify critical sections
- Review requirements
- Map documentation and resources to key system
- System overview
- Critical sections
- Scope recommendation
- Estimate of total work that is required
2. Description of model
We use a tool-assisted method for generating a model of the protocols and systems that are to be analysed.
- Detailed documentation review
- System model created
- Identification of fundamental patterns (e.g. SSL)
Review with key personel:
1. Model updates
2. Documentation error
3. Design errors
- A precise PROSA model providing:
- System overview
- Detailed system behavior
- Complete, uniform documentation
- Design errors are identified
3. Security requirements
Here we can generate protection graphs of the system, allowing you to view how critical assets are protected during transmission and on systems. We can identify anomalies such as circular use of keys. On this stage we can help identify the sensitivity, integrity and confidentiality requirements for each asset identified.
- Identify and validate information assets (critical information elements)
- Model requirements
- Model with complete requirements including:
- Confidentiality goals
- Integrity goals
- Mapping of requirements to the relevant requirements
Here we formulate the main attacker goals, and analyse how the system protects against attackers. An example here is that sensitive information should be protected at all points. The threats are mapped to the requirements, so that you can show that possible threats have been examined.
- Perform eavesdropper simulations
- Attack landscaping
- Impersonation patterns
- Documentation of possible threats (potential attacks with description of attack behavior)
5. Risk analysis
The final phase is to analyse the results of the threats, and to identify any residual risks. Typically in an evaluation process it is the residual risks which are of interest, as this shows what you can’t control for.
- Threats overview
- Decision making priorities
- Risk documentation for each potential threat