The application of useless Japanese inventions for requirements elicitation in information security

Rules of requirements elicitation in security are broken through the use of Chind¯ogu, by designing impractical security countermeasures in the ﬁrst instance, then using these to create usable security requirements. We present a process to conceive the requirements in Chind¯ogu form. We evaluate the usefulness of this process by applying it in three workshops with data gathered from a European rail company, and comparing requirements elicited by this process with a set of control requirements.


INTRODUCTION
A Chind ōgu is defined as "an unusual gadget, originally created as the solution to a particular problem, although effectively it hardly has any utility whatsoever, it's really almost useless" (Mediavilla  2008).A typical Chind ōgu is illustrated in Figure 1.Our work aimed to find out if something seemingly useless and impractical as a Chind ōgu could be considered viable for solving the wicked problem of information security requirements elicitation.The motivation for using Chind ōgu stems from the belief that developing systems which are both usable and secure is as an oxymoron.Security is often seen as a phase of product conception which results in reduced functionality and poor usability.Using Chind ōgu as a medium for eliciting requirements in the water industry was found to be successful in the past when applied in (Faily 2012) where the Chind ōgu "unintentionally raised awareness of an implicit vulnerability that had been hitherto overlooked".
To gauge the usefulness of Chind ōgu for security, we devised a process for eliciting security requirements grounded in the Requirements Engineering literature, and other cases where Chind ōgu have been used to solve complex problems.We present our approach in Section 2 before describing our results and lessons learned in Section 3.

APPROACH
Our approach for using Chind ōgu as a method of security requirements elicitation was grounded in general/creative requirements engineering (RE) practices, such as the use of analogies between the system attributes to other non-computing domains proposed by (Maiden et al. 2004).The creative requirements engineering literature was used to draw on experiences of other novel requirements engineering techniques, together with more conventional requirements engineering practices.
The process was applied as part of the Bournemouth-Athens Network in Critical Infrastructure Security (BANCIS) project.This Data was collected from a European rail company to provide problem scenarios for applying the Chind ōgu.Once data was gathered, we ran three workshops to apply the process with three participants.This included the first author as a facilitator, and two others with some expertise collecting requirements.Workshops were run in an informal setting with office paraphernalia used to create the Chind ōgu, based on an initial sketch, such as that shown in Figure 2. The first workshop was a pilot on a factious scenario to gather feedback and observations before the workshops using problems from the rail company were run.Workshops were then held based on problem data gathered from the rail company.During workshops, interview data from the rail company employeees was analysed, and problems were identified for the Chind ōgu process to be run against.Once the Chind ōgu and requirements were created, they were specified using the Volere template (Robertson and Robertson 2009), and sent to stakeholders for validation.
To evaluate the Chind ōgu derived requirements, a comparison was carried out against control requirements elicited as part of the BANCIS project.The comparison involved the application of predefined metrics on requirements similarity.We evaluated the process in general by observing and interviewing workshop participants.Interview questions concerned the perceived usefulness of a Chind ōgu process for eliciting requirements, compared to other requirements elicitation techniques.

RESULTS
While we found that Chind ōgu were perceived to be an effective elicitation technique, an initial learning curve to using the process effectively was observed because participants required prerequisite knowledge to use the process effectively.Workshop participants with a background in security requirements gathering found the process to be an effective way of critically analysing a problem, and helping them think about how the requirements they conceive are not actually an effective solution to a problem from a user's perspective.
Applying the process yielded meaningful security requirements, which were validated by stakeholders at the rail company.Participants were asked to comment on their validity compared to the original problems identified, the feedback indicated that the requirements satisfied the original problem.Although the requirements were valid, the comparison against control requirements from the BANCIS project highlighted some missing requirements; these were concerned the operation of subsystems which would be affected by a high-level requirement.

CONCLUSION
We found that Chind ōgu provide a means to quickly elicit high-level security requirements based on problems identified in interviews with stakeholders.Requirements elicited through this process did, however, need further analysis to establish their implications to other security systems and requirements.Nonetheless, the use of Chind ōgu appears to be a powerful tool for engaging stakeholders.
The impracticalities of the Chind ōgu inventions encouraged workshop participants to think critically about the requirements conceived.This, together with the unfamiliarity of the process, helped participants abandon preconceptions, thereby aiding creative thinking.