Subject: [sacm] How to know if you are really hacked or not

From: Fahima Ahmed Khan Etha <[email-masked]>
Date: Thu, 16 Oct 2014 10:10:39 +0600

Dear All,

It might be an off topic. But I am seeking guidance from all of you.

If any hacker group claimed that you are hacked... How to proof or find out
its authenticity?

Please share your view.

Best regards,

Fahima

On 15 October 2014 21:08, Adam W. Montville <[email-masked]>
wrote:

> Lisa,
>
> Below are a few comments on the combined information model draft - these
> aren’t necessarily the only comments I have, but they are those I think are
> warranted to make at this point.  As with my recent comments concerning the
> architecture and requirements drafts, I’m holding nits until a later
> stage.  I apologize for not getting these out to the list sooner, as I did
> review the draft a few weeks ago.
>
> In Section 4.1 there’s an “EDITOR’S NOTE” suggesting that the endpoints to
> which a given endpoint connects affects its security posture.  So, the
> logic goes something like this: Endpoint A connects to endpoint B,
> therefore endpoint A’s posture is affected.  I assert this is not true.
>
> We have defined posture, based on the definition found in RFC5209, as
> “configuration and/or status of hardware or software on an endpoint as it
> pertains to an organization’s security policy.”  There is no mention of
> connection to other endpoints in this definition.  Even if we wanted to
> expand the definition, I would argue strongly against, taking the position
> that how endpoint B affects endpoint A is in terms of it’s risk profile,
> not it’s posture.  The desired posture for endpoint A may change based on
> the posture and/or behavioral characteristics of endpoint B, but endpoint
> A’s posture does not change.
>
> In short, I want to avoid bringing this dimension into our present body of
> work without precluding the ability in the future.
>
> In Section 4.1.3 I’d encourage consistency of granularity in what we view
> as an “asset".  The granularity is pretty intense when you examine it
> closely - I’m not against a fine granularity (quite for it in fact).
>
> On one hand, we’re being as fine grained as saying that a “patch” and
> javascript are examples of software assets (the latter implying that the
> Web page containing or referencing that javascript is an asset as well, and
> the former possibly implying that the executable installing the patch is
> the asset over the patch information itself), and on the other hand, we’re
> conflating assets in the harmful software example of an “entertainment app
> that contains malware.”  Is it the entertainment app or the malware that is
> harmful?  If we’re going to be as granular as this section is, then I’d
> like to be more consistent so we don’t run into trouble down the road.
>
> In Section 4.7.7 there’s a nuance we may want to capture.  The
> non-technical example is a good one.  The example is that “closed” is an
> attribute of a door, and that a closed door tends to stay closed until
> something opens it.  I’d like to be more explicit to say that “closed” and
> "open” are always attributes of a door, but that they are either true or
> false at some point in time, and that they can never be true at the same
> time.  The attribute itself doesn’t actually change, but it’s state does.
> So, the previous statement of “An attribute tends to stay true until
> something causes a change” isn’t exactly right.  Instead, the state of an
> attribute tends to stay true until something causes a change.  Put another
> way, I don’t enjoy the idea of attributes coming and going and would rather
> have attributes attached with state information.
>
> Finally, I see a lot of off-list discussions reflected in the draft -
> discussions I would prefer to see on the list.  This is especially true now
> that the information model has been adopted (and even though there is not
> yet an official WG draft).  I understand that there might be a desire for a
> few more iterations (at least one more) before we create a WG submission,
> but I would much rather prefer on-list communication about this draft than
> off-list.
>
> Regards,
>
> Adam
>
>
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 16 Oct 2014 07:29:59 -0400

If interested in this discussion, let's respond on the SAAG list and not across all lists.

Thank you,
Kathleen

Sent from my iPhone

> On Oct 16, 2014, at 12:10 AM, Fahima Ahmed Khan Etha <[email-masked]> wrote:
> 
> Dear All,
> 
> If any hacker group claimed that you are hacked... How to proof or find out its authenticity?
> 
> Please share your view.
> 
> Best regards,
> Fahima
> 
> 
>> On 15 October 2014 21:08, Adam W. Montville <[email-masked]> wrote:
>> Lisa,
>> 
>> Below are a few comments on the combined information model draft - these aren’t necessarily the only comments I have, but they are those I think are warranted to make at this point.  As with my recent comments concerning the architecture and requirements drafts, I’m holding nits until a later stage.  I apologize for not getting these out to the list sooner, as I did review the draft a few weeks ago.
>> 
>> In Section 4.1 there’s an “EDITOR’S NOTE” suggesting that the endpoints to which a given endpoint connects affects its security posture.  So, the logic goes something like this: Endpoint A connects to endpoint B, therefore endpoint A’s posture is affected.  I assert this is not true.
>> 
>> We have defined posture, based on the definition found in RFC5209, as “configuration and/or status of hardware or software on an endpoint as it pertains to an organization’s security policy.”  There is no mention of connection to other endpoints in this definition.  Even if we wanted to expand the definition, I would argue strongly against, taking the position that how endpoint B affects endpoint A is in terms of it’s risk profile, not it’s posture.  The desired posture for endpoint A may change based on the posture and/or behavioral characteristics of endpoint B, but endpoint A’s posture does not change.
>> 
>> In short, I want to avoid bringing this dimension into our present body of work without precluding the ability in the future.
>> 
>> In Section 4.1.3 I’d encourage consistency of granularity in what we view as an “asset".  The granularity is pretty intense when you examine it closely - I’m not against a fine granularity (quite for it in fact).
>> 
>> On one hand, we’re being as fine grained as saying that a “patch” and javascript are examples of software assets (the latter implying that the Web page containing or referencing that javascript is an asset as well, and the former possibly implying that the executable installing the patch is the asset over the patch information itself), and on the other hand, we’re conflating assets in the harmful software example of an “entertainment app that contains malware.”  Is it the entertainment app or the malware that is harmful?  If we’re going to be as granular as this section is, then I’d like to be more consistent so we don’t run into trouble down the road.
>> 
>> In Section 4.7.7 there’s a nuance we may want to capture.  The non-technical example is a good one.  The example is that “closed” is an attribute of a door, and that a closed door tends to stay closed until something opens it.  I’d like to be more explicit to say that “closed” and "open” are always attributes of a door, but that they are either true or false at some point in time, and that they can never be true at the same time.  The attribute itself doesn’t actually change, but it’s state does.  So, the previous statement of “An attribute tends to stay true until something causes a change” isn’t exactly right.  Instead, the state of an attribute tends to stay true until something causes a change.  Put another way, I don’t enjoy the idea of attributes coming and going and would rather have attributes attached with state information.
>> 
>> Finally, I see a lot of off-list discussions reflected in the draft - discussions I would prefer to see on the list.  This is especially true now that the information model has been adopted (and even though there is not yet an official WG draft).  I understand that there might be a desire for a few more iterations (at least one more) before we create a WG submission, but I would much rather prefer on-list communication about this draft than off-list.
>> 
>> Regards,
>> 
>> Adam
>> 
>> 
>>