Security Mechanism

[swang-nira]

Refer this ticket(#6 (comment))

[swang-nira]

Below please check the draft of the SDCM 3.0 security mechanism. I attached a class diagram, and also a word document to include the terminologies and references.

Couple comments:

1. I think security mechanism is better than access control, since it covers more than access control. For example, TLS belongs to security mechanism, but not belongs to access control.
2. Since SSL 3.0, OAuth1 and OAuth1a are all deprecated, I didn't include them in the document.

[sdcm-3-security mechanism.docx](https://github.com/faa-swim/sdcm/files/9561172/sdcm-3-security.mechanism.docx)

[mkaplun]

RE: comment by @swang-nira

In my opinion, this model fails to achieve its objective of aligning the Security Mechanism element with a SWIM environment and architecture in the context of the SDCM.
Looking at it, it is impossible to imagine how it could be used as a part of a service description (a registry, document, or formal language schema).

Several issues jump out:

1. What kind of information should represent all those empty classes (15 out of 24)?
2. Why should service providers describe the "ESB Security Mechanism"? (ESB in a network communication platform architecture.)
3. Does it make sense to replace a single element that currently represents a "Security Mechanism" in the SDCM with a practically unreadable 5-6 level hierarchical tree? (Actually, all elements are related through composition, so this is hardly a hierarchy.)

In sum, the model fails to meet its goal, and I do not believe it can be applied to future SDCM.

[swang-nira]

RE: #7 (comment) by @mkaplun

Thanks for the comments. Based on Mark's suggestion, please check below simplified version and let me know for any further questions.

[mkaplun]

This is the first draft of a taxonomy to be associated with the Security Mechanism class. The working title for this taxonomy is Service Security Mechanism Category. Currently, it is presented in RDF (SKOS) and is expected to be placed in semantics.aero, and UML diagram(s) for use in SDCM is forthcoming.

ssm:service-security-mechanism a skos:Concept;
	skos:prefLabel "service security mechanism";
	skos:definition "A process (or device incorporating such processes) that are used by or within a service to prevent unauthorized or accidental access, change, destruction, or loss.";
	skos:narrower ssm:access-control;
	skos:narrower ssm:audit;
	skos:narrower ssm:availability;
	skos:narrower ssm:data-confidentiality;
	skos:narrower ssm:data-integrity;
	skos:narrower ssm:data-origin-authentication;
	skos:narrower ssm:non-repudiation;

ssm:access-control a skos:Concept;
	skos:prefLabel "access control";
	skos:definition "A security mechanism that protects a service against unauthorized access or usage.";
	skos:narrower ssm:authentication;
	skos:narrower ssm:authorization.

ssm:audit a skos:Concept;
	skos:prefLabel "audit";
	skos:definition "A security mechanism that records information needed to establish accountability for system events and for the actions of entities that cause them.".
	
ssm:authentication a skos:Concept;
	skos:prefLabel "authentication";
	skos:definition "A security mechanism that verifies an identity claimed by or for an entity.".

ssm:authorization a skos:Concept;
	skos:prefLabel "authorization";
	skos:definition "A security mechanism that ensures that entities are allowed particular actions based on permissions assigned.".

ssm:availability a skos:Concept;
	skos:prefLabel "availability";
	skos:definition "A security mechanism that addresses the security concerns raised by denial-of-service attacks.".

ssm:data-confidentiality a skos:Concept;
	skos:prefLabel "data confidentiality";
	skos:definition "A security mechanism that protects data against unauthorized disclosure.".
	
ssm:data-integrity a skos:Concept;
	skos:prefLabel "data integrity";
	skos:definition "A security mechanism that protects against unauthorized changes to data, including both intentional change or destruction and accidental change or loss, by ensuring that changes to data are detectable.".
	
ssm:data-origin-authentication a skos:Concept;
	skos:prefLabel "data origin authentication";
	skos:definition "A security mechanism that protects against unauthorized changes to data, including both intentional change or destruction and accidental change or loss, by ensuring that changes to data are detectable.".	

ssm:non-repudiation a skos:Concept;
	skos:prefLabel "non-repudiation";
	skos:definition "A security mechanism that provides protection against false denial of involvement in a communication.".

[mkaplun]

The diagram depicts new classes associated with the Security Mechanism class in the SDCM.

[wznira]

@mkaplun, are you envisioning something like this in JSON?

{
	"SecurityMechanism": {
		"name": "Data Encryption",
		"description": "Use TLS/SSL",
		"SupportingProtocol": [
			{
				"title": "The Transport Layer Security (TLS) Protocol Version 1.3",
				"location": "https://www.rfc-editor.org/rfc/rfc8446"
			}
		],
		"SecurityMechanismCategory": [
			"http://semantics.aero/ssm/authentication",
			"http://semantics.aero/ssm/data-confidentiality"
		]
	}
}

[mkaplun]

RE: the comment by @wznira

I think it's very close.
One little note: Security Mechanism also has to be an array; a service may (and should) have more than one security mechanism.

I think also a better example of the description would be:

...
"description": "The service uses Transport Layer Security (TLS) cryptographic protocol for supporting communications security over a network.",
...

But we will discuss it when we get to SDM-J development.

[caroluri]

I compared the taxonomy's labels and definitions with those in FAA standards for writing service description documents and have a couple of proposed corrections and a question.

1. Service security mechanism -- change "A process (or device incorporating such processes) that are used ..." to read "A process (or a device incorporating such a process) that is used…"
2. Non-repudiation -- change "...that provides protection against..." to "...that protects against..." to make the definition consistent with the other definitions
3. Data origin authentication -- this has the same definition as data integrity, so it should be given a new definition. Also, since authentication is already defined as verifying the identity of an "entity", and a data set is an entity, maybe consider renaming data origin authentication to "data encryption" or "data traceability" or "data provenance"?

[mkaplun]

RE: the comment by @caroluri

I'll modify 1) and 2) as suggested.

The 3) was a mistake. It was supposed to read, "A security mechanism that verifies the identity of an entity claimed to be the original source of received data."
However, because there appear to be no use cases for this security mechanism in a SWIM environment, I will not include it in the taxonomy.

[wznira]

There are multiple ways to categorize security mechanisms, two of them seem to be important as shown in the diagram below:

• The communication layer they function at - most of SDCM deals with application layer security, which could be further categorized into sublayers like Service Security, API Security, and Data Security (Data-In-Transit)
• The primary security purpose they serves, such as authentication, access control, data encryption, integrity and non-repudiation. Many security mechanism can serve multiple purposes. For example, SSL/TLS is used for both authentication and encryption; PKI can be used for authentication, encryption and non-repudiation.

Table below illustrate how we can categorize some popular protocols along these two dimessions.

<style> </style>

	Physical Layer	Network Layer	Application Layer
Authentication		TLS/SSL	HTTP Basic JWT Oauth SAML PKI
Access Control			XACML Oauth SAML
Encryption		TLS/SSL	Shared Secret PKI
Data Integrity			PKI Hash
Non Repudiation			PKI