Version 4.1 - 3.10 Syslog
This should not be a hard topic - since syslog is used quite a bit, so everyone should already be familiar with it. Servers, switches, routers and firewalls all use syslog - and send their messages to a syslog server. It's usually Splunk or something similar.
Cisco's IP Application Services page is the main documentation page for many of the 3.0 topics. If there was something that I completely understood and lightly covered in most of the previous sections, more detail will be found there. But the Wikipedia page is a little more useful for syslog general concepts.
Syslog uses UDP 514. There have been attempts to secure syslog by using TLS - that runs over TCP port 6514. That port was specified in RFC 5425 - TLS Transport Mapping for Syslog, however, implementations of syslog on TCP ports (and various ways to secure it) have been implemented by multiple vendors on multiple ports.
You should know the Event Logging Severity Levels:
0 - Emergencies
1 - Alerts
2 - Critical
3 - Errors
4 - Warnings
5 - Notifications
6 - Informational
7 - Debugging
You may see a question on another topic that looks like it has two correct answers. But maybe if you look closely, the incorrect answer may have a bogus syslog message (level 6 message about a critical event or error). But that's just a guess on how they would work this into another question/section.
Note that the facility code is different from the severity level.
It's probably worth reading Configuring Logging for the ASA on 9.0.
You will want to at least be familiar with the EMBLEM format. "The EMBLEM format is used primarily for the CiscoWorks Resource Manager Essentials (RME) Syslog analyzer. This format matches the Cisco IOS Software Syslog format produced by routers and switches. It is available only to UDP Syslog servers."
You may also want to at least know about syslog-ng. It's mainly for Unix systems, but you might see it on "hardened" security devices. [Probably won't be on the test, but might be a distractor - and you very well may see it in practice.]
Before I end this section, let's think about logging in general. What is its importance - especially related to security? Well, it documents things (how much and how well depends on the logging level). If there was any malicious activity, the first place you would want to look is the syslog evidence. Most people look at the logs when there is a problem with the device. Are there any error messages that might point to the cause? But security looks at logs as evidence. Was something tampered with? Were unauthorized changes implemented? This is why they try to log everything to a central syslog server - so it is all in one place. This central server should only have read-only access for anyone that can alter the device or its buffer. That way if a malicious user was on the device, they could cover their tracks on only the device's buffer - and not be able to cover up any logging sent to the central server.
In theory this is a good idea. In practice - well, there are issues. Since most of syslog implementations use UDP 514, the messages are using unreliable transport. They may or may not get to the server. Since every device is using the central server, it normally becomes overwhelmed (especially in a "situation" - where many devices could be sending more information than usual). And there is never any support for implementing a robust syslog system. It's like backups - they're not important...until they're critical. And if you hear the word "Splunk" and roll your eyes - well, sometimes it's really hard to find stuff (or takes forever for a search to return results). One of the solutions I've seen is to have multiple syslog servers. You have the one central server where everyone logs everything. Then you have a separate server that logs just certain devices. Just your firewalls log to SyslogA. Just your switches log to SyslogB. And just your routers log to SyslogC. It makes things easier for engineers to find while troubleshooting and still meets the Security Policy requirements for having a centralized server.
One of the other things to remember about syslog and security is "event correlation." This is why they want everything in one location. This is so you can detect related events (during or after a breach). This is also related to NTP - since how do you know if it's happening at the same time if your clocks aren't synchronized?
I think I've completely exhausted what I want to say about syslog. Mainly - a direct question would be about UDP 514 or the Event Levels. Remember all of 3.0 is covered in about 10 questions.