Log monitoring is difficult for many reasons. For one thing there are not many events that unquestionably indicate an intrusion or malicious activity. If it were that easy the system would just prevent the attack in the first place.
Unstructured data access governance is a big compliance concern. Unstructured data is difficult to secure because there’s so much of it, it’s growing so fast and it is user created so it doesn’t automatically get categorized and controlled like structured data in databases.
Interest continues to build around pass-the-hash and related credential artifact attacks, like those made easy by Mimikatz. The main focus surrounding this subject has been hardening Windows against credential attacks, cleaning up artifacts left behind, or at least detecting PtH and related attacks when they occur.
If attackers can deploy a remote administration tool (RAT) on your network, it makes it so much easier for them. RATs make it luxurious for bad guys; it’s like being right there on your network. RATs can log keystrokes, capture screens, provide RDP-like remote control, steal password hashes, scan networks, scan for files and upload them back to home. So if you can deny attackers the use of RATs, you’ve just made life a lot harder for them.
An area of audit logging that is often confusing is the difference between two categories in the Windows security log: Account Logon events and Logon/Logoff events. These two categories are related but distinct, and the similarity in the naming convention contributes to the confusion.
Intrusion detection and compliance are the focus of log management, SIEM and security logging. But security logs, when managed correctly are also the only control over rogue admins. Once root or admin authority has been given to, or acquired by, a user, there is little they cannot do.
I think one of the most underutilized features of Windows Auditing and the Security Log are Process Tracking events. In Windows 2003/XP you get these events by simply enabling the Process Tracking audit policy.
Over the years, security admins have repeatedly asked me how to audit file shares in Windows. Until Windows Server 2008, there were no specific events for file shares.
We hear a lot about tracking privileged access today because privileged users like Domain Admins can do a lot of damage. But more importantly, if their accounts are compromised the attacker gets full control of your environment. In line with this concern, many security standards and compliance documents recommend tracking changes to privileged groups like Administrators, Domain Admins and Enterprise Admins in Windows, and related groups and roles in other applications and platforms.
HIPAA Logging HOWTO, Part 2 The Health Insurance Portability and Accountability Act of 1996 (HIPAA) outlines relevant security and privacy standards for health information – both electronic and physical. The main mission of the law is “to improve portability and continuity of health insurance coverage in the group and individual markets, to combat waste, fraud, and abuse in health insurance and health care delivery” (HIPAA Act of 1996 http://www.hhs.gov/ocr/privacy/). A recent enhancement to HIPAA is called Health Information Technology for Economic and Clinical Health Act or HITECH Act.
I am often asked that if Log Management is so important to the modern IT department, then how come more than 80% of the market that “should” have adopted it has not done so?
Preparing the Infrastructure From all the uses for log data across the spectrum of security, compliance, and operations, using logs for incident response presents a truly universal scenario – you can be forced to use logs for incident response at any moment, whether you’re prepared or not.
Time won't give me time: The importance of time synchronization for Log Management
Despite the fact that security industry has been fighting malicious software – viruses, worms, spyware, bots and other malware since the late 1980s, malware still represents one of the key threat factors for organizations today. While silly viruses of the 1990s and noisy worms (Blaster, Slammer, etc.) of the early 2000’s have been replaced by commercial bots and so-called “advanced persistent threats,” the malware fight rages on.
It doesn't rhyme and it's not what Whittier said but it's true. If you don't log it when it happens, the evidence is gone forever.
If you manage any Linux machines, it is essential that you know where the log files are located, and what is contained in them. From a security perspective, here are 5 groups of files which are essential. Many other files are generated and will be important for system administration and troubleshooting.
Windows gives you several ways to control which computers can be logged onto with a given account. Leveraging these features is a critical way to defend against persistent attackers.
What security events get logged when a user logs on to their workstation with a domain account and proceeds to run local applications and access resources on servers in the domain?
A data breach today takes 127 days to detect, according to the Ponemon Institute. Comprehensive visibility and real-time analysis of device and application log data provide an early warning of cybersecurity threats before damage occurs. Log monitoring and Security Information and Event Management (SIEM) decision makers sometimes make short-sighted financial decisions to reduce log sources, only to find that it impacts security decision making and incident response.
I often encounter a dangerous misconception about the Windows Security Log: the idea that you only need to monitor domain controller logs. Domain controller security logs are absolutely critical to security but they are only a portion of your overall audit trail. Member server and workstation logs are really just as important and I’m going to focus this article on the top 4 questions you can only answer with workstation logon/logoff events.
Analyzing all the login and pre-authentication failures within your organization can be tedious. There are thousands of login failures generated for several reasons. Here we will discuss the different event IDs and error codes and how you can simplify the login failure review process.
Randy Franklin Smith compares methods for detecting malicious activity from logs including monitoring for high impact changes, setting up tripwires and anomalous changes in activity levels. Security standards and auditors make much of reviewing logs for malicious activity.
In most previous newsletters, we have discussed the use of logging for various regulatory mandates (such as PCI DSS, HIPAA and FISMA) as well as the use of logs for incident response and malicious software tracking. This log data can also be incredibly useful for detecting and investigating insider abuse and internal attacks.
