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

Colin Watson colin.watson at owasp.org
Mon Mar 14 16:57:04 EDT 2011


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
>
>
> ================
>


More information about the Owasp-appsensor-project mailing list