[Owasp-appsensor-project] Response Actions

Colin Watson colin.watson at owasp.org
Wed Aug 18 10:36:49 EDT 2010


John

Thanks very much for your thoughts.  I've put together a summary sheet
with all the things you mentioned - well it's more than one page and
includes most of my thinking to date.  I think the file is too large
to send to this list so have added it as a PDF to the site for now:

http://www.owasp.org/index.php/File:Owasp-appsensor-responses.pdf

It is draft, and needs further thought and input.

I have renamed "Security Violation Message" to the more generic "User
Notification" similar to "Administrator Notification".  Also, I
disliked my own idea of including things like sending to SIEM as part
of "Administrator Notification", and have suggested "Other
Notification" for those types of things.

I also changed "User Characterisation Updated" to "User Status
Change".  Table 2 (Examples) hopefully explains better.

Once this document is more final, I can probably produce a wiki page,
breaking it down into more pages.

Regards

Colin

On 16 August 2010 03:01, John Melton <jtmelton at gmail.com> wrote:
> Colin,
> I like the idea of a nice write-up for all of these (nice work already).  I
> would also like to propose somewhere in your write-up to have a quick
> reference table for all the response actions, so I can just get a quick list
> of them, even though there may be more detail below.  I would think this
> table might also include columns for the different attributes (like
> time-dependent, silent, etc that you put in your email) with a simple check
> or something if it applies to that response action (this was just my first
> thought of how to do it, really just thinking about a 1 page printable
> "quick-view").  I also like your recommendation of a useful reference code
> collection, but I haven't come up with anything useful for a naming
> convention.
>
> Thanks,
> John
>
> On Fri, Aug 13, 2010 at 6:42 AM, Colin Watson <colin.watson at owasp.org>
> wrote:
>>
>> Hi
>>
>> The AppSensor v1.1 lists four response actions:
>>
>> * Security Violation Message
>> * Account Logout
>> * Account Lockout
>> * Administrator Notification
>>
>> but other actions are also mentioned:
>>
>> * Function Disabled (e.g disable add friend feature, prevent new site
>> registrations)
>>
>> I suppose "Administrator Notification" might be be broadened to
>> include messaging other systems (e.g. SIEM), although the example
>> "con" is "used too often".
>>
>> Also, some extra ideas can be found in recent presentations and emails
>> to the list:
>>
>> 1)  Logging Increased (e.g. capture request headers and full responses)
>>
>> 2) Terminate Process (e.g. ask user to begin business process again
>> from start) - a softer version of account logout
>>
>> 3) Time Delays Introduced/Increased (e.g. extend response time for
>> each failed authentication attempt, add delays into every response)
>>
>> 4) Function Amended (e.g. reduce payment transfer limit before
>> additional out-of-band verification is required, limit on feature
>> usage rate imposed, additional registration validation steps,
>> additional anti-automation measures, static rather than dynamic
>> content returned)
>>
>> 5) User Characterisation Updated (e.g. internal trustworthiness
>> scoring changed) ???? not sure about this - but could be used to
>> "flag" an account as at risk, so if the telephone helpdesk receive a
>> lost password enquiry, they might amend their behaviour there ?????
>>
>> 6) Application Disabled (e.g. website shut down and replaced with
>> temporary static page, one user's IP address range blocked)
>>
>> Some of the above might be applied to just the current User or
>> system-wide affecting all Users.  Some of the responses are time
>> independent (e.g. alert to administrator), some might have a time
>> period associated with them (e.g. temporary account lock-out) and some
>> might be considered relatively permanent from the app's point of view
>> (e.g. permanent lock-out, application disabled).
>>
>> Some may be "silent" actions in that the user is unaware of them, and
>> in others the user may be informed.
>>
>> I was thinking of writing this up in more detail and any suggestions
>> or comments would be welcome.  For example, would it be useful to have
>> reference codes for each type of response so we can log what action
>> was taken?  If so, what naming convention?
>>
>> Regards
>>
>> Colin
>> _______________________________________________
>> Owasp-appsensor-project mailing list
>> Owasp-appsensor-project at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-appsensor-project
>
>


More information about the Owasp-appsensor-project mailing list