Download Responding to Intrusions

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Wireless security wikipedia , lookup

Cyberwarfare wikipedia , lookup

Distributed firewall wikipedia , lookup

Cross-site scripting wikipedia , lookup

Computer and network surveillance wikipedia , lookup

Hacker wikipedia , lookup

Mobile security wikipedia , lookup

Operation Payback wikipedia , lookup

Computer security wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

Cyberterrorism wikipedia , lookup

Cyberattack wikipedia , lookup

Cybercrime countermeasures wikipedia , lookup

Transcript
Stephen Gosner
COSC 356 001
Term Paper
Responding to Intrusions
This purpose of this paper is to give you a brief understanding of network
intrusions. More specifically, this paper will explain what a compromised system
actually is, some different forms of attacks, and how a team should respond to an
intrusion. Network intrusions can be very viscous and every action that is taken during
before, and after the attack can have great effects on the outcome.
When a hacker, or a team of hackers gains access to an unauthorized system, a
weak link in the systems security has been exploited. More specifically, the definition of
a compromised system is a system that has had its defenses penetrated by a hacker
through some form of vulnerability being exploited. In this case, the hacker usually
assumes some form of control over the target system. Therefore, systems end up being
compromised when hackers find these vulnerabilities. Vulnerabilities come in many
different forms, which is why it’s so difficult to fully harden any system. Null or default
passwords, default shared keys, an underlying protocol utilized by a service hosted on
the system, operation system bugs, and application bugs are just a few common
vulnerabilities. As stated before, vulnerabilities come in many different forms and most
of the time they are exploited because of human error on the administrator’s end of the
spectrum. Hackers are so incredibly difficult to defend against in such an evolving
technologically advanced industry these days because of the large array of attack
methods.
Some common forms of attacks that are used frequently include but are not
limited to eavesdropping, identity spoofing, sniffer attacks, password-based attacks, and
brute force attacks. In detail, eavesdropping is the collecting of data that passes
between two active nodes on a network. Identity spoofing, aka IP address spoofing,
occurs when an attacker assumes the source IP address of IP packets to make it
appear as though the packet originated from a valid IP address. A sniffer attack occurs
when attackers capture and analyze network traffic. A more simplistic approach are
password-based attacks that are aimed at guessing the password for a system until the
correct password is determined. Brute force attacks are similar in respect via attempts
to decode a cipher by attempting each possible key to find the correct one. Man-in-themiddle attacks and Denial-of-service attacks are more complex on the other hand. A
man-in-the-middle attack occurs when a hacker eavesdrops on a secure communication
session and monitors, captures and controls the data being sent between the two
parties communicating. A system that encounters a denial-of-service attack can be a
more serious situation. Otherwise known as a DoS attack, these attacks are aimed at
preventing authorized, legitimate users from accessing services on the network. A
DDoS (distributed denial-of-service) attack is much harder to deflect because there is
no single attacker to defend from, where the targeted resource will be flooded with
requests from hundreds to thousands of multiple sources. As previously stated, these
are a few of the more common types of attacks. There are many more, and new forms
of attacks appear as defenses fight the others. So what happens if indeed your network
has been attacked?
Once an intrusion has been detected, time is of the essence. It is imperative that
every organization has an Incident Response Plan (IRP) in place at all times. The IRP
requires a team of in-house experts, otherwise known as a Computer Emergency
Response Team (CERT). Requirements of the IRP include a legally reviewed and
approved strategy, financial support from the company, a feasible tested action plan,
and physical resources such as redundant storage, standby systems, and backup
services. The first step once an intrusion is detected, is to immediately notify your
CERT team. It is the responsibility of the CERT team to respond to the problem quickly
and efficiently. The CERT team needs to neutralize the attack in order to prevent any
further damages from occurring. The team will use many strategies to accomplish their
tasks. Commonly, the CERT team will disable the network connections, disconnect the
affected systems, create and apply access control lists on firewalls and routers, and
patch the exploit. Some other strategies include watching the perpetrators to track their
actions, and even redirecting the perpetrator to a honeypot. A honeypot is a system or
segment of a network containing false data used to track incursion safely without
disruption to production resources. Once the CERT team has neutralized the attack, the
next step is to investigate the incident.
Investigating a network systems breach is like investigating a crime scene.
Detectives will collect all evidence available to them, note any strange clues, and take
inventory of the loss and damages. Detectives have the ability to apply computer
forensics in order to collect any evidence they’re able to obtain. An analysis of the
computer compromise can either be done as the attack is occurring or after the attack is
over. This is typically done during the attack, while new information is continually added
to the analysis. While it’s unwise to trust any system log files on an exploited system,
there are other forensic utilities to aid in the analysis. As detectives start to collect the
evidence, all information which indicates malicious activities should be recorded. This
includes all files that have been modified, corrupted, or deleted as well as all
unauthorized processes that are running. Other valuable information to be collected
should be application event logs, system event logs, security event logs, and all other
machine specific event logs such as DSN logs, DHCP logs, and File replication logs.
When the system is under attack, you should immediately transfer a copy of your
system logs to a backup system which is not being hacked. Network logs which include
IDS, router, and firewall logs are a good source of information when it comes to
analyzing the extent to an attack. Sniffers can then be used to determine the state of
the Network. Sniffers can provide important information on the different traffic which
accessed a server then enabling you to recreate sessions. This enables you to analyze
the sequence of the events that occurred. Once the attack has been neutralized, and
the investigation has collected information needed, the CERT team needs to now
recover the system.
It’s the responsibility of the CERT team to bring any downed systems or
applications back online. These include authentication servers, database servers, and
any other production resources. Patches can be used in recovering the system, but is
never recommended. The best strategy for re-installing the system is performing a
clean re-installation. By performing a clean re-installation, you ensure that the affected
system is cleansed of any Trojans, backdoors, or malicious processes. This method
also ensures that any data, if restored from a trusted backup source, is cleared of any
malicious modifications. After the system affected has been recovered, the attack
needs to be reviewed and reported.
After the attack has been neutralized, it is important to review the incident. A
post-mortem analysis is typically required. Throughout the course of the attack, the
CERT team should be taking notes as the response is happening. It’s also important to
include every possible detail of the response which will provide very useful while
reviewing the attack. Doing this could provide you with some valuable information on
how to prevent this same attack from reoccurring. While you might not be able to
completely prevent the attack from reoccurring, you should at least be able to alleviate
the risk. And finally, all issues should be reported to organizations such as local and
federal authorities, affected customers, and multi-vendor software vulnerability portals.
An example of this would be the Common Vulnerabilities and Exposures site (CVE).
In conclusion, a network intrusion can be very devastating to an organization.
Company files, personal information, and other sensitive data can be lost. It’s
impossible to fully prevent a network intrusion. “If there is a will, there is away” applies
directly to hackers and their determination at times. The response to an intrusion is vital
to how devastating the incident becomes. Time is of the essence during the response
phase. We can learn a lot more on how to reduce risks every time an intrusion occurs,
so long as the IRP is executed effectively and efficiently.
Works-Cited Page
•
Ranum, Marcus J. "A Step-by-step Network Incident Response Plan."
SearchSecurity. 1 Feb. 2004. Web. 5 April 2015.
<http://searchsecurity.techtarget.com/Step-by-step-Creating-an-IT-incidentresponse-plan>.
•
Hinnen, Todd. "Technology: Effectively Responding to a Network
Intrusion." Technology: Effectively Responding to a Network Intrusion. 6 Apr.
2012. Web. 15 Apr. 2015.
<http://www.insidecounsel.com/2012/04/06/technology-effectively-responding-toa-network-int>.
•
"Responding to Network Attacks and Security Incidents." Tech-FAQ. 14 Sept.
2014. Web. 14 Apr. 2015. <http://www.tech-faq.com/responding-to-networkattacks-and-security-incidents.html>.
•
"Chapter10.Incident Response." Creating an Incident Response Plan. Web. 8
Apr. 2015. <https://access.redhat.com/documentation/enUS/Red_Hat_Enterprise_Linux/3/html/Security_Guide/s1-response-plan.html>