This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "OWASP Incident Response Project"

From OWASP
Jump to: navigation, search
m (In Print)
(Related Projects)
 
(34 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
=Main=
 
=Main=
 +
{{#widget:PayPal Donation
 +
|target=_blank
 +
|budget=OWASP_Incident_Response_Project
 +
}} 
 +
  
 
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>
 
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>
  
 
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
 
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
+
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
  
==OWASP Incident Response Project==
+
==OWASP Top 10 Guidance for Incident Response==
  
==Description==
+
==Audience==
  
This project is to provide fundamental guidance to organizations in building there own incident response program to respond to a incident.
+
Breaches happen every day as you learn about them in the news. Is your business prepared? This project provides a proactive approach to Incident Response planning. The intended audience of this document includes business owners to security engineers, developers, audit, program managers, law enforcement & legal council. This guidance should be considered when building a comprehensive approach. This guidance intends to guide the reader on topics that need to be part of the plan in your organization, this includes those responsible for managing the business and technical risk of the entire organization.
  
 
==Licensing==
 
==Licensing==
The OWASP Incident Response Project is free to use. It is licensed under the http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike 3.0 license], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.
 
  
 +
Creative Commons Attribution-NonCommercial-ShareAlike
 +
==Project Sponsor==
 +
OWASP Top 10 Guidance for Incident Response project is sponsored by [http://www.proactiverisk.com ProactiveRISK Inc.].
  
| valign="top"  style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |
+
[[File:Proactiverisk_logo_v2.jpg | link=http://www.proactiverisk.com]]
  
== What is the OWASP Incident Response Project? ==
+
| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |
  
The OWASP Incident Response Project provides:
+
== In Print ==
  
Fundamental principals for a incident response program
+
[https://www.owasp.org/images/9/92/Top10ConsiderationsForIncidentResponse.pdf Version 1.0 .PDF Version]
  
 
== Presentation ==
 
== Presentation ==
  
coming soon...
+
[https://www.owasp.org/images/b/bd/IR_Top_10_Considerations_-_Slides-v2.pdf Slides]
  
 
== Project Leader ==
 
== Project Leader ==
  
[https://www.owasp.org/index.php/User:Brennan Tom Brennan] @brennantom
+
[https://www.owasp.org/index.php/User:Brennan Tom Brennan] [http://www.twitter.com/brennantom @brennantom]
 +
 
 +
== Version 2.0 ==
 +
Want to help out and make this project BETTER?  Add your comments here
 +
[https://docs.google.com/document/d/1TbIwFW_Z1d7jhnQL9vkdBzFtRC1lmHp9JpTXYXyN58A/edit?usp=sharing Version 2.0 GoogleDocs - Add Comments]
  
 
== Related Projects ==
 
== Related Projects ==
 +
 +
[https://www.owasp.org/index.php/OWASP_Anti-Ransomware_Guide_Project OWASP Randsomware]
  
 
[https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project OWASP Top 10]
 
[https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project OWASP Top 10]
Line 42: Line 55:
 
[https://www.owasp.org/index.php/OWASP_WASC_Web_Hacking_Incidents_Database_Project Web Hacking Incident Database]
 
[https://www.owasp.org/index.php/OWASP_WASC_Web_Hacking_Incidents_Database_Project Web Hacking Incident Database]
  
 
+
| valign="top" style="padding-left:25px;width:200px;" |
 
 
| valign="top" style="padding-left:25px;width:200px;" |
 
 
 
  
 
== News and Events ==
 
== News and Events ==
* Release date 12/7/2015 NYC Chapter Meeting
+
* Release date 12/7/2015
 
+
* 01/13/2018 NYC Chapter Meeting V2.0
== In Print ==
 
  
 
==Classifications==
 
==Classifications==
Line 56: Line 65:
 
   {| width="200" cellpadding="2"
 
   {| width="200" cellpadding="2"
 
   |-
 
   |-
   | align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
+
   | rowspan="2" align="center" valign="top" width="50%" | [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
  | align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]] 
 
 
   |-
 
   |-
   | align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
+
   | align="center" valign="top" width="50%" | [[File:Owasp-defenders-small.png|link=]]
 
   |-
 
   |-
   | colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
+
   | colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
 
   |-
 
   |-
   | colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
+
   | colspan="2" align="center" | [[File:Project_Type_Files_DOC.jpg|link=]]
 
   |}
 
   |}
  
 
|}
 
|}
 
1.    Introduction
 
A Security incident is an identified occurrence or weakness indicating a possible breach of security policies or failure of safeguards, or a previously unknown situation which may be security relevant.[1]
 
Organizations are susceptible to different types of attacks which might be  simple or sophisticated in nature and attack vectors such as attempted hacks, viruses, and trojans keep evolving at a pace that calls for constant vigilance. Incidents have the potential to affect the confidentiality, integrity and availability of information or services provided by an organization.
 
 
Incident Response is the reaction to an identified occurrence whereby responders classify an incident, investigate and contain the incident . Incident Documentation is also a part of this procedure which should be conducted in an efficient and timely fashion. More often than not, many companies fail to appreciate how much they stand to lose when they do not have the people, processes and tools that are required for Incident Recovery procedures. Statistics reveal that security incidents now occur on a regular basis and cause substantial business interruption when it is not well handled. 
 
 
Why is Incident Response Important?
 
The answer is straightforward.  Any challenge or problem which is not properly contained and handled can and will spiral into bigger problems that can eventually lead to the total collapse of the system.
 
Incidents will occur even in environments that are adequately prepared for it.
 
A competent Incident Response operation will help to
 
Minimize loss.
 
Mitigate the weaknesses that were exploited.
 
Restore services and processes.
 
Reduce the risk that can occur from future incidents.
 
 
 
One of the biggest questions that must be answered by companies or Incident Response Managers  is:
 
“Where do we start from?”
 
 
Our advice is that you do a comprehensive audit or review of your constituency in order to have a very good picture of where the organization stands.
 
 
2. Consideration 1. Audit and Due Diligence.
 
Performing an audit will let you know how well prepared the organization is for Incident Response in terms of:
 
·  People. Is there a formal Incident Response team? if yes , do the team members have adequate technical skills for the designated roles or tasks ?
 
·  Process. When an incident occurs do the team members know what to do, when to do it and how to do it?
 
·  Equipment and Materials.  Has the organization identified the equipment, materials or information mission critical to the business? Where are such equipment or materials stored? What are the interactions between business processes, supportive systems and external suppliers? Are these interactions monitored and documented ? etc. All these questions and more will be answered when an audit is performed.
 
Remember due diligence will expose the problems an organization can face in  implementing an effective Incident Response Plan.
 
 
 
3. Consideration 2. Create a Response Team.
 
In an era where business and business interactions are conducted at a very swift and extraordinary pace, it is amazing to note that only a few organizations totally comprehend how ready they are to react to incidents that affect their organization.
 
Preventing and managing attacks or incidents that can occur without prior notice is best managed by experts that belong to an Incident Response team. Organizations or enterprises without an Incident Response team should know that it is essential to create an Incident Response team whose objective is to set priorities for managing, responding to and recovering from incidents.
 
An Incident Response team should consist of people with sufficient technical skills.  It is important that the team members consist of SME's (Subject Matter Experts) or Knowledge Engineers from different domains across the organization.
 
The following roles are important to any IR team:
 
·        Team Lead. The responsibility of the Team Led is to coordinate the efforts of the team and ensure that assigned tasks are executed in an efficient manner.
 
·        Triage Officer. The Triage Officer deals with incidents that are reported to or by the team. The resource person occupying this position will  need to decide whether it is an incident that is to be handled by the team, when to handle it and who is going to be the incident handler according to laid down procedures.
 
·    Incident handler. The incident handler role is important. The handler deals with the incident  analyzing information, proposing solutions, resolving incidents and communicating progresses or challenges faced.
 
 
 
You might also consider Vendors and Third party Service Providers whose activities are relevant to Incident Management. They should help you to respond to incidents in a faster, more effective manner.
 
Other members of the team can be a Public Relations Officer, Legal Adviser and a  Risk Assessment officer.
 
In summary there are some important things to note when creating an Incident Response Team.
 
Ensure that you have a competent Team Leader who is in charge and has a clear chain of command.    Document the roles and responsibilities of the team members and communicate this clearly to all relevant stakeholders. This will ensure that the work flows smoothly along clearly established reporting lines.
 
Team members should have sufficient authority to respond to task and challenges within their jurisdiction. They should also be encouraged to work actively with other internal and external team members as the overall objective is to respond efficiently to incidents that affect the organization as a whole.
 
Remember, the major task of the Incident Response team is to classify an incident , investigate and contain the incident and also ensure proper documentation where applicable. A team is only as strong as it’s weakest link. Ensure that all team members realize how important their roles are and review performances and contributions accordingly. Ideally you should have backups for these roles when the team members are unavailable.
 
 
 
 
4. Consideration 3. Create a Documented Incident Response Plan.
 
An organization should have a well-documented Incident Response plan that would guide the Incident Response Team during an incident.  There are many sample documents available which can help you in this exercise. Any plan drawn up for the team and firm must be practicable and in accordance with best practice. A good starting point is to start off with standards such as the ISO/IEC 27000 series.
 
However, in a bid to follow best practice , do not draft a plan that will not be feasible for your team and organization . You can ask an auditor, a third party expert or  an ISO 27001 certification body, to confirm that your incident response plan is at par  with your standard practices.
 
A comprehensive plan at minimum , should cover Roles and Responsibilities, Investigation, Triage and Mitigation, Recovery, and Documentation process.
 
These steps  should be actionable by members of the Incident Response Team. Executives should be familiar with the plan and equipped with appropriate procedures for handling outside inquiries.
 
 
 
5. Consideration 4. Identify your Indicators and Triggers.
 
What would be categorized as an incident at your organization? How important or weighty are the factors that would trigger an incident?  It is not every event that occurs that will trigger an incident or an incident response. This implies that you need to clearly define what can trigger an incident. Some of these events include:
 
Loss or theft of Equipment.
 
Loss or theft of information.
 
Unauthorized software or hardware installation.
 
Unauthorized information transmission within the organization or to an external party.
 
Attempts to gain unauthorized access to data, computer or information storage device.
 
Unauthorized clearance of sensitive data or information.
 
Attempts to compromise or breach defined security networks within the organization
 
A member of your organization reports of suspicious activity such as clicking on a phishing link.
 
A Web server’s log entries that that indicates the use of a vulnerability scanner.
 
A host’s audit log indicating a suspicious change in its configuration. Just to mention a few
 
These triggers or indicators should be documented. It is advisable that it also goes into your documented Incident Response Plan (see the previous section for more details) and  known to the all members of your organizations .  This may require some training or a comprehensive awareness campaign as the information should not be limited to the Incident Response team.
 
 
6. Consideration 5.Investigate the Problem
 
When an event occurs, an Incident Response Team is required to categorize the event and  identify whether or not you have an incident.  The review will determine if it is a valid potential incident or not.
 
A thorough investigation will require input from the Incident Response Team and might require input from external resources (see Incident Response Team members above).
 
In investigation, the necessary course of action will depend on the cause of the incident and plan according to the Incident Response  documentation. Note that some incidents can be fixed swiftly while some may take a while to resolve.
 
In any scenario, communication within and without the team is very important and all stakeholders should be briefed accordingly. The investigation will document the incident details, including what to look for, who to involve, and how to document what is found.
 
Some other activities that can be carried out are listed below.
 
Establishing , clearly what has occurred.(Is it a  malware attack, system hack, session hijack, Denial of Service  etc)
 
Identify what systems, people or processes have been compromised or affected based on incident.
 
Determine what happened to what was compromised.
 
Determine the point of origin of the incident where possible .This infers that you establish the source of the threat or attack vector.
 
Specifying your investigation objectives, triage and resolution methodology.
 
Gathering , reviewing and detailed analysis of all information concerning  the incident,
 
Adequate checks on equipment for malfunctions and vulnerability  that may have led to the incident.
 
What information (if any) has been disclosed to unauthorized parties, deleted or corrupted.
 
Identifying the potential business impact of the  incident: i.e. Business Interruption , Financial Loss.
 
Other investigative procedures to be carried out like Forensics , Prosecution etc
 
 
For example , if the Incident has to do with a compromised equipment within a network, it will be advisable to determine which equipment was compromised, if the compromise came from an external or internal source. If it is determined that the incident merits probable legal action, preserving the evidence in its original form will be a crucial requirement. The Legal Counsel will recommend proper steps for documenting the evidence and collaborate with Law enforcement agencies where necessary.
 
 
 
7. Consideration 6. Triage and Mitigation.
 
Investigation naturally leads to the triage and resolution process.  As the team identifies potential exposure, they should plan and execute effective mitigation accordingly.  For various incidents, the plan should include the incident type and necessary steps for mitigation.
 
Some mitigation steps and actions have been listed in the previous section (see Investigation above).
 
For some incidents, the response may require more complicated and coordinated actions to remove the attack vectors or attackers from your environment. Some organizations may not have the expertise or experience to execute and  document all steps and would require external input. The details for vendors who may need to respond, such as an ISP during a Denial of Service attack, or a forensics firm to mitigate a Complex Advanced Persistent threat should be included in the Incident Report.
 
In summary , the triage process should cater for the following activities:
 
Classification of the Incident.
 
Incident Prioritization.
 
Assigning specific tasks to specific people.
 
Note that the initial part  of an investigation is sometimes referred to as Triage.
 
 
 
8. Consideration 7. Recovery.
 
Once a thorough investigation has been carried out, recovery is a significant step for restoring whatever services or materials might have been affected during an incident. This could be the task of the technical people in the team. The recovery step is the transition from active incident to standard monitoring.  The recovery procedure should include the steps for transition given the specifics of the firm’s environment and approach.
 
It is important that after an incident has been contained, key components that contributed to the incident should be eliminated. For example, when returning a compromised machine to production, is it acceptable to clean infection residue or should the machine in question be wiped cleaned, formatted and rebuilt from known reliable media?
 
Other practical recovery responses can include:
 
·        Conducting a malware scrutiny.
 
·        Allowing sufficient time to elapse to prove that a compromised network is now secure.
 
·        Removing temporary constraints placed during the investigation period.
 
·        Confirming the integrity of business systems and controls.
 
·        Replacing compromised records with reliable versions
 
·        Resetting passwords on compromised accounts.
 
·        Installing updates and patches.
 
            ·        Install or replace equipment that are susceptible to exploits.
 
The overall objective of the recovery process in Incident Response is to reinstate systems to normalcy , affirm  that the systems are functioning normally, and repudiate  all known vulnerabilities to prevent similar incidents from reoccurring.
 
 
 
9. Consideration 8. Documentation and Reporting.
 
Reporting an incident is more than sending an email or other notification to team members or relevant stakeholders. A comprehensive incident report is required in keeping with best practices and with the Incident Response plan. The type of reports that might be required might vary but should help in managing and reviewing incidents satisfactorily.
 
Reporting and documentation is a critical action that will always occur before, during and after Incident Response. Some key actions, events and processes that would require documentation has been highlighted in previous sections of this document. Emphasis should be  laid on the following  questions when documenting Incident Response Report.
 
·        The date, time and actual location of the incident.
 
·        Who discovered and reported the incident.
 
·        Systems, materials , processes  or Information affected.
 
·        Stakeholders involved in the incident.
 
·        Comprehensive description of what transpired.
 
·        Who has been informed about the incident and action steps taken.
 
Some other points to consider in reporting and documentation is briefing the management about the incident in a timely fashion. Management should be notified immediately when an important incident is detected.  Briefing is a critical action in reporting as it  provides the management an overview of the  situation  which can  help define the obligatory course of action.
 
As more information becomes available throughout the response process, additional briefings and updates should occur at regular intervals.
 
 
Sharing Information with internal and  external stakeholders.
 
Sometimes, there is a considerable amount of information generated from incidents that occur within an organization and  you can share information with external vendors or  trusted service providers in a bid to educate them and also receive helpful information from them when the need arises.
 
Note that sharing information should be on a ‘need to know’ basis and it is advisable for organizations to involve the Legal Counsel expert when creating reports so that factors such as regulatory obligations, contractual obligations, and insurance obligations are properly considered as an incident investigation proceeds.  All team members should be trained in a common lexicon of language to guarantee prompt and clear communication during incident response.
 
 
10. Consideration 9. Process Review.
 
It is imperative to continuously monitor an incident and  the workload/performance of the team or Incident Handler. When you review an incident comprehensively you can make intelligent decisions about the factors listed below.
 
·        Should I increase or decrease the number of Incident Handlers?
 
·        Do we need to develop automated procedures for Incident Handling?
 
.    What risks did we identify during the incident that needs to be followed up for action and monitored closely ?
 
Other activities that should also be considered during a process review is keeping a Lessons Learnt log.
 
The lessons can be positive or negative in nature but they should be current and relevant and ensure the maturity of your team over time. You might want to keep versions of the log so that you can keep track of its development and know which previous lessons learned were either integrated successfully and which needs to be revisited.
 
 
11. Consideration 10. Practice , Practice , Practice.
 
Do not wait until an incident occurs before you put your team to work. Once the organization has a workable plan in place, it is advisable to run through part or all of it as a tabletop exercise. Assemble the various stakeholders and talk through different scenarios and how the group would react. Document the results of these exercises and incorporate the findings into your plan.
 
When new resource persons join your  Incident Response team, it is important that  they understand how important these mock drills and practice are to the firm.  Sometimes you can practice the organization’s plan by simulating a live scenario.
 
This test can be as simple as dropping a thumb drive on the floor of the office and seeing what happens, to simulating a data breach or phishing attack.
 
Your objective is not to intimidate the team members or peers but to determine if your plan works or not before the real event occurs. Drills and practices also reveal where lapses are and they can be resolved before real life scenarios happen.
 
 
 
12. Conclusion
 
An incident is considered to be any adverse event that threatens the progress,  integrity or  availability of your organization’s objectives or  resources. Encourage your Incident Response Team to  take  part in external events, such as by attending conferences, enrolling in training  and other helpful activities.
 
Incident Response cuts across the whole organization and should not just be restricted to the IT unit or particular units.
 
It should be clearly communicated that an organization’s fundamental business or service delivery can be endangered when incidents occur. It is the mandate of an efficient Incident Response Team to  prevent , handle, resolve and adequately document incidents that may arise.
 
Incident Recovery  is a significant tool of overall governance and to have it, in whatever form or shape, is a necessity. This fact is acknowledged and supported in the ISO 27001 security standards and in frameworks such as ITIL and COBIT.
 
 
 
 
References.
 
 
1.      An empirical study on the use of the Generic Security Template for structuring the lessons from information security incidents. 2014. By Ying He, Chris Johnson,Karen Renaud ,Yu Lu and Salem Jebriel. School of Computing Science University of Glasgow,Glasgow, UK   
 
URL:http://www.researchgate.net/profile/Ying_He14/publication/262300500_An_empirical_study_on_the_use_of_the_Generic_Security_Template_for_structuring_the_lessons_from_information_security_incidents/links/5433e19c0cf2dc341dae01aa.pdf
 
 
2.      Top Considerations for Incident Response by Legal Sec 
 
URL: http://www.proactiverisk.com/wp-content/uploads/2015/06/IR-Guidance.pdf
 
 
3.      Information Security Incident Reporting Policy by Herefordshire Council , 2013
 
 
4,      Good Practice Guide for Incident Management by ENISA , 2010. 
 
URL:https://www.enisa.europa.eu/activities/cert/support/incident-management/files/good-practice-guide-for-incident-management
 
 
5.    Local Government Cyber Security :Cyber Incident Response Guide,A Non-Technical Guide Essential for Elected Officials ,Administrative Officials  and Business Managers  by MS-ISAC
 
URL:http://msisac.cisecurity.org/members/local-government/documents/finalincidentresponseguide.pdf
 
  
 
= Acknowledgements =
 
= Acknowledgements =
Line 242: Line 80:
 
Incident Response Project is developed by a worldwide team of volunteers. The primary contributors to date have been:
 
Incident Response Project is developed by a worldwide team of volunteers. The primary contributors to date have been:
  
* [https://www.owasp.org/index.php/User:Brennan Tom Brennan], ProactiveRISK
+
* [https://www.owasp.org/index.php/User:Brennan Tom Brennan], [http://www.proactiverisk.com ProactiveRISK]
* <insert your name>
+
* Jason Jolo, [http://www.proactiverisk.com ProactiveRISK]
* <insert your name>
+
* Jordan Lewis
 
* <insert your name>
 
* <insert your name>
 
* <insert your name>
 
* <insert your name>
Line 257: Line 95:
 
You do not have to be a security expert in order to contribute.
 
You do not have to be a security expert in order to contribute.
 
Some of the ways you can help:
 
Some of the ways you can help:
 +
 
* Proof Reading
 
* Proof Reading
 
* Graphic Design
 
* Graphic Design
 
* Conduct Industry Survey
 
* Conduct Industry Survey
 +
* Educate local communities
 +
*  list of open-source IR tools
 
* <insert your idea>
 
* <insert your idea>
  
Line 265: Line 106:
 
{{:Projects/OWASP_Incident_Response_Project}}   
 
{{:Projects/OWASP_Incident_Response_Project}}   
  
__NOTOC__ <headertabs />  
+
__NOTOC__ <headertabs></headertabs>  
  
[[Category:OWASP Project]]  [[Category:OWASP_Builders]] [[Category:OWASP_Defenders]]  [[Category:OWASP_Document]]
+
[[Category:OWASP Project]]   
 +
[[Category:OWASP_Builders]]  
 +
[[Category:OWASP_Defenders]]   
 +
[[Category:OWASP_Document]]

Latest revision as of 01:54, 23 January 2018


OWASP Project Header.jpg

OWASP Top 10 Guidance for Incident Response

Audience

Breaches happen every day as you learn about them in the news. Is your business prepared? This project provides a proactive approach to Incident Response planning. The intended audience of this document includes business owners to security engineers, developers, audit, program managers, law enforcement & legal council. This guidance should be considered when building a comprehensive approach. This guidance intends to guide the reader on topics that need to be part of the plan in your organization, this includes those responsible for managing the business and technical risk of the entire organization.

Licensing

Creative Commons Attribution-NonCommercial-ShareAlike

Project Sponsor

OWASP Top 10 Guidance for Incident Response project is sponsored by ProactiveRISK Inc..

Proactiverisk logo v2.jpg

In Print

Version 1.0 .PDF Version

Presentation

Slides

Project Leader

Tom Brennan @brennantom

Version 2.0

Want to help out and make this project BETTER? Add your comments here Version 2.0 GoogleDocs - Add Comments

Related Projects

OWASP Randsomware

OWASP Top 10

OWASP Cheat Sheets

OWASP Mod_Security CRS

Web Hacking Incident Database

News and Events

  • Release date 12/7/2015
  • 01/13/2018 NYC Chapter Meeting V2.0

Classifications

Owasp-incubator-trans-85.png
Owasp-defenders-small.png
Cc-button-y-sa-small.png
Project Type Files DOC.jpg

Volunteers

Incident Response Project is developed by a worldwide team of volunteers. The primary contributors to date have been:

Want to help? Get in touch with us

Others

  • OWASP NYC Metro Chapter

Involvement in the development and promotion of OWASP Incident Response Project is actively encouraged! You do not have to be a security expert in order to contribute. Some of the ways you can help:

  • Proof Reading
  • Graphic Design
  • Conduct Industry Survey
  • Educate local communities
  • list of open-source IR tools
  • <insert your idea>
PROJECT INFO
What does this OWASP project offer you?
RELEASE(S) INFO
What releases are available for this project?
what is this project?
Name: OWASP Incident Response Project (home page)
Purpose: OWASP Incident Response Project will provide users with a current set of tools and best practices for dealing with a hacked web application.
License: Creative Commons Attribution ShareAlike 3.0 License (best for documentation projects)
who is working on this project?
Project Leader(s):
  • Tom Brennan @
how can you learn more?
Project Pamphlet: Not Yet Created
Project Presentation:
Mailing list: Mailing List Archives
Project Roadmap: View
Key Contacts
  • Contact Tom Brennan @ to contribute to this project
  • Contact Tom Brennan @ to review or sponsor this project
current release
Not Yet Published
last reviewed release
Not Yet Reviewed


other releases