Security principles for cross domain solutions
Thirteen things that need to be good to make a secure Cross Domain Solution (CDS).
Pages
Page 8 of 15
People and the CDS
A CDS must be usable by all the people who interact with it. This includes:
- Installers of the system.
- Administrators who have to look after the system.
- People inside the organisation, who have to work with the tools every day.
- People outside the organisation, for whom a CDS may be critical to working with people inside it.
- Security staff monitoring the solution.
To be usable for all of these people (even if there are a lot of them, or it’s a large amount of work that people do with it), the CDS should be:
- Effective – tasks can be completed to an acceptable quality or better (according to the system owners). This should take account of the outcome's accuracy and completeness. These standards apply to task people carry out directly with the CDS (such as sending information) and to the quality of the CDS’s outputs. For example, people inside the domain may be unable to carry out specific image analysis if details have been altered by security transformations. The CDS should also minimise the possibility of an action taken by a person, such as a mis-click, leading to a security incident.
- Efficient – tasks can be completed in a timely fashion, with little effort or additional cost, so that people do not feel the need to find workarounds. The system should shepherd people away from errors by using contextual hints, and processes designed to make errors less likely. There should also be easy ways to recover from mistakes.
- Satisfying – the experience of using the system meets the needs and expectations of its users. Peoples’ perceptions are important. Problems such as the unexpected alteration of files, or the fear that a file transfer may be stopped without notifications can make people seek workarounds, perhaps even avoiding the CDS entirely, resorting to less secure alternatives.
- Accessible – A system which fails to be accessible quickly becomes inefficient and unsatisfying. For example, a file transfer system that converts text into images may make received documents impenetrable to search tools, as well as to screen readers. If the CDS cannot be made accessible then an alternate system should be available for people with accessibility requirements.
A CDS must be usable as a whole package. This includes hardware and software, documentation, training, and support services. Training and documentation can add only a little usability if this is missing in other parts of the CDS.
Defensive techniques
To enable a CDS to be effective, efficient, satisfying and accessible, for the people who use it:
- The usability of the system should be evaluated for all the most frequent and important tasks of the Installers, System Administrators, Security Staff and End users.
- End users should be kept aware of which domain they are working in, or that their work will be sent to (e.g. 'inside' or 'outside'). This can be done by presenting domain cues through the user interface. These cues should offer some redundancy so that they work for people with sensory impairments (such as colour blindness) or who may not be attending to a particular sensory channel (for example they are looking at their keyboard to type instead of the screen).
- Present transformed content to people as such. Ideally, people should be told, or be able to easily discover what details are missing or different.
- Give end users feedback about success and failure, as well as delays in transmission, release control and reception.
- Be accessible, which may avoid unintended bad outcomes for all people, not just those that have disabilities.
- Add little extra complexity, time or effort to end users' tasks.
- Have defaults that provide reasonable protection 'out of the box.' They should also have reasonable effectiveness, efficiency and satisfaction for untrained installers.
- It should not require significant additional effort from System Admins to be reasonably secure.
As well as the design of the CDS itself, there are other things that could make human error more likely when people interact with a CDS. There are many descriptions (from the world of Safety) of these things, and you can read an example in the Health and Safety Executive’s (HSE) list of “Performance Influencing Factors”. The more important it is for your users to interact with a CDS in a secure way, the more effort you will have to put into managing human error.
The organisation that the CDS works in will have culture, policies and practices or other features that may make the CDS more or less likely to succeed. Even with a CDS package that has been successful before, it can be very difficult to know in advance how it will work in an organisation as a whole, in different parts of the same organisation, or over time. So, it is important to learn about how the CDS is working after it has been put in place and is in use, and to keep on learning.
- Small scale trials of a CDS before it’s wider roll out may be helpful. These could make it possible to identify and manage unintended security harms involving people, while they are still small, and so make your CDS more successful.
- Adopt a positive security culture to help people feel comfortable giving feedback on security issues and events. Visibly act on any feedback given to encourage people to keep giving it.
- Ensure the people who interact with the CDS are asked about their experience of using it “on the ground” so things that might help people improve security are captured. Study how people make good security and performance happen with the CDS, so you can spread and increase it, as well as studying how bad security and performance happens, so you can improve it.
