[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [GRAYMAIL] Re: [kmip] Re: [kmip] RE: [kmip] Groups - Handling Instruction_w_Examples.xlsx uploaded
Yes I understood that. And my point was that the y- will not work here. At least for the multi level US defense case. This is not a new problem. The solution has been around forever and it's what the direction Chuck was using: Security Labels. But instead we make it a y- or X- thing then it's a hack and won't be interoperable. We need a well defined structure like Key Block that has some flexibility to handle different types of labels. That is the right way to do it or in my opinion we should not do it at all.
On May 5, 2016, at 10:16 PM, Anthony Berglas <firstname.lastname@example.org> wrote:I was not suggesting that we literally implement a Unix security model. Merely to be very careful about over designing something.So start with the y- model, see if it can be used to cover the cases, and if not then very carefully make more complex.AnthonyOn Fri, May 6, 2016 at 9:41 AM, Mark Joseph <email@example.com> wrote:My understanding was the main driver for this was to handle existing security systems for defense. This is one use case. And that is not the simple UNIX system which cannot handle multiple levels of data. That analogy is not appropriate to this use case.If we don't want to handle existing military systems (at least US based ones) then I am fine with the trivial discretionary access control mechanism that UNIX represents
Best,Mark JosephP6R, Inc
On May 5, 2016, at 4:27 PM, Anthony Berglas <firstname.lastname@example.org> wrote:AnthonySo I would suggest starting out with something very simple. Like just two classes of attributes, protected (z-) and normal (x-). Then see if that can be used to model what you need. Occasionally you might need to hack, such as duplicating and object, but that is OK. If needed add a bit more.OTOH The Window's model is much more sophisticated. Full ACLs, with arbitrary permissions assignable to arbitrary (groups of) users, and inheritance, very complex environments can be modeled. But it is a complete mess. Nobody really understands it. The default tools make it impossible to understand or confirm security of a larger number of files. In order to make it usable "home groups" were introduced whose exact semantics are very vague. And all this makes the system ultimately insecure to use in practice.One thing to keep in mind is the need to keep things simple.Consider the Unix and Windows file access control systems. The Unix model is very crude and has not changed in 30 years. There are just three classifications (user/group/others) and a few bits of persmissions. Yet, with BSD's addition of multiple groups, it gets the job done. More over, everyone understands it, and it is easy to see what is going on with ls -l.On Fri, May 6, 2016 at 6:19 AM, Mark Joseph <email@example.com> wrote:I don't think we should take this to the entire group for a while. I suggest a few of us work on it and invite anyone else to join our little group separately. Last week we just got silence from the entire group.Government oriented is fine just as long as we distinguish mandatory and discretionary access controls. Label based systems are mandatory.Also I think we need structures for anything that can have multiple versions of things. Not sure what your issue is with structures but we don't have any technical issue against them.We could do a small conference call just with our own smaller group. I doubt Tony would have an issue with it.
On May 5, 2016, at 1:13 PM, Lockhart, Robert <Robert.Lockhart@thalesesec.com> wrote:
Something to definitely discuss next meeting. I have some additional questions that can wait and maybe clarify my particular use case which was government oriented. Also I want to be sure we are not requiring every attribute have a structure associated with it are we? Just the ones that require additional protection based on an associated security level for a given attribute.
Robert A. (Bob) Lockhart
Chief Solutions Architect
Thales e-Security, Inc.
My understanding was that one of the primary use cases for this was multi-level secure systems. In which case it is using mandatory access controls. So the notion of a time out on an attribute does not make sense in that domain unless I have misunderstood your description
I do agree with your general approach let's pick a few domains and run with just those. Using a structure like key block which can morph into different things.
We could also make most of the structures repeatable. So for one domain there will be just one attitude (e.g. US security label) but other domains can have multiple. This may let us avoid the US vs Australia defense thing. Just a thought.
On May 5, 2016, at 12:05 PM, Lockhart, Robert <Robert.Lockhart@thalesesec.com> wrote:
I am a bit concerned about getting too granular with tags. While I know we have way more than enough numbers, I would prefer to keep them non-specific and if someone wants to define an extension that denotes US vs. Australia then leave it to them to define in more depth or request we add one for them. I would lump the domains into very generic buckets similar to what you did for PII data. If an organization wants us to define a specific domain for them, they can request it and we can decide then. Until then I would consider keeping it simple. Otherwise you end up with around ~206 defense/defence organization tags, 194+ health care tags and a subset of those with financial bodies you would need to include.
My suggestion would be to narrow it down to the following for simplicity (forgive my lack of international spelling as I only write American courtesy of my spell checker):
1 Governmental Non-defense
3 Health Care
4 Personally Identifiable Information
5 – 7fffffff Reserved for future use
80000000 – FFFFFFFF Custom Extensions
I would also like to see expiration or destruction date for attributes that require security in the Distribution Protection, Storage Protection section or as its own attribute in the Object Structure. I have seen a use case that required that a portion of the information on a particular object had to go buh-bye prior to the actual object it was about (redaction anyone? – Can’t wait to display black felt pen marks on a key detail screen). We could get long haired here and discuss a validity time versus a date on the off chance someone uses a common structure for multiple objects but I would prefer to stay away from it for now and just specify an attribute destroy date.
P.S. The 206 number comes from counting countries that don’t have global recognition like Taiwan, Kosovo, Western Sahara, Greenland, Palestine, etc… and only count the UK as one country instead of the four countries it is comprised of along with a few nation-states thrown in for fun. The 194 number is from the number of countries or at least by worldatlas.com.
P.P.S. The U.S. recognizes 195 countries today.
That’s it from me for today’s geography and international politics lesson.
Robert A. (Bob) Lockhart
Chief Solutions Architect
Thales e-Security, Inc.
Great points all!
Two questions, just asking for clarification
1) In the Department of Defense example the table has two security labels one at TS and one at S. How can one piece of data have two labels?
Consider a MLS solutions where something could be authorized for Secret or Top Secret Storage that was the idea. Where there are multiple labels associated with all the authorized security levels.
2) In the US health care case, access is typically controlled by RBAC (we have a customer in this area and this seems how its done) I just see
peoples names in the who has access no notion of access rules.
This is more of an Attribute Based Access Control (ABAC) model that takes it cues from the providers (My esteemed colleagues and Dr. Howser) and the appropriate ICD 10 tags for conditions as part of the labeling scheme that ends up being a combination of provider and condition.
3) Also in the who has access I just see text names, these are some type of user ids right?
Those are IDs and can be any type of ID….. kept those human readable for the sake of example
Howdy KMIP TC!
Here is the updated spreadsheet for Handling Instructions with examples for Healthcare and DoD.
-- Mr. Charles White
Document Name: Handling Instruction_w_Examples.xlsx
Submitter: Mr. Charles White
Group: OASIS Key Management Interoperability Protocol (KMIP) TC
Date submitted: 2016-04-28 08:40:39