Ready to Be Hacked: Incident Response
Ready to Be Hacked: Incident Response
A review of the four steps of an incident response plan after a security breach from OWASP.
Join the DZone community and get the full member experience.
Join For FreeSecure and manage your open source software with Flexera.
As any security professional knows, the threat landscape is a moving target. Right now, hackers seem to be choosing web applications as a favored way into enterprise information systems— Verizon
reports that they represent 40% of all confirmed breaches, the most significant attack vector in 2015.
The IT world looks very different than it did just ten years ago — access to your enterprise system no longer comes only from inside your trust boundaries. With the rising popularity of cloud solution and mobile computing, there are more access points then ever. Add to this new focus on web applications (up from less than 10% in 2014), and your system is at greater risk than ever before.
The time to think about being hacked is before the hackers find their way into your system. The Open Web Application Security Project (OWASP) developed a comprehensive incident response plan to enable organizations to be proactive and be able to respond quickly and effectively when a system is breached.
There are four key steps to take before you are hacked (for the first or next time):
1. Audit and Due Diligence
You must first know what you are dealing with. That includes auditing your system to identify current assets (such as equipment and applications) and prioritizing them to understand your most critical information and where it is housed.
2. Response Team
Next, it is critical to create a team of experts from across the organization who will leap into action and implement your response plan when there is a breach. This includes making sure there is a team leader who has responsibility to determine if the incident requires a response from the team.
3. Incident Response Plan
This is the heart of your response—a plan that lays out the roles and responsibilities of team members, sets in advance the process the team will use to investigate, mitigate, and recover from the incident.
4. Identify Triggers and Indicators
This is a critical adjunct to planning the process—documentation of how your organization identifies and categorizes incidents, and what factors will trigger the incident response plan.
It isn’t possible to protect against all risks, but there are steps to take to secure your system as much as possible and prepare to deal with the situation when the risk turns into reality for your organization. Implementing an incident response plan starting with these four critical elements will ensure that your organization is ready to recover in the event of a breach.
This response plan is only one element of a complete security posture. To truly reduce risk, you should take advantage of runtime application self-protection (RASP) technology to protect your organization and its assets. This comes the closest to any technique out there to being complete protection for your web applications.
Learn more about the OWASP incident response plan and RASP fits into a comprehensive security plan. Download the report You’ve Been Hacked: Why Web Application Security Programs Should Start with RASP.
Security vulnerabilities put your data and your customer’s data at risk. Find out how FlexNet Code Insight integrates into your SDLC and makes monitoring open source security a breeze, so you can worry less and build more. Brought to you in partnership with Flexera.
Like This Article? Read More From DZone
Published at DZone with permission of Richard April , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}