[Owasp-appsensor-project] NIST SP 800-137 Initial Public Draft "IS Continuous Monitoring..."

Dennis Groves dennis.groves at gmail.com
Mon Mar 14 19:28:45 EDT 2011


On Mon, Mar 14, 2011 at 10:40 PM, Dennis Groves <dennis.groves at gmail.com>wrote:

Interesting, because I think of AppSensor as a framework for an Application
> to defend itself against the unknown attacks - when the 'sensors' are feed
> to a statistical anomaly detection system; since this then allows one to
> detect and respond to attacks that are otherwise unanticipated.
>
> I don't think of it as application-layer intrusion detection as this is ISO
> 7942-2 language and is very 'OSI model' type of language.
>
> I personally think the correct idea is along the lines of 'defensive
> application development' which combined with say 'rugged software
> development' and we start to have a 'development defense in depth patterns'
> that rival anything that anybody has yet published - it is about getting the
> word out.
>
> I think it is a good idea to stay away from the marketing terms because
> that will only cloud this beautiful idea in the already negative
> connotations and response the security community and market has already had
> to those terms.
>
> --
> Dennis Groves, MSc
>
>
> On Mon, Mar 14, 2011 at 8:57 PM, Colin Watson <colin.watson at owasp.org>wrote:
>
>> I've had two direct replies saying "yes" so far... but one other thought:
>>
>> I refer to this as "application-layer intrusion detection and
>> response".  I wonder if we should try to differentiate it more from
>> IDPS (intrusion detection and prevention systems).  Perhaps just
>> "application attack detection and response", and weave the phrases
>> "attack aware" and "proactive defense" into the text somewhere?
>>
>> Colin
>>
>>
>>
>> On 14 March 2011 18:30, Colin Watson <colin.watson at owasp.org> wrote:
>> > Hi
>> >
>> > NIST SP 800-137 concerning "Information Security Continuous Monitoring
>> > for Federal Information Systems and Organizations"
>> >
>> >   http://csrc.nist.gov/publications/PubsDrafts.html#800-137
>> >
>> > is inviting comments (until 15th March!).  I read this over the
>> > weekend, and feel it seems to neglect actual real time (referring to
>> > "near real-time" monitoring) and doesn't say very much about
>> > application monitoring at all.  Ordinarily I would do this type of
>> > reply via the Global Industry Committee, but I think the subject is
>> > much more aligned with AppSensor than most other OWASP activities.
>> > Therefore I would like to submit some comments "on behalf of the OWASP
>> > AppSensor project team", and will send the following tomorrow unless I
>> > hear otherwise.  I'm not expecting anyone to read the NIST document,
>> > or parts of it, but would like a sanity check on what I have written.
>> >
>> > Colin
>> >
>> > ================
>> >
>> > Introduction
>> > -----------------
>> >
>> > The following four comments are submitted on behalf of the OWASP
>> > AppSensor project team, following our own consultation process.
>> >
>> > Response
>> > --------------
>> >
>> > a)  Page 10 refers to "real-time or near realtime security-related
>> > information", but elsewhere (e.g. pages 1, 2, 6, 7, 13, 14, 29, etc)
>> > the phrase "near real-time" is used instead.  The guidance should
>> > explicity include actual realtime monitoring at each reference to
>> > "near real-time", so that it is not excluded from the guidance.
>> >
>> > b)  In "3.2 Role of Automation in Continuous Monitoring", human
>> > analysis will not necessarily be required for the interpretation of
>> > findings in application-layer intrusion detection and response,
>> > because the actions are undertaken in real-time within the timeframe
>> > of the user request and software response.  Human analysis will have
>> > been required to assess, define and implement the policies in advance
>> > instead.  Thus in some situations the steps shown in Figure 3-1 on
>> > page 20 (Continuous Monitoring Process) may be one less, when
>> > "Analyse/Report" and "Respond" are collapsed into a single item.  This
>> > concept also relies on some overlap between the illustrative tiers in
>> > Figure 2-1 on page 8 (Organization-wide Continuous Monitoring) i.e.
>> > the software application combines information from Tier 3 (information
>> > systems) and Tier 2 (mission/business) giving a very low false
>> > positive attack detection rate.
>> >
>> > c) The list and descriptions of the eleven security automation domains
>> > In Appendix D (pages D-2 and D-3) does not seem to adequately cover,
>> > or allow for, application-layer intrusion detection and response.
>> > Neither "Event & Incident Management" (section D.1.2) nor "Network
>> > Management" (section D.1.6) describe what is possible when building
>> > intrusion detection & response into the software code itself.  In this
>> > there is full knowledge of the business logic, user session, user
>> > role, user permissions, input data formats, etc, and proactive
>> > defensive measures can be undertaken in real-time.  It is vastly
>> > different to the IDPS described (in D.1.2).  We therefore propose a
>> > twelfth domain of "Application Management".
>> >
>> > **** OWASP can provide suggested draft text for this proposed domain
>> > if required, linking the reduction in operational risk to the security
>> > controls in NIST SP 800-53 ****
>> >
>> > d) In D.3 Automation and Data Sources", the bulleted list of "examples
>> > of security automation activities" (page D-11), we would suggest
>> > adding a fifth item "Building in application-layer intrusion detection
>> > and response" since it is a relatively new concept, may not be
>> > considered due to lack of awareness and thus the potential benefits
>> > left unexploited.
>> >
>> > About the OWASP AppSensor project
>> > ---------------------------------------------------------
>> >
>> > This response is submitted on behalf of the OWASP AppSensor project
>> > team.  The AppSensor project defines a conceptual framework,
>> > methodology and example code that offers prescriptive guidance to
>> > implement intrusion detection and automated response into software
>> > applications. The concept has been piloted and is in use defending
>> > real-world applications.
>> >
>> > Further information:
>> > · AppSensor project
>> >  http://www.owasp.org/index.php/OWASP_AppSensor_Project
>> > · Detection points
>> >  http://www.owasp.org/index.php/AppSensor_DetectionPoints
>> > · Response actions
>> >  http://www.owasp.org/index.php/AppSensor_ResponseActions
>> >
>> > About OWASP
>> > ---------------------
>> >
>> > The Open Web Application Security Project (OWASP) is a worldwide free
>> > and open community focused on improving the security of application
>> > software. Our mission is to make application security "visible," so
>> > that people and organizations can make informed decisions about
>> > application security risks. Everyone is free to participate in OWASP
>> > and all of our materials are available under a free and open software
>> > license. The OWASP Foundation is a U.S. recognized 501(c)(3)
>> > not-for-profit
>> > charitable organization, that ensures the ongoing availability and
>> > support for our work
>> > at OWASP.
>> >
>> > Further information:
>> > · OWASP Foundation
>> >  http://www.owasp.org/index.php/OWASP_Foundation
>> > · About The Open Web Application Security Project
>> >  http://www.owasp.org/index.php/About_OWASP
>> >
>> >
>> > ================
>> >
>> _______________________________________________
>> Owasp-appsensor-project mailing list
>> Owasp-appsensor-project at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-appsensor-project
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-appsensor-project/attachments/20110314/9bde3406/attachment-0001.html 


More information about the Owasp-appsensor-project mailing list