I was Thinking and came up with some Evil
37 views
Skip to first unread message
Michael Smith
May 20, 2010, 10:40:57 PM5/20/10
to cloud...@googlegroups.com
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
ryb...@ryzhe.ath.cx code...@yahoo.com
Blog: http://www.guerilla-ciso.com/
Twitter: @rybolov
Unable to handle kernel NULL pointer dereference at virtual address
00000000
\|/ ____ \|/
"@'/ .. \`@"
/_| \__/ |_\
\__U_/
Oops, going down hard!
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
ryb...@ryzhe.ath.cx code...@yahoo.com
Blog: http://www.guerilla-ciso.com/
Twitter: @rybolov
Unable to handle kernel NULL pointer dereference at virtual address
00000000
\|/ ____ \|/
"@'/ .. \`@"
/_| \__/ |_\
\__U_/
Oops, going down hard!
James Urquhart
May 21, 2010, 5:33:55 PM5/21/10
to cloud...@googlegroups.com
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
Yes/No/Not Applicable/Not Understood
Thus, requests that are not recognized by the provider can get a distinct response.
James Urquhart
Ben Sapiro
May 22, 2010, 1:00:42 PM5/22/10
to CloudAudit
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?
> rybo...@ryzhe.ath.cx codey...@yahoo.com
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?
Ben Sapiro
May 22, 2010, 1:09:59 PM5/22/10
to CloudAudit
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
> rybo...@ryzhe.ath.cx codey...@yahoo.com
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
Sam Johnston
May 22, 2010, 1:34:00 PM5/22/10
to cloud...@googlegroups.com
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)
James Urquhart
May 23, 2010, 12:39:42 AM5/23/10
to cloud...@googlegroups.com
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 <sa...@samj.net>
To: cloud...@googlegroups.com
Sent: Sat, May 22, 2010 10:34:00 AM
Subject: Re: I was Thinking and came up with some Evil
Krishna Sankar
May 23, 2010, 1:43:20 AM5/23/10
to cloud...@googlegroups.com
Folks,
Couple of points:
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/>
Couple of points:
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/>
Ben Sapiro
May 23, 2010, 9:37:52 AM5/23/10
to CloudAudit
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:
> Folks,
> Couple of points:
>
> 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/>
>
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:
> Folks,
> Couple of points:
>
> 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
>
>
>
>
> > 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
>
Ben Sapiro
May 23, 2010, 9:44:28 AM5/23/10
to CloudAudit
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>
"I have no clue what you are talking about"
it, we have no answer
"oops, I should have an answer, but the file is now missing"
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
>
> ________________________________
James Urquhart
May 23, 2010, 10:33:55 AM5/23/10
to cloud...@googlegroups.com
Hmm. I kind of feel like that's backwards.
"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
"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
Krishna Sankar
May 23, 2010, 10:55:06 AM5/23/10
to cloud...@googlegroups.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/>
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/>
Reply all
Reply to author
Forward
0 new messages