Catcher in the Rye
Information Security goes on the Offensive
By S. Russell Dyer BS(MIS)
CISSP CRISC
Prologue
It is well documented that the man who shot John Lennon,
JFK’s assassin, and the guy who shot
Ronald Reagan all had a copy of the book “Cather in the Rye”.
What if we could identify malicious hackers by their common access to a single file, or
group of files?
Information Security is a constant game of cat and mouse.
Unfortunately, the good guys are frequently
one step behind the bad guys. Hackers
discover a security flaw in a particular software and begin exploiting it and
eventually Security practitioners detect and classify the activity as malicious.
Then with the help of developers either patch the flaw or apply new methods or
tools to mitigate the security issue. Then the cycle repeats in a never-ending
circle.
Perhaps we can shift this paradigm in favour of the good
guys. Or even turn it upside down entirely where the hackers are the ones
trying to catch up and figure out what is safe for them to touch and what is
not?
Background
Firstly, we must understand the typical process a hack
follows and match this process to the attacker’s high level goals.
For a hacker to be successful he, or she, will undertake the
following tasks.
- Exploit a software or configuration flaw to gain access to a host system.
- Make changes to ensure access survives a reboot of the system.
- Hide any traces of activity to enable longevity of access.
Once these three objectives are accomplished, the hacker can
start poking around and looking for valuable information. Also, using this compromised
system as a pivot point to move deeper into the network and compromises more
valuable hosts.
Flipping the
Paradigm
While we endeavor to have all our network assets and infrastructure
patched and secured, there will always be one or two systems which slip through
the cracks. Whether it’s a server running an older operating system that’s due
to be replaced in the near future, or an application running on a server which
isn’t quite on the latest patched version. There will be cracks and these will
be exploited in an attack.
Honeypots have been around for a while and are an ok system
to use in an attempt to entice and detect hacking activity; they rely on the
hacker focusing on the honeypot, and
activity on that honey pot server being used and an indicator that there has
been a security breach. But there is no way to guarantee that an attacker will
target the honeypot and not a different, more important system.
I propose a new take on the honeypot, the Honey file.
Honey files can be placed on each system and monitored at a
heightened level to serve as an alarm and strong indication that the system has
been compromised by an attack.
The honey file is a specially created file which meets the
following criteria.
- Not accessed or used by the host hardware, operating system or any installed applications on the system on which is resides. (Thus any accesses or changes to the file can be assumed to be either accidental maintenance related or malicious hacker activity)
- Must not contain any information that would be of actual value to an attacker.
- Any alterations, additions or event complete removal of this file must in no way affect the host system or application in any way.
- This file may contain authentic looking but fake information useful for tracking follow on malicious activity.
- Taylor the honey file to the host system so as to project an air of authenticity and criticality. This increases the chance it will be accessed by a hacker. Also don’t put obvious windows server type files on a unix server or vice versa.
The time and effort invested in creating the honey files
will directly impact the effectiveness of the files when in use.
Think of scenarios where developers or server admins might
have “accidently” left valuable information on a server prior to it going live
and then forgotten to remove it later on.
It is recommended that several types of honey file be
employed to increase overall effectives.
- Fake Database honey file. A database that contains bogus information and can be monitored strictly. Databases are high priority targets for hackers
- Fake Procedure documents with embedded fake login information. Any access attempt by credentials listed in these documents can be considered malicious hacker activity and show a hacker has file system access on the system.
- Fake configuration text files. Specific Unused IP addresses can be listed in these files and monitored to alert on attacks.
So what is the
logic behind this ?
The goal is to seed juicy files throughout your environment
and configure a high level of alerts and monitoring on these files. These files will be the tripwire which set
off the alarm bells and represents a strong indication of malicious activity.
Most systems have minimal logging enabled due to issues with
load and resource utilization. By using
distributed honey files we alleviate the need to turn up logging on the
majority of systems and have a more targeted and accurate indication of
malicious activity with a vastly reduced number of false positives when
compared to the traditional Intrusion Detections systems.
Notes
Honeyfiles:
Deceptive Files for Intrusion Detection -
http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA484922
