Talk:Parkerian Hexad

I believe that the Parkerian Hexad is useful in some situations. However, I cannot accept the assertion that the three new attributes are "atomic" or "non-overlapping" in any general sense.

Consider the example given for Authenticity:

Similarly, misusing a field in a database to store information that is incorrectly labeled is a 
breach of authenticity; e.g., storing a merchant's tax code in a field labeled as the merchant's 
ZIP code would violate the authenticity of the information.

This can easily be classified as a breach of integrity: The zip code field used to have the zip code, now that data has been corrupted.

Also, consider the example of utility.

For example, suppose someone encrypted data on disk to prevent unauthorized access or undetected 
modifications – and then lost the decryption key: that would be a breach of utility. The data would 
be confidential, controlled, integral, authentic, and available – they just wouldn’t be useful in that 
form. 

Perhaps the "data on the disk" are available, the data that I put into the system is not available in this case. I think it's a classic breach of availability. I think that if data is formatted incorrectly for my system, then it isn't available. It's quite useful to talk about utility as a concept, but I don't think it's reasonable to claim that it doesn't overlap with availability (as availability has been defined for many years). Of course, if we were to define availability to be only concerned with hardware malfunctions, then sure, all the software and humanware malfunctions would not count as availability breaches, and we'd need a new name (like utility). But I don't see (at least in the article) any evidence of careful delineation.

I should emphasise that I'm not suggesting CIA is the best or only set of attributes, or even that they're non-overlapping. It all depends on the particular model you want to use for your system. The more complex your model, the more non-overlapping attributes you can have. Different models can help us think about different sets of threats and countermeasures. But I think that it takes careful work to come up with a model where the different attributes are defined and distinguished. I see no evidence that this work has been done for the Hexad, and so it seems unreasonable to claim that the 'new' attributes are "atomic" and "non-overlapping".

John Y 19:23, 17 March 2007 (UTC)

I agree with John. I guess it's Parker's assertion that these new elements are "atomic" and "non-overlapping": If so, the article should state that. Another flaw is that the hexad doesn't take account of two other elements added to the CIA triad: accountability, to give CIA²; assurance (not information assurance, but more in the sense of quality assurance), to give CIA³. The former is quite common in the literature; the latter introduced (I think) in NIST SP 800-33: Underlying Technical Models for Information Technology Security. --Ant (talk) 22:33, 18 December 2007 (UTC)

[[User:Mich Kabay|Mich__kabay, 15:40, 26 February 2011 (UTC)

The issues of atomicity and non-overlapping characteristics must be clarified. Atomicity means that the attribute cannot be broken down into sub-components. And attributes are non-overlapping to the degree that they uniquely identify a particular aspect of information security.

AUTHENTICITY: When a field is used to store information other than that described by the label of the field, the breach is of authenticity -- appropriate description or attribution -- not of integrity. The tax code stored by a sloppy programmer in the field originally used for a ZIP code is potentially perfectly correct: there is no breach of integrity, which refers to conformance to the original intent and content of the data. The breach is of labeling.

Another example that illustrates the distinction between authenticity and integrity is the forged e-mail message. A criminal forges the header information of a new e-mail message to give the false impression that it originates from someone else. The criminal does not break into the victim's e-mail account or alter an existing message. In no sense can such a fraudulent e-mail be considered a breach of integrity in the information-security sense (although it is certainly a breach of personal integrity<smile>). The forged e-mail message can be transmitted and stored perfectly, preserving data integrity at all stages of its life; however, it breaches the authenticity attribute because it is mis-attributed to the victim whose name is used in the header.

UTILITY: If someone sends a user a perfectly correct data transmission on, say, a 9-track magnetic tape, the data are available to the recipient. If they have a working 9-track tape reader, the data will be available as fast as they can mount the tape and read the data. If the mag-tape reader is not working -- or if there is none accessible to the recipient of the tape -- one can hardly label the _DATA_ as being unavailable. The data may not be _useful_ to that particular recipient, but it is unreasonable to label the DATA as unavailable. Similarly, if someone sends an encrypted file to a recipient who has the appropriate decryption key, the data are useful to that recipient -- but not to a recipient who lacks the decryption key. The presence or absence of the key determines the UTILITY of the data, not the availability. Why should we insist on confusing possibility or speed of access to the data with usability of the data, which depends on conditions quite separate from the data themselves?

I am surprised to see this very narrow definition of availability. Common use of the term in the infosec community is broad enough to describe data or systems which are not available for use, regardless of whether the data or systems can theoretically become available for use at a later time. It seems under this narrow interpretation that a DoS attack no longer causes loss of availability, which would be a change from current terminology.

In fact, is availability even relevant for systems (as opposed to data) under this definition? Would a system become unavailable if all its hardware components were melted down in a bonfire? The pile of slag is still "available", just not useful. And yet, if the fire was hot enough to vaporize the hardware, it would become "unavailable" as well. While this distinction may be correct on a technical level, it does not seem to me to be useful for analyzing risk.

65.51.90.2 (talk) 20:16, 22 April 2011 (UTC)

Mich kabay (talk) 16:03, 26 February 2011 (UTC)M. E. Kabay, PhD, CISSP-ISSMP P: +1.802.479.7937

• Assoc Prof of Information Assurance

School of Business & Management Norwich University Expect Challenge. Achieve Distinction.

• * *

E: mailto:mekabay@gmail.com W: http://www.mekabay.com/

• Network World Security Strategies Newsletters

http://www.networkworld.com/newsletters/sec/

>o ASCII ribbon campaign against HTML e-mail o<

Possession or Control

The given example (a stolen sealed envelope) is far from ideal as it introduces a subjective element into the argument (the concerns of the envelope owner)which is not intrinsic to the information asset. A much better (and real world) example that seems nearer to Parker's intent would be TLS certificates, which are capable of revocation. 212.159.59.5 (talk) 10:45, 11 September 2016 (UTC)

Added Notability template

I marked this article with the Notability template, because I believe it does not meet the WP:SIGCOV guideline. There has been very little attention for this theory.

Most of the references on this page are either works by the person who coined the theory, or works that don't mention the hexad at all. The (withdrawn!) NIST SP 800-33 mentions two properties other than the usual CIA triad, but they are not related to Parker's model.

As far as I can see, the linked Master's thesis cites one secondary source that mentions the Parkerian Hexad: a blog post from 2009.

Information security links here, but that paragraph mentions: "The merits of the Parkerian Hexad are a subject of debate amongst security professionals." The citation for it points to a blog that links to this article, and the "debate" is basically one security professional dismissing it.

I think two blog posts as secondary sources don't count as receiving significant coverage in reliable sources.

--Stiiin (talk) 17:00, 3 January 2022 (UTC)