A live demo of CAIRIS is available to use on https://demo.cairis.org.
The demo has a test account (user: email@example.com, password: test) with two example databases you can explore: NeuroGrid , ACME Water. You are also free to create your account to explore CAIRIS’ capabilities on your own.
The live demo is rebuilt every night based on the latest updates to CAIRIS, so please feel free to add, update, or remove elements in the example models. The test account is dropped and re-created each night with the sample models. Other accounts created on the server are dropped on Sunday morning each week.
The CAIRIS YouTube channel has several short video primers. These include an overview of the UI, and guidance on using CAIRIS for different design activities.
Define your contexts of use¶
How you use CAIRIS depends on how you approach the early stages of your design. You will, however, need to work with environments to represent your contexts of use. Each model comes with a Default environment, but you may wish to add more later as you learn more about different contexts.
Save early and often¶
You should save your working model early and often. Saving a model in CAIRIS entails exporting it. CAIRIS models are XML, so easy to edit using other tools and easy to version control.
CAIRIS supports the creation and management of personas to represent archetypical users, and tasks to describe how these interact with the system being designed. You need to define roles that the personas fulfil before creating personas, and personas before creating tasks. As your design evolves task models and risk analysis models will summarise the impact that security and usability are having on each other.
Asset-driven security design¶
Once you’ve specified at least one environments, you can start modelling assets : the things that are important to you. You should model relationships between them to help you make sense of your growing design, and identify new assets you need to protect. As asset models gives you ideas about possible system weaknesses, record these as vulnerabilities. As you think of new threats, note who you think the attacker might be, and what threats they might carry out. Armed with these insights, you can then create risks that bring everything together. Based on these risks, you can decide how to respond and add countermeasures to mitigate them.
Threat-driven security design¶
You don’t have to start your design by thinking about assets. CAIRIS encourages the early creation of threat models, which can be useful if you’re still trying to make sense of what the system is and how attackers might exploit it. This can help you better understand what your assets are, and even help you understand what the usability implications of certain threats might be.
Working with requirements¶
The earlier you start finding requirements, the easier it will be to spot other issues in your design. CAIRIS lets you model requirements as goals, requirements, and use cases.
Thinking about architecture¶
Requirements aren’t always easy to find, and sometimes thinking about possible architectures can help you work backwards. You can use architectural patterns as building blocks and introduce these into environments to see risks they might be exposed to, or how they might impact personas and tasks. You can also use security patterns to see what their consequences of different pieces of best practice might have on your design.
Your stakeholders may not want to work directly with CAIRIS, so you can generate documentation to share your design documentation with others.