Log Analysis

Airport Security: Don't Make The Same Mistakes

by Paul Asadoorian on January 7, 2010

Airport "Security"

Those of us who travel through any U.S. airport are used to the inconvenience of airport security - the long lines, metal detectors, having to take off your shoes, belts, earrings, and of course the ominous "liquids and gels" inspection. While most people accept these inconveniences as an unfortunate necessity, much of what has been implemented shares some of the common pitfalls found in many computer and network security programs. Using the U.S. airport security model as an example, let’s take a look at some of the security being implemented and relate it to security gone wrong in the enterprise:

  • Throwing Technology at the Problem - Airports are equipped with some of the latest technology to provide security, such as full body scanners and x-ray machines, yet breaches still happen. Most of us who have served in a security role in an organization are all too familiar with this problem. The typical knee-jerk reaction from management to a security problem is to buy a product, such as a firewall, and install it on the network. Technology is important, but the process and people that surround it are what really makes it work. Training people to administer the firewall, and other security measures, to ensure they are being used properly is the key to success. Policy also needs to exist and be enforced, allowing businesses to operate securely.
  • airport-security-line.jpg
    The dreaded long lines at airport security are a by-product of the current security model at U.S. airports.

    Cyberdawn - A Diverse Cyber Exercise - Part II

    by Paul Asadoorian on October 9, 2009

    Passwords are just so easy to abuse...

    It was interesting to see that the top scorer in the game (who went by the handle of "ftp", and coincidentally had 21 scores in the first day of game play!) did not use fancy new exploits, 0day attacks or a wide range of open-source or even commercial tools. He was able to gain access to systems because the teams left default or easily guessable passwords set on some of the Linux servers. He used SSH to login to the systems, then SCP to upload some Python code, that was used to update the scoring engine. From there he was able to maintain access, not by rootkit technology or anything sophisticated, but just hiding in plain sight. The Python script makes a TCP connection to the scoring server and sends a message. It was moved into a file called "/dev/vfat", to make it look like a system file. Next, a shell script was written to call the python script every ten minutes. This file was called "getty" and ran in the background, and was also inserted into the startup scripts to ensure it kept running. The teams never found these processes running and "ftp" won the game, no exploits required.



    hackeratwork.png
    Hacker "ftp" at work, winning the game using built-in tools such as bash, python and SSH.

    Analyzing Network Metadata

    by Paul Asadoorian on October 1, 2009

    When analyzing network traffic it’s typically not as important to look at the contents of the packets; rather the information about them, where they are going and how they got there. This “network metadata” (often referred to as NetFlow data) can reveal interesting information about your network and often uncover misconfigurations, policy abuses and security incidents. I relate it to the movie "The Matrix". In the movie there is a scene where the characters are looking at computer screens displaying “the matrix”. Those who are not accustomed to looking at the matrix will not see "The Blonde" or the "Brunette", but will just see a bunch of green characters.

    matrixjpg.jpg
    What do you see?

    Tenable Log Correlation Engine & Splunk Integration

    by Paul Asadoorian on June 26, 2009

    Setting up the Log Correlation Engine & Splunk

    Tenable has recently released a new Log Correlation Engine (LCE) client that allows you to collect log data from Splunk installations to send to LCE, Tenable’s solution for log storage, normalization and correlation. If you have instances of Splunk in your environment, it’s a simple process to configure the integration. Below is an overview of the traffic flow:

    Full Log Aggregation, Storage and Search

    by Ron Gula on May 20, 2009

    Tenable has released version 3.2 of the Log Correlation Engine (LCE) which includes the ability to store, compress and search any log that is sent to it. This functionality is available to all current LCE customers as a point release upgrade. It also builds upon the existing log normalization, correlation, user tracking and anomaly detection that were already available in prior versions.

    Click on the below image for a demonstration of the LCE performing full log searches from within the Security Center:

    Full Log Search

    Tracking Users Through Logs and Network Activity

    by Ron Gula on June 23, 2007

    Tenable's research group has released a TASL correlation script for the Log Correlation Engine (LCE) that automatically associates learned user accounts with IP addresses. This enables historical tracking of users in organizations that do not have centralized authentication and access control such as university environments or campus-wide networks.

    More on "Never Before Seen" Log Events

    by Ron Gula on January 3, 2007

    This entry concerns more information and analysis of output from the "Never Before Seen" TASL script for the Log Correlation Engine (LCE). We've had the script running at several customer locations and have had interesting data to discuss which helps show the script's usefulness. This blog entry discusses analyzing the results from IntruShield IPS events as well as overall "never before seen" event trending.

    Updated Black-list Correlation

    by Ron Gula on December 28, 2006

    Tenable's research group has recently expanded support for "Black Lists" within the Log Correlation Engine. These new features include enhanced log parsing to identify specific black-list sources as well as leveraging these lists into the "Crowd Surge" detection TASL script.

    Why Correlate With Black Lists?

    Pages