Security Mistakes That Leave You Vulnerable To Compromise #6: No Centralized Logging


Logging network activity is one of the most powerful tools in your security arsenal; it lets you confirm or deny suspicious behavior and it lets you reconstruct events long after they happen. According to many security analyses, organizations often learn about intrusions long after the initial compromise, and having a history of events allows you to go back to see what happened and figure out what can be done to prevent similar attacks in the future.

Log data is invaluable not only to investigate specific events, but also to detect the existence of events in the first place.  Comprehensive log data allows staff to investigate hunches or theories that a SIEM is unable to assist with.   For example, an analyst may notice a PC acting strangely, and suspect that it has some sort of yet-undetected malware.   An investigation into the PCs history can help determine if the suspicion is warranted or misplaced:  what systems has this PC connected to?  Has it attempted other suspicious activity such as scanning other PCs?  Has it attempted to connect to unusual or unauthorized devices?  If the PC has connected to suspicious websites, who else in the organization has also connected to these websites?  Another example is where an analyst notices an abnormality such as a user logging in at odd hours.  Does that user do it often, or is this the only time?  Is the source address from a foreign country?

With comprehensive network logging, an analyst can answer all these questions quickly.

It is important to gather logs from as many sources as possible. Most organizations simply collect logs from routers and firewalls. If you’ve compartmentalized your network as explained above, you should also be logging attempted policy violations.     That is, whenever an access list blocks traffic, that event should be logged.

You should not stop at logging just your routers and firewalls. You should be logging all authentication events (logins) from your Active Directory, Linux and VPN devices. Be sure you log both successful logins as well as failures.  You should also include proxies and IDS sensors. If other enterprise applications, such as order processing, CRM systems or accounting systems generate logs, you should be collecting those too.  In short, collect all the logs you can from all your systems.

Of course, its one thing to collect logs. Searching for the right log entry out of gigabytes of log data is another matter. Many organizations collect lots of log data and dutifully archive it, never to be seen again. But the ability to find relevant information quickly can make or break a your security monitoring.         Fortunately there are a number of log analysis systems, both commercial and open source, that allow you to search through months of log data based on any number of criteria. Having a detailed log history can help you answer questions such as “When did jsmith log into the system last month?” “Has the PC at IP address ever been attempted to access a restricted server?” “Who logged in to the database at 2:00 am last Saturday night?”

A search system needs to combine structured and unstructured (i.e. full text) searches.  Searches need to be fast enough so that analysts can perform ad-hoc queries, follow up on hunches, etc. Ideally search data can be presented in several forms, including tables and graphs.  In some cases, it is necessary to control access to certain users, so they have access to only a subset of log data.

Should you build an open source system, or buy a commercial product? This is the perennial question, as there are both commercial products and open-source utilities that fit the bill for logging and retrieving data.  Often, commercial logging systems are often built on top of or duplicate existing open-source products, and give them user-friendly interfaces.  Many open-source logging utilities are part of Unix/Linux utilities and are fully functional systems in their own right.

Open-source applications do need more system administrative effort than commercial products, but they usually offer more flexibility than their commercial counterparts.  Commercial products, on the other hand, are almost “plug-and-play,” but you are often locked into managing your data the way the products developers think it ought to be done.

In the end, the build or buy decision often comes down to the available system administrative skills.  If you have staff that is comfortable in the Linux environment, open-source software may be a cost-effective option.  If not, then commercial products may be a better choice.  But whatever you end up using, having this log data available will be one of your most powerful tools to detect and defend against network attacks.

One response to “Security Mistakes That Leave You Vulnerable To Compromise #6: No Centralized Logging

  1. Well assume that we’re in a plurality election here, so the winner is the person who gets a plurality.[url=]Moncler Boots sale[/url]

Leave a Reply


Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.


Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.


John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.