Subject: Re: [sacm] Mobile devices

From: Tony Rutkowski <[email-masked]>
Date: Wed, 22 Apr 2015 12:34:43 -0000

What does it mean to denominate them as not central.  The rationality here is rather incomprehensible. Everything is mobile.On Mar 25, 2015 8:23 PM, Clifford Kahn <[email-masked]> wrote:
>
> If I understand right, the consensus is that mobile devices are not central. In some slice of the world they aren't. But in the commercial world they are. I believe that in much of the commercial world, mobile devices are the *main* compliance concern.
>
>  
>
> If the initial SACM standards are silent on how to monitor compliance of these devices, the standards will not help a large segment. That will hinder adoption – perhaps terribly.
>
>  
>
> I appreciate that we need to create a set of standards that are *useful*, *soon*. I am all over that.
>
>  
>
> But that requires wise pruning, not just pruning. There won’t be a SACM 2.0 unless SACM 1.0 gets adopted.
>
>  
>
> Full disclosure: I work for a mobile security company. I don’t think that invalidates my argument.
>
>  
>
> Best,
>
>                                                 Cliff
>
>  
>
> Clifford Kahn
>
> Principal Engineeer, Technical Lead
>
>

---

From: "Adam W. Montville" <[email-masked]>
Date: Wed, 22 Apr 2015 09:48:29 -0500

I’d like to clarify what I meant when I said “mechanism” (which wasn’t the better term to use) as a way to potentially avoid the “device type” boundaries (which are ultimately considered fiat boundaries anyway).  

The way I’ve been trying to approach this is to look at the different sources of data and make some attempt to classify them in some manner.  What follows is not perfect, but it may provide a starting point for discussion.  Also, this perspective isn’t new - OVAL pretty much does it this way today, though it could possibly be improved.

There are a limited number of ways to collect specific data about endpoints (considering “direct" observation only for the time being), whether such devices are workstations, servers, virtualized instances of said servers or workstations, mobile devices, constrained devices, or what have you.  

Let’s call these things “collection points” (trying to get away from “method” or “mechanism”).

We might end up with Collection Point that is the top-level class to things like: Command, File Content, Object Attribute, Query, Registry.  

A Command might contain a subclass called Shell, which may have children of Bash and PowerShell, among others.

File Content might contain subclasses labeled Binary File Content and Text File Content.  Text File Content may be subclassed with things like Apache HTTP Configuration File Content, Java Properties File Content, JSON File Content, Key-value File Content, NginX Configuration File Content, SSH Configuration File Content, XML File Content, and so on.

Object Attribute may have a child class labeled File Attribute, which in turn might include something like File Permission, which would likely have Unix File Permission and Windows File Permission as children.

Query could be subclassed into API Query, Data Query, and Protocol.  An API Query could be subclassed into things like Amazon EC2 API, NETCONF, REST.  Data Query could be subclassed into things like Cypher Query, SPARQL Query, SQL Query, WMI Query and so on.  Protocol could be subclassed into NETCONF (not sure where to put this one), LDAP, and potentially others.

Registry could be subclassed into Windows Registry.

By looking at things in this way, we obviate the relevance of the “device type” discussion entirely, and we possibly provide a better way of supporting the most possible things in the shortest amount of time.

Should I duck and cover now?

Kind regards,

Adam

> On Mar 25, 2015, at 7:51 PM, Tony Rutkowski <[email-masked]> wrote:
> 
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: Gunnar Engelbach <[email-masked]>
Date: Wed, 22 Apr 2015 11:15:00 -0400

I have to agree with the instinct to categorize in this manner and 
refine those generalizations into usable specifics.  And yes, this is 
what OVAL already does, but OVAL's inheritance hierarchy is more closely 
refined by operating systems rather than data types as you've outlined 
-- not saying either is better at this point, just pointing out the 
difference.

A caveat to using an approach like this is that you need to acknowledge 
there are going to be collectables that aren't obviously derivative of 
one category or another and might in fact benefit from multiple inheritance.

One lesson learned from OVAL that I can't stress enough is to completely 
disconnect the attributes to be collected from the manner of collection.

Since you mentioned WMI, I'll pick on that as an example.  WMI is a 
*method* for collecting system information but is not a repository for 
any of that information.  In other words, anything that can be collected 
via WMI can also be collected by other means (and in cases of things 
that fall under the RSOP namespace, more reliably via other methods).  
But if WMI is treated as an attribute type, then security checks will be 
written using that, and that in turn precludes the ability to get the 
same information via other methods.

Being careful about this distinction also means not having to worry 
about whether or not we have to explicitly support any particular 
collection method like SNMP, NETCONF, and so on.

-- gun

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 22 Apr 2015 11:24:50 -0400

Hi,

I think we are all in agreement here.  If Clifford wants to propose a
collection method solution specific to mobile, he should go ahead and do
that.  He shouldn't be held up by the information and data model.  He may
uncover attributes that are not currently supported that have to expand the
information and data models when the data gets transformed.  These can be
separate activities to make progress.

Thanks,
Kathleen

On Wed, Apr 22, 2015 at 11:15 AM, Gunnar Engelbach <
[email-masked]> wrote:

>
> I have to agree with the instinct to categorize in this manner and refine
> those generalizations into usable specifics.  And yes, this is what OVAL
> already does, but OVAL's inheritance hierarchy is more closely refined by
> operating systems rather than data types as you've outlined -- not saying
> either is better at this point, just pointing out the difference.
>
> there are going to be collectables that aren't obviously derivative of one
> category or another and might in fact benefit from multiple inheritance.
>
> *method* for collecting system information but is not a repository for any
> of that information.  In other words, anything that can be collected via
> WMI can also be collected by other means (and in cases of things that fall
> under the RSOP namespace, more reliably via other methods).  But if WMI is
> treated as an attribute type, then security checks will be written using
> that, and that in turn precludes the ability to get the same information
> via other methods.
>
> Being careful about this distinction also means not having to worry about
> whether or not we have to explicitly support any particular collection
> method like SNMP, NETCONF, and so on.
>
>
> -- gun
>
>
>
>> I’d like to clarify what I meant when I said “mechanism” (which wasn’t
>> the better term to use) as a way to potentially avoid the “device type”
>> boundaries (which are ultimately considered fiat boundaries anyway).
>>
>> The way I’ve been trying to approach this is to look at the different
>> sources of data and make some attempt to classify them in some manner.
>> What follows is not perfect, but it may provide a starting point for
>> discussion.  Also, this perspective isn’t new - OVAL pretty much does it
>> this way today, though it could possibly be improved.
>>
>> There are a limited number of ways to collect specific data about
>> endpoints (considering “direct" observation only for the time being),
>> whether such devices are workstations, servers, virtualized instances of
>> said servers or workstations, mobile devices, constrained devices, or what
>> have you.
>>
>> We might end up with Collection Point that is the top-level class to
>> things like: Command, File Content, Object Attribute, Query, Registry.
>>
>> File Content might contain subclasses labeled Binary File Content and
>> Text File Content.  Text File Content may be subclassed with things like
>> Apache HTTP Configuration File Content, Java Properties File Content, JSON
>> File Content, Key-value File Content, NginX Configuration File Content, SSH
>> Configuration File Content, XML File Content, and so on.
>>
>> Object Attribute may have a child class labeled File Attribute, which in
>> turn might include something like File Permission, which would likely have
>> Unix File Permission and Windows File Permission as children.
>>
>> Query could be subclassed into API Query, Data Query, and Protocol.  An
>> API Query could be subclassed into things like Amazon EC2 API, NETCONF,
>> REST.  Data Query could be subclassed into things like Cypher Query, SPARQL
>> Query, SQL Query, WMI Query and so on.  Protocol could be subclassed into
>> NETCONF (not sure where to put this one), LDAP, and potentially others.
>>
>> By looking at things in this way, we obviate the relevance of the “device
>> type” discussion entirely, and we possibly provide a better way of
>> supporting the most possible things in the shortest amount of time.
>>
>>> What does it mean to denominate them as not central.  The rationality
>>> here is rather incomprehensible. Everything is mobile.On Mar 25, 2015 8:23
>>> PM, Clifford Kahn <[email-masked]> wrote:
>>>
>>>> If I understand right, the consensus is that mobile devices are not
>>>> central. In some slice of the world they aren't. But in the commercial
>>>> world they are. I believe that in much of the commercial world, mobile
>>>> devices are the *main* compliance concern.
>>>>
>>>>
>>>> If the initial SACM standards are silent on how to monitor compliance
>>>> of these devices, the standards will not help a large segment. That will
>>>> hinder adoption – perhaps terribly.
>>>>
>>>>

-- 

Best regards,
Kathleen

---

From: "Adam W. Montville" <[email-masked]>
Date: Wed, 22 Apr 2015 11:14:23 -0500

> On Apr 22, 2015, at 10:24 AM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hi,
> 
> I think we are all in agreement here.  If Clifford wants to propose a collection method solution specific to mobile, he should go ahead and do that. 

Yes, if anyone has something they’d like to submit, please do so.

> He shouldn't be held up by the information and data model.

Other than that he’s already got endpoint ID tasks and information model work on his plate...

>   He may uncover attributes that are not currently supported that have to expand the information and data models when the data gets transformed.  These can be separate activities to make progress.

Separate activities are absolutely encouraged.  Still, successful parallelization requires a multiprocessor environment, and right now, our set of processors is limited.

> 
> Thanks,
> Kathleen
> 
> On Wed, Apr 22, 2015 at 11:15 AM, Gunnar Engelbach <[email-masked] <mailto:[email-masked]>> wrote:
> 
> I have to agree with the instinct to categorize in this manner and refine those generalizations into usable specifics.  And yes, this is what OVAL already does, but OVAL's inheritance hierarchy is more closely refined by operating systems rather than data types as you've outlined -- not saying either is better at this point, just pointing out the difference.
> 
> A caveat to using an approach like this is that you need to acknowledge there are going to be collectables that aren't obviously derivative of one category or another and might in fact benefit from multiple inheritance.
> 
> One lesson learned from OVAL that I can't stress enough is to completely disconnect the attributes to be collected from the manner of collection.
> 
> Since you mentioned WMI, I'll pick on that as an example.  WMI is a *method* for collecting system information but is not a repository for any of that information.  In other words, anything that can be collected via WMI can also be collected by other means (and in cases of things that fall under the RSOP namespace, more reliably via other methods).  But if WMI is treated as an attribute type, then security checks will be written using that, and that in turn precludes the ability to get the same information via other methods.
> 
> Being careful about this distinction also means not having to worry about whether or not we have to explicitly support any particular collection method like SNMP, NETCONF, and so on.
> 
> 
> -- gun
> 
> 
> 
> On Mar 25, 2015, at 7:51 PM, Tony Rutkowski <[email-masked] <mailto:[email-masked]>> wrote:
> 
> What does it mean to denominate them as not central.  The rationality here is rather incomprehensible. Everything is mobile.On Mar 25, 2015 8:23 PM, Clifford Kahn <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>
> 
> 
> 
> -- 
> 
> Best regards,
> Kathleen