For now, here’s Chapter 1 and the Table of Contents and preambles. (pdf)

A sort of common map, so to speak, on which to point out, recognize and understand each other’s territories..

Extracted from: ‘The necessity of Trans-Scientific Frameworks for doing Interdisciplinary Research’ by Professor Søren Brier

Now, how do I apply the theory and the transdiscipinary framework for my research on data breach incident response?

It seems that on initial exploration, Peirce’s work on Semiotics provided the necessary framework in the form of Firstness, Secondness, Thirdness – Peirce’s ternary.

Which is – don’t be careless, don’t be reckless, don’t be rude and don’t be an idiot.

An interviewee’s comment on the various data protection and privacy standards, procedures and policies.

Extracted information from the site;
Overview

The OASIS Cyber Threat Intelligence (CTI) TC was chartered to define a set of information representations and protocols to address the need to model, analyze, and share cyber threat intelligence. In the initial phase of TC work, three specifications will be transitioned from the US Department of Homeland Security (DHS) for development and standardization under the OASIS open standards process: STIX (Structured Threat Information Expression), TAXII (Trusted Automated Exchange of Indicator Information), and CybOX (Cyber Observable Expression).

The OASIS CTI Technical Committee will:

define composable information sharing services for peer-to-peer, hub-and-spoke, and source subscriber threat intelligence sharing models
develop standardized representations for campaigns, threat actors, incidents, tactics techniques and procedures (TTPs), indicators, exploit targets, observables, and courses of action
develop formal models that allow organizations to develop their own standards-based sharing architectures to meet specific needs

I will certainly be interested in the ‘incidents, indicators, observables and courses of action’. Anything shareable is worth researching.

The following texts are extracted from this report,’Towards a Safer and More Secure Cyberspace‘ issued by the National Academy of Sciences, US.

Box 4.1 summarizes the classic Saltzer-Schroeder principles, first published in 1975, that have been widely embraced by cybersecurity researchers. (my italic)

BOX 4.1
The Saltzer-Schroeder Principles of Secure System Design and Development
Saltzer and Schroeder articulate eight design principles that can guide system design and contribute to an implementation without security flaws:

• Economy of mechanism: The design should be kept as simple and small as possible. Design and implementation errors that result in unwanted access paths will not be noticed during normal use (since normal use usually does not include attempts to exercise improper access paths). As a result, techniques such as line-by-line inspection of software and physical examination of hardware that implements protection mechanisms are necessary. For such techniques to be successful, a small and simple design is essential.

• Fail-safe defaults: Access decisions should be based on permission rather than exclusion. The default situation is lack of access, and the protection scheme identifies conditions under which access is permitted. The alternative, in which mechanisms attempt to identify conditions under which access should be refused, presents the wrong psychological base for secure system design. This principle applies both to the outward appearance of the protection mechanism and to its underlying implementation.

• Complete mediation: Every access to every object must be checked for authority. This principle, when systematically applied, is the primary under- pinning of the protection system. It forces a system-wide view of access control, which, in addition to normal operation, includes initialization, recovery, shutdown, and maintenance. It implies that a foolproof method of identifying the source of every request must be devised. It also requires that proposals to gain performance by remembering the result of an authority check be examined skeptically. If a change in authority occurs, such remembered results must be systematically updated.

• Open design: The design should not be secret. The mechanisms should not depend on the ignorance of potential attackers, but rather on the possession of specific, more easily protected, keys or passwords. This decoupling of protection mechanisms from protection keys permits the mechanisms to be examined by many reviewers without concern that the review may itself compromise the safeguards. In addition, any skeptical users may be allowed to convince themselves that the system they are about to use is adequate for their individual purposes. Finally, it is simply not realistic to attempt to maintain secrecy for any system that receives wide distribution.

• Separation of privilege: Where feasible, a protection mechanism that requires two keys to unlock it is more robust and flexible than one that allows access to the presenter of only a single key. The reason for this greater robustness and flexibility is that, once the mechanism is locked, the two keys can be physically separated and distinct programs, organizations, or individuals can be made responsible for them. From then on, no single accident, deception, or breach of trust is sufficient to compromise the protected information.

• Least privilege: Every program and every user of the system should operate using the least set of privileges necessary to complete the job. This principle reduces the number of potential interactions among privileged programs to the minimum for correct operation, so that unintentional, unwanted, or improper uses of privilege are less likely to occur. Thus, if a question arises related to the possible misuse of a privilege, the number of programs that must be audited is minimized.

• Least common mechanism: The amount of mechanism common to more than one user and depended on by all users should be minimized. Every shared mechanism (especially one involving shared variables) represents a potential information path between users and must be designed with great care to ensure that it does not unintentionally compromise security. Further, any mechanism serving all users must be certified to the satisfaction of every user, a job presumably harder than satisfying only one or a few users.

• Psychological acceptability: It is essential that the human interface be designed for ease of use, so that users routinely and automatically apply the protection mechanisms correctly. More generally, the use of protection mechanisms should not impose burdens on users that might lead users to avoid or circumvent them—when possible, the use of such mechanisms should confer a benefit that makes users want to use them. Thus, if the protection mechanisms make the system slower or cause the user to do more work—even if that extra work is “easy”—they are arguably flawed.

Nine Patterns

BREACHES VS INCIDENTS?
This report uses the following definitions:
Incident: A security event that compromises the integrity, confidentiality, or availability of an information asset.
Breach: An incident that results in the disclosure or potential exposure of data.
Data disclosure: A breach for which it was confirmed that data was actually disclosed (not just exposed) to an unauthorized party.

Being a software analyst (plus other ‘beings’), I tend to start looking for ways or more formally, a methodology to ‘identify or classify’ objects that I’m interested in exploring.

There’s a saying in management speak that ‘you can’t manage (it) if you can’t measure (it)’
To measure it, one has to also know what is ‘it’ I want measuring, so the first step appears to be ‘identify it’.
Well, this is assuming I have also set up my context for ‘identifying it’.

In the world of research, ‘identification or classification’ is considered as ‘the most central and generic conceptual exercises’. Conceptually this takes two forms of classification namely typologies and taxonomies.

Further clues are in this article;
G. Par´e, M.-C. Trudel, M. Jaana, S. Kitsiou, Synthesizing Information Systems Knowledge: A Typology of Literature Reviews, Information and Management (2014), http://dx.doi.org/10.1016/j.im.2014.08.008

In essence, typology is derived deductively and taxonomy is usually derived empirically or inductively using cluster analysis or other statistical methods.

Which term to use depends on what I want to do with it.