After much rumination over the past week, I decided to put some thoughts down in an email, see if I can push the football forward in a different direction.
For the contents of each control, this is what I need to answer:
Yes/No/Not Applicable
Corresponds to Product: I don't do this for you now, but if you buy this product I will.
Short answer--maybe limited to 300/500 characters?
Long answer--the verbose "2-paragraph" answer, limit to 1500 characters?
Control subcomponent traceability matrix: by "subcomponent" (OS, web interface, router, firewall, etc) implementation details.
Customer responsibility: what parts of this control are customer-configurable or not provided by me as the service provider.
Date of last test: certification date or assessment date.
Evidence of last test: allowed to include a .zip of artifacts.
Control assessment findings: if I have any findings corresponding to this control.
Mitigation roadmap: I don't do this now but I will do part A by FooDate1, Part B by FooDate2, etc.
Does this make sense or am I smoking crack as usual? The trick to me is access control on the service provider side as to what level of information I would provide based upon user roles which are based on use cases. IE, I don't want to give non-customers anything more in-depth than the short answer.
----- Original Message ----
From: Michael Smith <rybo...@ryzhe.ath.cx>
To: cloudaudit@googlegroups.com
Sent: Thu, May 20, 2010 7:40:57 PM
Subject: I was Thinking and came up with some Evil
After much rumination over the past week, I decided to put some thoughts down in an email, see if I can push the football forward in a different direction.
For the contents of each control, this is what I need to answer:
Yes/No/Not Applicable
Corresponds to Product: I don't do this for you now, but if you buy this product I will.
Short answer--maybe limited to 300/500 characters?
Long answer--the verbose "2-paragraph" answer, limit to 1500 characters?
Control subcomponent traceability matrix: by "subcomponent" (OS, web interface, router, firewall, etc) implementation details.
Customer responsibility: what parts of this control are customer-configurable or not provided by me as the service provider.
Date of last test: certification date or assessment date.
Evidence of last test: allowed to include a .zip of artifacts.
Control assessment findings: if I have any findings corresponding to this control.
Mitigation roadmap: I don't do this now but I will do part A by FooDate1, Part B by FooDate2, etc.
Does this make sense or am I smoking crack as usual? The trick to me is access control on the service provider side as to what level of information I would provide based upon user roles which are based on use cases. IE, I don't want to give non-customers anything more in-depth than the short answer.
I'm having trouble contrasting "not understood" versus a 404 code (of
does not exist)
can you describe the case where replying with a 404 code, which
indicates the provider doesn't have an answer that should have been
responded to with a not understood?
On May 21, 5:33 pm, James Urquhart <jurquh...@yahoo.com> wrote:
> I would ask one more item to your basic answers:
> Yes/No/Not Applicable/Not Understood
> Thus, requests that are not recognized by the provider can get a distinct response.
> James Urquhart
> ----- Original Message ----
> From: Michael Smith <rybo...@ryzhe.ath.cx>
> To: cloudaudit@googlegroups.com
> Sent: Thu, May 20, 2010 7:40:57 PM
> Subject: I was Thinking and came up with some Evil
> After much rumination over the past week, I decided to put some thoughts down in an email, see if I can push the football forward in a different direction.
> For the contents of each control, this is what I need to answer:
> Yes/No/Not Applicable
> Corresponds to Product: I don't do this for you now, but if you buy this product I will.
> Short answer--maybe limited to 300/500 characters?
> Long answer--the verbose "2-paragraph" answer, limit to 1500 characters?
> Control subcomponent traceability matrix: by "subcomponent" (OS, web interface, router, firewall, etc) implementation details.
> Customer responsibility: what parts of this control are customer-configurable or not provided by me as the service provider.
> Date of last test: certification date or assessment date.
> Evidence of last test: allowed to include a .zip of artifacts.
> Control assessment findings: if I have any findings corresponding to this control.
> Mitigation roadmap: I don't do this now but I will do part A by FooDate1, Part B by FooDate2, etc.
> Does this make sense or am I smoking crack as usual? The trick to me is access control on the service provider side as to what level of information I would provide based upon user roles which are based on use cases. IE, I don't want to give non-customers anything more in-depth than the short answer.
> --
> > <))))*> Michael J. Smith, CISSP-ISSEP
> rybo...@ryzhe.ath.cx codey...@yahoo.com
> Blog:http://www.guerilla-ciso.com/ > Twitter: @rybolov
it makes a lot of sense, but I think there are two things to consider:
1) We need a structured way to describe controls and control
mechanisms
2) We're trying to bootstrap here, this sounds like a great
evolutionary path for a next release
On May 20, 10:40 pm, Michael Smith <rybo...@ryzhe.ath.cx> wrote:
> After much rumination over the past week, I decided to put some thoughts
> down in an email, see if I can push the football forward in a different
> direction.
> For the contents of each control, this is what I need to answer:
> Yes/No/Not Applicable
> Corresponds to Product: I don't do this for you now, but if you buy
> this product I will.
> Short answer--maybe limited to 300/500 characters?
> Long answer--the verbose "2-paragraph" answer, limit to 1500 characters?
> Control subcomponent traceability matrix: by "subcomponent" (OS, web
> interface, router, firewall, etc) implementation details.
> Customer responsibility: what parts of this control are
> customer-configurable or not provided by me as the service provider.
> Date of last test: certification date or assessment date.
> Evidence of last test: allowed to include a .zip of artifacts.
> Control assessment findings: if I have any findings corresponding to
> this control.
> Mitigation roadmap: I don't do this now but I will do part A by
> FooDate1, Part B by FooDate2, etc.
> Does this make sense or am I smoking crack as usual? The trick to me is
> access control on the service provider side as to what level of
> information I would provide based upon user roles which are based on use
> cases. IE, I don't want to give non-customers anything more in-depth
> than the short answer.
Also bear in mind that for this version we're constrained to "normal"
response codes (e.g. file doesn't exist == 404), even if there are others
that may make sense for different semantics.
On Sat, May 22, 2010 at 7:00 PM, Ben Sapiro <b...@sapiro.net> wrote:
> I'm having trouble contrasting "not understood" versus a 404 code (of
> does not exist)
> can you describe the case where replying with a 404 code, which
> indicates the provider doesn't have an answer that should have been
> responded to with a not understood?
> On May 21, 5:33 pm, James Urquhart <jurquh...@yahoo.com> wrote:
> > I would ask one more item to your basic answers:
> > Yes/No/Not Applicable/Not Understood
> > Thus, requests that are not recognized by the provider can get a distinct
> response.
> > James Urquhart
> > ----- Original Message ----
> > From: Michael Smith <rybo...@ryzhe.ath.cx>
> > To: cloudaudit@googlegroups.com
> > Sent: Thu, May 20, 2010 7:40:57 PM
> > Subject: I was Thinking and came up with some Evil
> > After much rumination over the past week, I decided to put some thoughts
> down in an email, see if I can push the football forward in a different
> direction.
> > For the contents of each control, this is what I need to answer:
> > Yes/No/Not Applicable
> > Corresponds to Product: I don't do this for you now, but if you buy this
> product I will.
> > Short answer--maybe limited to 300/500 characters?
> > Long answer--the verbose "2-paragraph" answer, limit to 1500 characters?
> > Control subcomponent traceability matrix: by "subcomponent" (OS, web
> interface, router, firewall, etc) implementation details.
> > Customer responsibility: what parts of this control are
> customer-configurable or not provided by me as the service provider.
> > Date of last test: certification date or assessment date.
> > Evidence of last test: allowed to include a .zip of artifacts.
> > Control assessment findings: if I have any findings corresponding to
> this control.
> > Mitigation roadmap: I don't do this now but I will do part A by
> FooDate1, Part B by FooDate2, etc.
> > Does this make sense or am I smoking crack as usual? The trick to me is
> access control on the service provider side as to what level of information
> I would provide based upon user roles which are based on use cases. IE, I
> don't want to give non-customers anything more in-depth than the short
> answer.
After thinking about it for a bit, 404 is OK, but--as Sam hints--it lacks semantics. 404 could be interpreted as both "I have no clue what you are talking about" and "oops, I should have an answer, but the file is now missing", if I understand correctly. The reaction to the response might differ significantly, depending on the use case. (E.g. I might strike the respondent from future requests in the former case, while retrying repeatedly in the latter).
Then again, my knowledge of HTML codes is pretty elementary--almost kindegarten...
James
________________________________
From: Sam Johnston <s...@samj.net>
To: cloudaudit@googlegroups.com
Sent: Sat, May 22, 2010 10:34:00 AM
Subject: Re: I was Thinking and came up with some Evil
Also bear in mind that for this version we're constrained to "normal" response codes (e.g. file doesn't exist == 404), even if there are others that may make sense for different semantics.
On Sat, May 22, 2010 at 7:00 PM, Ben Sapiro <b...@sapiro.net> wrote:
>I'm having trouble contrasting "not understood" versus a 404 code (of
>>does not exist)
>>can you describe the case where replying with a 404 code, which
>>indicates the provider doesn't have an answer that should have been
>>responded to with a not understood?
>>On May 21, 5:33 pm, James Urquhart <jurquh...@yahoo.com> wrote:
>>> I would ask one more item to your basic answers:
>>> Yes/No/Not Applicable/Not Understood
>>> Thus, requests that are not recognized by the provider can get a distinct response.
>>> James Urquhart
>>> ----- Original Message ----
>> From: Michael Smith <rybo...@ryzhe.ath.cx>
>>> To: cloudaudit@googlegroups.com
>>> Sent: Thu, May 20, 2010 7:40:57 PM
>>> Subject: I was Thinking and came up with some Evil
>>> After much rumination over the past week, I decided to put some thoughts down in an email, see if I can push the football forward in a different direction.
>>> For the contents of each control, this is what I need to answer:
>>> Yes/No/Not Applicable
>>> Corresponds to Product: I don't do this for you now, but if you buy this product I will.
>>> Short answer--maybe limited to 300/500 characters?
>>> Long answer--the verbose "2-paragraph" answer, limit to 1500 characters?
>>> Control subcomponent traceability matrix: by "subcomponent" (OS, web interface, router, firewall, etc) implementation details.
>>> Customer responsibility: what parts of this control are customer-configurable or not provided by me as the service provider.
>>> Date of last test: certification date or assessment date.
>>> Evidence of last test: allowed to include a .zip of artifacts.
>>> Control assessment findings: if I have any findings corresponding to this control.
>>> Mitigation roadmap: I don't do this now but I will do part A by FooDate1, Part B by FooDate2, etc.
>>> Does this make sense or am I smoking crack as usual? The trick to me is access control on the service provider side as to what level of information I would provide based upon user roles which are based on use cases. IE, I don't want to give non-customers anything more in-depth than the short answer.
>>> --
>>> > <))))*> Michael J. Smith, CISSP-ISSEP
>> rybo...@ryzhe.ath.cx codey...@yahoo.com
a) Not understood is 400-Bad request. Which is not the same as 404.
b) 404 is fine if there is no resource, which means the server
understood what is needed, but what is needed is not available.
c) BTW, 204 no content is also possible which says there is nothing to
return.
d) The difference between 2xx and 4xx is that 4xx is an error path
while 2xx is a normal path. So 2xx is a better choice for dealing with known
unknowns while 4xx is for unknown unknowns.
Cheers
<k/>
On 5/22/10 Sat May 22, 10, "James Urquhart" <jurquh...@yahoo.com> wrote:
> After thinking about it for a bit, 404 is OK, but--as Sam hints--it lacks
> semantics. 404 could be interpreted as both "I have no clue what you are
> talking about" and "oops, I should have an answer, but the file is now
> missing", if I understand correctly. The reaction to the response might differ
> significantly, depending on the use case. (E.g. I might strike the respondent
> from future requests in the former case, while retrying repeatedly in the
> latter).
> Then again, my knowledge of HTML codes is pretty elementary--almost
> kindegarten...
> James
> From: Sam Johnston <s...@samj.net>
> To: cloudaudit@googlegroups.com
> Sent: Sat, May 22, 2010 10:34:00 AM
> Subject: Re: I was Thinking and came up with some Evil
> Also bear in mind that for this version we're constrained to "normal" response
> codes (e.g. file doesn't exist == 404), even if there are others that may make
> sense for different semantics.
> Sam (in Berlin)
> On Sat, May 22, 2010 at 7:00 PM, Ben Sapiro <b...@sapiro.net> wrote:
>> I'm having trouble contrasting "not understood" versus a 404 code (of
>> does not exist)
>> can you describe the case where replying with a 404 code, which
>> indicates the provider doesn't have an answer that should have been
>> responded to with a not understood?
>> On May 21, 5:33 pm, James Urquhart <jurquh...@yahoo.com> wrote:
>>> > I would ask one more item to your basic answers:
>>> > Yes/No/Not Applicable/Not Understood
>>> > Thus, requests that are not recognized by the provider can get a distinct
>>> response.
>>> > James Urquhart
>>> > ----- Original Message ----
>>> > From: Michael Smith <rybo...@ryzhe.ath.cx>
>>> > To: cloudaudit@googlegroups.com
>>> > Sent: Thu, May 20, 2010 7:40:57 PM
>>> > Subject: I was Thinking and came up with some Evil
>>> > After much rumination over the past week, I decided to put some thoughts
>>> down in an email, see if I can push the football forward in a different
>>> direction.
>>> > For the contents of each control, this is what I need to answer:
>>> > Yes/No/Not Applicable
>>> > Corresponds to Product: I don't do this for you now, but if you buy this
>>> product I will.
>>> > Short answer--maybe limited to 300/500 characters?
>>> > Long answer--the verbose "2-paragraph" answer, limit to 1500 characters?
>>> > Control subcomponent traceability matrix: by "subcomponent" (OS, web
>>> interface, router, firewall, etc) implementation details.
>>> > Customer responsibility: what parts of this control are
>>> customer-configurable or not provided by me as the service provider.
>>> > Date of last test: certification date or assessment date.
>>> > Evidence of last test: allowed to include a .zip of artifacts.
>>> > Control assessment findings: if I have any findings corresponding to this
>>> control.
>>> > Mitigation roadmap: I don't do this now but I will do part A by FooDate1,
>>> Part B by FooDate2, etc.
>>> > Does this make sense or am I smoking crack as usual? The trick to me is
>>> access control on the service provider side as to what level of information
>>> I would provide based upon user roles which are based on use cases. IE, I
>>> don't want to give non-customers anything more in-depth than the short
>>> answer.
true, however - triggering alternate response codes requires either
deploying server side code or modifying the web server config.
The former is contrary to the requirement to deployable via flat files
and a directory structure alone (that is, a provider doesn't need to
write code to do this)
The latter is challenging (trivially so) given the diversity of web
servers and likely reluctance of an admin to modify their
configurations.
Additionally, is it appropriate to apply new semantics to codes that
already have meaning? As a browser I know that 404 means something
isn't there or 403 means I'm not allowed in, but if I start using 204
or 400 codes to indicate something other than exactly what the
designers intended, we run the risk of ambiguity in client side
interpretation, a normal browser might interpret it one way (remember
we're supposed to be human accessible as well) while our client tools
interpret it another.
We should use response codes exactly as intended by the original
authors and express our specific semantics through different
mechanisms (where they aren't 100% equal with RFC2616 and meaning is
completely unambiguous to all consumers).
On May 23, 1:43 am, Krishna Sankar <ksanka...@gmail.com> wrote:
> a) Not understood is 400-Bad request. Which is not the same as 404.
> b) 404 is fine if there is no resource, which means the server
> understood what is needed, but what is needed is not available.
> c) BTW, 204 no content is also possible which says there is nothing to
> return.
> d) The difference between 2xx and 4xx is that 4xx is an error path
> while 2xx is a normal path. So 2xx is a better choice for dealing with known
> unknowns while 4xx is for unknown unknowns.
> Cheers
> <k/>
> On 5/22/10 Sat May 22, 10, "James Urquhart" <jurquh...@yahoo.com> wrote:
> > After thinking about it for a bit, 404 is OK, but--as Sam hints--it lacks
> > semantics. 404 could be interpreted as both "I have no clue what you are
> > talking about" and "oops, I should have an answer, but the file is now
> > missing", if I understand correctly. The reaction to the response might differ
> > significantly, depending on the use case. (E.g. I might strike the respondent
> > from future requests in the former case, while retrying repeatedly in the
> > latter).
> > Then again, my knowledge of HTML codes is pretty elementary--almost
> > kindegarten...
> > James
> > From: Sam Johnston <s...@samj.net>
> > To: cloudaudit@googlegroups.com
> > Sent: Sat, May 22, 2010 10:34:00 AM
> > Subject: Re: I was Thinking and came up with some Evil
> > Also bear in mind that for this version we're constrained to "normal" response
> > codes (e.g. file doesn't exist == 404), even if there are others that may make
> > sense for different semantics.
> > Sam (in Berlin)
> > On Sat, May 22, 2010 at 7:00 PM, Ben Sapiro <b...@sapiro.net> wrote:
> >> I'm having trouble contrasting "not understood" versus a 404 code (of
> >> does not exist)
> >> can you describe the case where replying with a 404 code, which
> >> indicates the provider doesn't have an answer that should have been
> >> responded to with a not understood?
> >> On May 21, 5:33 pm, James Urquhart <jurquh...@yahoo.com> wrote:
> >>> > I would ask one more item to your basic answers:
> >>> > Yes/No/Not Applicable/Not Understood
> >>> > Thus, requests that are not recognized by the provider can get a distinct
> >>> response.
> >>> > James Urquhart
> >>> > ----- Original Message ----
> >>> > From: Michael Smith <rybo...@ryzhe.ath.cx>
> >>> > To: cloudaudit@googlegroups.com
> >>> > Sent: Thu, May 20, 2010 7:40:57 PM
> >>> > Subject: I was Thinking and came up with some Evil
> >>> > After much rumination over the past week, I decided to put some thoughts
> >>> down in an email, see if I can push the football forward in a different
> >>> direction.
> >>> > For the contents of each control, this is what I need to answer:
> >>> > Yes/No/Not Applicable
> >>> > Corresponds to Product: I don't do this for you now, but if you buy this
> >>> product I will.
> >>> > Short answer--maybe limited to 300/500 characters?
> >>> > Long answer--the verbose "2-paragraph" answer, limit to 1500 characters?
> >>> > Control subcomponent traceability matrix: by "subcomponent" (OS, web
> >>> interface, router, firewall, etc) implementation details.
> >>> > Customer responsibility: what parts of this control are
> >>> customer-configurable or not provided by me as the service provider.
> >>> > Date of last test: certification date or assessment date.
> >>> > Evidence of last test: allowed to include a .zip of artifacts.
> >>> > Control assessment findings: if I have any findings corresponding to this
> >>> control.
> >>> > Mitigation roadmap: I don't do this now but I will do part A by FooDate1,
> >>> Part B by FooDate2, etc.
> >>> > Does this make sense or am I smoking crack as usual? The trick to me is
> >>> access control on the service provider side as to what level of information
> >>> I would provide based upon user roles which are based on use cases. IE, I
> >>> don't want to give non-customers anything more in-depth than the short
> >>> answer.
So for these two cases, I think we already have the answer
"I have no clue what you are talking about"
Return a 404 code - indicating it's not there, we haven't considered
it, we have no answer
"oops, I should have an answer, but the file is now missing"
Return a 200 code plus an unqualified answer of YES in the text
payload - making no files available and with a sufficiently low TTL
which encourages the client to check back again soon
Alternatively, return a 200 code plus an unqualified NOT_APPLICABLE
meaning we've considered this control and we're not answering because
we don't think it applies to us
(apologies that I'm talking to a spec still being written and not yet
presented)
On May 23, 12:39 am, James Urquhart <jurquh...@yahoo.com> wrote:
> After thinking about it for a bit, 404 is OK, but--as Sam hints--it lacks semantics. 404 could be interpreted as both "I have no clue what you are talking about" and "oops, I should have an answer, but the file is now missing", if I understand correctly. The reaction to the response might differ significantly, depending on the use case. (E.g. I might strike the respondent from future requests in the former case, while retrying repeatedly in the latter).
> Then again, my knowledge of HTML codes is pretty elementary--almost kindegarten...
> James
> ________________________________
> From: Sam Johnston <s...@samj.net>
> To: cloudaudit@googlegroups.com
> Sent: Sat, May 22, 2010 10:34:00 AM
> Subject: Re: I was Thinking and came up with some Evil
> Also bear in mind that for this version we're constrained to "normal" response codes (e.g. file doesn't exist == 404), even if there are others that may make sense for different semantics.
> Sam (in Berlin)
> On Sat, May 22, 2010 at 7:00 PM, Ben Sapiro <b...@sapiro.net> wrote:
> >I'm having trouble contrasting "not understood" versus a 404 code (of
> >>does not exist)
> >>can you describe the case where replying with a 404 code, which
> >>indicates the provider doesn't have an answer that should have been
> >>responded to with a not understood?
> >>On May 21, 5:33 pm, James Urquhart <jurquh...@yahoo.com> wrote:
> >>> I would ask one more item to your basic answers:
> >>> Yes/No/Not Applicable/Not Understood
> >>> Thus, requests that are not recognized by the provider can get a distinct response.
> >>> James Urquhart
> >>> ----- Original Message ----
> >> From: Michael Smith <rybo...@ryzhe.ath.cx>
> >>> To: cloudaudit@googlegroups.com
> >>> Sent: Thu, May 20, 2010 7:40:57 PM
> >>> Subject: I was Thinking and came up with some Evil
> >>> After much rumination over the past week, I decided to put some thoughts down in an email, see if I can push the football forward in a different direction.
> >>> For the contents of each control, this is what I need to answer:
> >>> Yes/No/Not Applicable
> >>> Corresponds to Product: I don't do this for you now, but if you buy this product I will.
> >>> Short answer--maybe limited to 300/500 characters?
> >>> Long answer--the verbose "2-paragraph" answer, limit to 1500 characters?
> >>> Control subcomponent traceability matrix: by "subcomponent" (OS, web interface, router, firewall, etc) implementation details.
> >>> Customer responsibility: what parts of this control are customer-configurable or not provided by me as the service provider.
> >>> Date of last test: certification date or assessment date.
> >>> Evidence of last test: allowed to include a .zip of artifacts.
> >>> Control assessment findings: if I have any findings corresponding to this control.
> >>> Mitigation roadmap: I don't do this now but I will do part A by FooDate1, Part B by FooDate2, etc.
> >>> Does this make sense or am I smoking crack as usual? The trick to me is access control on the service provider side as to what level of information I would provide based upon user roles which are based on use cases. IE, I don't want to give non-customers anything more in-depth than the short answer.
> >>> --
> >>> > <))))*> Michael J. Smith, CISSP-ISSEP
> >> rybo...@ryzhe.ath.cx codey...@yahoo.com
----- Original Message ----
From: Ben Sapiro <b...@sapiro.net>
To: CloudAudit <cloudaudit@googlegroups.com>
Sent: Sun, May 23, 2010 6:44:28 AM
Subject: Re: I was Thinking and came up with some Evil
So for these two cases, I think we already have the answer
"I have no clue what you are talking about"
Return a 404 code - indicating it's not there, we haven't considered
it, we have no answer
"oops, I should have an answer, but the file is now missing"
Return a 200 code plus an unqualified answer of YES in the text
payload - making no files available and with a sufficiently low TTL
which encourages the client to check back again soon
Alternatively, return a 200 code plus an unqualified NOT_APPLICABLE
meaning we've considered this control and we're not answering because
we don't think it applies to us
(apologies that I'm talking to a spec still being written and not yet
presented)
On May 23, 12:39 am, James Urquhart <jurquh...@yahoo.com> wrote:
> After thinking about it for a bit, 404 is OK, but--as Sam hints--it lacks semantics. 404 could be interpreted as both "I have no clue what you are talking about" and "oops, I should have an answer, but the file is now missing", if I understand correctly. The reaction to the response might differ significantly, depending on the use case. (E.g. I might strike the respondent from future requests in the former case, while retrying repeatedly in the latter).
> Then again, my knowledge of HTML codes is pretty elementary--almost kindegarten...
> James
> ________________________________
> From: Sam Johnston <s...@samj.net>
> To: cloudaudit@googlegroups.com
> Sent: Sat, May 22, 2010 10:34:00 AM
> Subject: Re: I was Thinking and came up with some Evil
> Also bear in mind that for this version we're constrained to "normal" response codes (e.g. file doesn't exist == 404), even if there are others that may make sense for different semantics.
> Sam (in Berlin)
> On Sat, May 22, 2010 at 7:00 PM, Ben Sapiro <b...@sapiro.net> wrote:
> >I'm having trouble contrasting "not understood" versus a 404 code (of
> >>does not exist)
> >>can you describe the case where replying with a 404 code, which
> >>indicates the provider doesn't have an answer that should have been
> >>responded to with a not understood?
> >>On May 21, 5:33 pm, James Urquhart <jurquh...@yahoo.com> wrote:
> >>> I would ask one more item to your basic answers:
> >>> Yes/No/Not Applicable/Not Understood
> >>> Thus, requests that are not recognized by the provider can get a distinct response.
> >>> James Urquhart
> >>> ----- Original Message ----
> >> From: Michael Smith <rybo...@ryzhe.ath.cx>
> >>> To: cloudaudit@googlegroups.com
> >>> Sent: Thu, May 20, 2010 7:40:57 PM
> >>> Subject: I was Thinking and came up with some Evil
> >>> After much rumination over the past week, I decided to put some thoughts down in an email, see if I can push the football forward in a different direction.
> >>> For the contents of each control, this is what I need to answer:
> >>> Yes/No/Not Applicable
> >>> Corresponds to Product: I don't do this for you now, but if you buy this product I will.
> >>> Short answer--maybe limited to 300/500 characters?
> >>> Long answer--the verbose "2-paragraph" answer, limit to 1500 characters?
> >>> Control subcomponent traceability matrix: by "subcomponent" (OS, web interface, router, firewall, etc) implementation details.
> >>> Customer responsibility: what parts of this control are customer-configurable or not provided by me as the service provider.
> >>> Date of last test: certification date or assessment date.
> >>> Evidence of last test: allowed to include a .zip of artifacts.
> >>> Control assessment findings: if I have any findings corresponding to this control.
> >>> Mitigation roadmap: I don't do this now but I will do part A by FooDate1, Part B by FooDate2, etc.
> >>> Does this make sense or am I smoking crack as usual? The trick to me is access control on the service provider side as to what level of information I would provide based upon user roles which are based on use cases. IE, I don't want to give non-customers anything more in-depth than the short answer.
> >>> --
> >>> > <))))*> Michael J. Smith, CISSP-ISSEP
> >> rybo...@ryzhe.ath.cx codey...@yahoo.com
Folks,
Let us make a table with the request, response conditions and them map
to the HTTP error codes. If we cannot understand the question, 4xx is the
right response. If we understood the question, 2xx is the right response.
For example if one is asking for a file, and the server code looks
somewhere and finds none, most probably 204 no content is the right answer,
saying we got it, but there is no file. Of course, if it finds the file 200
Ok with the contents of the file will be returned.
But as Ben was saying earlier, we are just going to map files to URLs
with no server code, the server will automatically return 404 Not Found or
200 OK with the file contents. (I assume it is a GET to an URL)
IMHO, we need not be too much elaborate - a binary state (file os there
or not there) plus the state in the content should be fine.
I assume the clients will read through the returned content and make
appropriate inferences.
Also need to decide if there will be server code deployed or there will
not be. If not, we will have less control over the HTTP status codes and
that is good - less things to worry about and to go wrong.
Cheers
<k/>
On 5/23/10 Sun May 23, 10, "James Urquhart" <jurquh...@yahoo.com> wrote:
> "I have no clue..." is not an error situation, but a legitimate response to
> the question "can you do this?".
> "Oops..." is an error condition, as I should be able to provide an answer to
> the question, but something technical/logistical went wrong.
> James
> ----- Original Message ----
> From: Ben Sapiro <b...@sapiro.net>
> To: CloudAudit <cloudaudit@googlegroups.com>
> Sent: Sun, May 23, 2010 6:44:28 AM
> Subject: Re: I was Thinking and came up with some Evil
> So for these two cases, I think we already have the answer
> "I have no clue what you are talking about"
> Return a 404 code - indicating it's not there, we haven't considered
> it, we have no answer
> "oops, I should have an answer, but the file is now missing"
> Return a 200 code plus an unqualified answer of YES in the text
> payload - making no files available and with a sufficiently low TTL
> which encourages the client to check back again soon
> Alternatively, return a 200 code plus an unqualified NOT_APPLICABLE
> meaning we've considered this control and we're not answering because
> we don't think it applies to us
> (apologies that I'm talking to a spec still being written and not yet
> presented)
> On May 23, 12:39 am, James Urquhart <jurquh...@yahoo.com> wrote:
>> After thinking about it for a bit, 404 is OK, but--as Sam hints--it lacks
>> semantics. 404 could be interpreted as both "I have no clue what you are
>> talking about" and "oops, I should have an answer, but the file is now
>> missing", if I understand correctly. The reaction to the response might
>> differ significantly, depending on the use case. (E.g. I might strike the
>> respondent from future requests in the former case, while retrying repeatedly
>> in the latter).
>> Then again, my knowledge of HTML codes is pretty elementary--almost
>> kindegarten...
>> James
>> ________________________________
>> From: Sam Johnston <s...@samj.net>
>> To: cloudaudit@googlegroups.com
>> Sent: Sat, May 22, 2010 10:34:00 AM
>> Subject: Re: I was Thinking and came up with some Evil
>> Also bear in mind that for this version we're constrained to "normal"
>> response codes (e.g. file doesn't exist == 404), even if there are others
>> that may make sense for different semantics.
>> Sam (in Berlin)
>> On Sat, May 22, 2010 at 7:00 PM, Ben Sapiro <b...@sapiro.net> wrote:
>>> I'm having trouble contrasting "not understood" versus a 404 code (of
>>>> does not exist)
>>>> can you describe the case where replying with a 404 code, which
>>>> indicates the provider doesn't have an answer that should have been
>>>> responded to with a not understood?
>>>> On May 21, 5:33 pm, James Urquhart <jurquh...@yahoo.com> wrote:
>>>>> I would ask one more item to your basic answers:
>>>>> Yes/No/Not Applicable/Not Understood
>>>>> Thus, requests that are not recognized by the provider can get a distinct
>>>>> response.
>>>>> James Urquhart
>>>>> ----- Original Message ----
>>>> From: Michael Smith <rybo...@ryzhe.ath.cx>
>>>>> To: cloudaudit@googlegroups.com
>>>>> Sent: Thu, May 20, 2010 7:40:57 PM
>>>>> Subject: I was Thinking and came up with some Evil
>>>>> After much rumination over the past week, I decided to put some thoughts
>>>>> down in an email, see if I can push the football forward in a different
>>>>> direction.
>>>>> For the contents of each control, this is what I need to answer:
>>>>> Yes/No/Not Applicable
>>>>> Corresponds to Product: I don't do this for you now, but if you buy this
>>>>> product I will.
>>>>> Short answer--maybe limited to 300/500 characters?
>>>>> Long answer--the verbose "2-paragraph" answer, limit to 1500 characters?
>>>>> Control subcomponent traceability matrix: by "subcomponent" (OS, web
>>>>> interface, router, firewall, etc) implementation details.
>>>>> Customer responsibility: what parts of this control are
>>>>> customer-configurable or not provided by me as the service provider.
>>>>> Date of last test: certification date or assessment date.
>>>>> Evidence of last test: allowed to include a .zip of artifacts.
>>>>> Control assessment findings: if I have any findings corresponding to this
>>>>> control.
>>>>> Mitigation roadmap: I don't do this now but I will do part A by FooDate1,
>>>>> Part B by FooDate2, etc.
>>>>> Does this make sense or am I smoking crack as usual? The trick to me is
>>>>> access control on the service provider side as to what level of
>>>>> information I would provide based upon user roles which are based on use
>>>>> cases. IE, I don't want to give non-customers anything more in-depth than
>>>>> the short answer.
>>>>> --
>>>>>> <))))*> Michael J. Smith, CISSP-ISSEP
>>>> rybo...@ryzhe.ath.cx codey...@yahoo.com
