The SANS Institute is a partner in the Consensus Audit Guidelines (CAG) project to define the 20 critical security controls most important for network security.  The project defines high-level recommendations, but these recommendations cannot describe in detail, of course, how to implement them in every environment because every environment is different.  But the fact of the matter is that most environments run Windows, and most of these Windows machines are joined to Active Directory domains, that’s just the way it is.

This blog is also about the Securing Windows Track (SEC505) at SANS, so the questions for this article are:  “How does SEC505 map onto the 20 critical controls?  How well does SEC505 prepare one to implement the 20 controls in a Microsoft shop?”  You won’t be surprised to hear, of course, that the answer is “Very Nicely!“, but there are gaps and I’ll point them out below.  SANS has a two-day overview course entitled “20 Critical Security Controls (SEC440)“, but SEC505 is a six-day course specifically for Windows.  So if you’re interested in the CAG and SEC505, please read on, but if not, please skip it, there are much more interesting things to read about on the Net.

For each of the 20 critical controls, the following describes what’s covered in the six-day Securing Windows course that can help you actually implement the controls on Windows systems, not just audit them.  (You might open another tab in your browser to the CAG page to see the summary of each control for comparison with the following.)

Note: The headings below are color-coded: Green means that the control is covered well, Black means the control is covered adequately or partially, and Red means the control is covered slightly or not at all.

Control 1: Inventory of Hardware Devices

SEC505 does not cover hardware inventory products.  However, when gathering inventory data with nmap and other tools, you inevitably run up against problems of how to organize, store, search, compare and generate reports from the mountains of data collected.  This is true even of GUI commercial tools because the vendors can’t anticipate every possible query or report you’ll want.  Whether you use databases, spreadsheets, XML or just comma-delimited text files to store the data, PowerShell is a superb command shell and scripting language for manipulating that data.  Many security tasks are not performed because the administrators lack scripting skills, and inventory tasks are perfect examples.  SEC505 includes a full day on PowerShell scripting.

Control 2: Inventory of Software

SEC505 does not cover software inventory products.  However, without scripting skills, again, it is difficult to extract actionable information from the mountains of ever-changing data you’ll collect with whatever products you do use.  And, in fact, if you’re not using an enterprise management system to software inventory data, PowerShell can help with that too, even on remote systems, using WMI.

This control also advises locking down software installations, using application whitelisting, and logging application usage.  In SEC505 an entire day is devoted to Group Policy and there are many Group Policy technologies for just these sorts of problems, e.g., Software Restriction Policies, AppLocker, audit/logging policies, managing NTFS permissions, configuring almost every aspect of Internet Explorer and the Microsoft Office applications, code signing requirements for scripts/macros, restricting MSI package installation, running scripts to identify non-standard software, etc.

Control 3: Secure Configurations for Computer Systems

Windows machines are not hardened by hand, but by the application of INF/XML security templates, such as with the templates from NIST, CIS and Microsoft.  These templates are applied using Group Policy, SECEDIT.EXE, the Security Configuration and Analysis MMC snap-in, or the Security Configuration Wizard (all of which are covered in SEC505).  For the few settings that cannot be configured through a template or Group Policy, it is likely that a script would be used so that the changes could be automated (PowerShell again).  This control is very well covered in SEC505.

Control 4: Secure Configurations for Network Devices

SEC505 does not cover firewall design, please instead see Perimeter Protection In-Depth (SEC502).

Control 5: Boundary Defense

SEC505 does not cover firewall or IDS design, please see Perimeter Protection In-Depth (SEC502) and Intrusion Detection In-Depth (SEC503).

Control 6: Audit Logs

Windows audit policy and logging is configured through security templates and Group Policy, as mentioned above, since each machine has its own event logs.  SEC505 also covers how to enable logging in the RADIUS servers controlling remote access, such as for VPN, dial-up and 802.11 wireless (in Day 4).  All of this data will need to be consolidated at a central location, usually with a third-party SIM, but when the human touch is needed to go beyond the canned queries and reports of your SIM, how can that data be efficiently extracted and analyzed?  Again, PowerShell scripts using regular expressions and SQL queries work very nicely.  What about configuring third-party SIM products?  Not covered in SEC505.

Control 7: Application-Layer Software Security

SEC505 does not cover secure coding, web application testing or database security.    However, SEC505 does devote a full day to IIS web server hardening.  In that course we talk about, among other things, how to perform HTTP application-layer filtering with the URL Rewrite module and regular expressions, which can be used to implement a basic web application firewall (and the CAG does recommend using a web application firewall).  The IIS day of SEC505 is mainly concerned with locking down IIS servers, which is a special case of Control #3 above.

Control 8: Administrative Privileges

Virtually every recommendation in this control regarding administrative user accounts is discussed in SEC505, especially in the Active Directory (505.1) and Group Policy (505.2) days.  The PKI day of SEC505 (505.3) also walks the attendee through the process of setting up a Windows PKI and issuing smart cards and other certificates to administrative users for secure multi-factor authentication.

Control 9: Need To Know

SEC505 does not discuss need-to-know access control methodology or testing per se, but, again, such controls would be largely enforced through Widnows user groups, security templates and Group Policy.  Testing could be automated through PowerShell scripts which authenticate over the network as different users with different privileges.

Control 10: Vulnerability Scanning

SEC505 does not cover vulnerability scanners, which are covered in other courses, such as Security Essentials (SEC401).

Control 11: Account Monitoring and Control

Most recommendations in this control would be implemented through a combination of Active Directory ACLs, Group Policy settings, and custom AD queries, perhaps with PowerShell scripts.  And all of these topics are nicely covered in SEC505.

Control 12: Malware Defenses

SEC505 does not cover tarpits or honeypots, which are covered in other courses, including Security Essentials (SEC401).  Anti-malware techniques are discussed throughout the week, such as User Account Control benefits and managing Internet Explorer settings, but a comparison of particular AV scanning products or debate about where to install them, that is not covered.

Control 13: Control of Network Ports, Protocols and Services

Group Policy and command-line administration of IPSec and the new Windows Firewall is covered in SEC505 in great detail.  The combination of IPSec + Windows Firewall + Group Policy grants very precise and flexible control over which users and computers are permitted to access which ports/services on which machines; it is possible, for example, to configure something like per-user “roaming VLANs” with these technologies and what Microsoft calls “domain isolation“.  Day four of SEC505 is devoted to IPSec, the new Windows Firewall, the Microsoft RADIUS service, RRAS VPNs (IPSec/SSL/PPTP) and 802.11 wireless security.

Control 14: Wireless

Day four of SEC505 walks you through the steps of setting up a PKI, pushing out wireless certificates (or smart cards), installing RADIUS servers, configuring the wireless settings on laptops through Group Policy, and enforcing the use of WPA2, AES encryption and PEAP authentication at the RADIUS servers.  Through Group Policy you can also lock down and then hide the other wireless options from non-administrative users, e.g., you can prevent them from connecting to ad hoc networks.  Other recommendations in this control unrelated to Windows configuration, such as scanning for rogue access points, are not covered in the course.  SANS has a great week-long track on wireless security (SEC617), but that course isn’t for Windows networks specifically, SEC505 is.

Control 15: Data Loss Prevention

SEC505 covers many of the recommendations of this control for DLP, mainly in day three.  This includes BitLocker whole drive encryption, “BitLocker To Go” for USB flash drives, EFS file encryption, and Group Policy control of USB device usage.  To search for Personally Identifiable Information (PII) on systems, a custom PowerShell script could be used, but this is not discussed per se in the course.  Monitoring the network for data leakage is not covered in SEC505 (try SEC503).

Control 16: Secure Network Engineering

Firewall design is covered in a different course at SANS, Perimeter Protection In-Depth (SEC502), but this control is more broad than that.  As discussed for Control 13, we have Group Policy control over IPSec and Windows Firewall settings for rapid response to attacks.  And in day one of SEC505, DNS security is covered because DNS is the Achilles’ heel of Active Directory.  DHCP logging is easy to enable, so it’s mentioned too, and one might use PowerShell to extract data from large DHCP logs.  Hence, most of the recommendations in this control are covered in SEC505.

Control 17: Penetration Testing

SEC505 does not cover penetration testing, which is discussed in other courses, such as Network Penetration Testing and Ethical Hacking (SEC560).

Control 18: Incident Response Capability

SEC505 does not cover incident response planning, this topic is discussed in other courses, such as Hacker Techniques, Exploits and Incident Handling (SEC504).

Control 19: Data Recovery Capability

SEC505 does not cover how to perform backups and recovery, please see Security Essentials (SEC401).

Control 20: Skills Assessment and Training

SEC505 does not cover security training or awareness testing.

There are a number of tools available for dumping Windows event logs to text files, but there always seems to be a problem or missing data or weird formatting or license issues or…something!

This DumpEventLog.vbs script hopefully is better or at least sucks less, it’s features are:

• Writes output to well-formed CSV text file (one line per log entry, crazy Microsoft formatting cleaned out).
• Works against local and remote systems running Windows 2000 or later (if you have admin privileges).
• Can output all the data from each log entry, even the “insertion strings” and binary attachments (in hex).
• Dump one, some or many event logs on a system by name, or use /all switch to dump them all.
• Events from all the logs are first sorted by time to maintain chronology, then appended to the CSV file.
• CSV data can be directly opened in a spreadsheet or easily imported into a database.
• Script uses asynchronous WMI queries (SWebmSink object) so it’s relatively fast for not being a binary.
• Written in VBScript, so it’s easy to edit if you want to change the output or otherwise modify it.
• Public domain, do with it as you wish!

The intent of the script is to be able to consolidate event log data from multiple machines at one location for local analysis using PowerShell, grep, Excel or whatever your favorite tools are, then to compress the CSV files with gzip for archival.  In the zip file with the script are some sample batch scripts for extracting events of different types.  (If you want a PowerShell version of the script, I’ll get around to it eventually!)

Switches

In a command shell, run “cscript.exe dumpeventlog.vbs /?” to see the help for the script.

DumpEventLog.vbs target file.csv "logname(s)" [/clear] [/v] [/dumphex]
DumpEventLog.vbs target file.csv /all [/clear] [/v] [/dumphex]

Target is the name or IP address of the system from which to extract event log data.

File.csv is the name or full path to a text file, to which the extracted data will be appended.

“Logname(s)” is a comma-separated list of event log names to be dumped (not case sensitive).

/All will dump all the event logs, whatever their names are (not limited to System, Security and Application).

/Clear will clear each log afterwards.

/V for verbose output with entry message text.

/DumpHex implies /V and will also dump insertion strings and any binary attachments.

Target machine must be Windows 2000 or later, running the Windows Management Instrumention (WMI) service, without firewall restrictions for the necessary RPC traffic.  Authentication is single sign-on, so you’ll likely need to log on locally as a Domain Admin in order to dump any log from any remote machine in your domain.  If you schedule the script, it must run under the context of an account (probably a global account) with the necessary privileges to extract/clear the Security event log.

(On a side note, the script was originally written for a scripting course for the sake of discussing WMI, synchronous vs. asynchronous WMI queries, regular expressions, and how to use a connectionless recordset with ADO, so you might find the badly-written code interesting if you’re learning VBScript.)

The Batch Scripts

The other batch scripts in the zip download, such as Last_50_Failed_Logons_In_Excel.bat, are simply to demo how fast and convenient it is to analyze event log data from the command line using free tools like findstr.exe, grep.exe, tail.exe, etc.  Run the AutoDumpAndClearEventLogs.bat first on a test machine to get rolling.

Download the zip file here or from the Downloads page of this blog.

Mozilla Foundation has released Firefox 3.5. The Mozilla Foundation lists multiple security enhancements including improved anti-phishing, anti-malware, and privacy protection.

US-CERT encourages users and administrators to review the Firefox 3.5 release notes and  features and upgrade to Firefox 3.5 as necessary.

In the previous post in this Fried FAT series, we gathered some details about an altered FAT partition on a USB key by running fsstat against it. Our goal is to return the USB key image to its unaltered state.

Let’s run fls to get some information about the files on the image:

Here we’re concerned with the first three entries. We see a regular file that’s been deleted, with metadata information at FAT Directory Entry 5. What do we mean by metadata information? Timestamps, file size and the addresses for the clusters that the file occupies on the disk are all metadata.

How do we know the first file has been deleted? Two ways, first, fls puts an asterisk before the metadata address to indicate the file has been deleted and second, on FAT file systems a deleted file has the first character in its name replaced with hexadecimal value 0xE5 which corresponds to the ASCII underscore. There are two other files, “cover page.jpg” and “Scheduled Visits.exe” with metadata at FAT Directory Entries 8 and 11. In our case notes, we record the information about these three files, including their names, allocation status and the address of the metadata information.

Let’s pursue the first file in fls‘ output. Since we know the address for the file’s metadata, we’ll use the istat command and the metadata address that fls gave us:

Now we’ve got a load of useful information. We see the file is not allocated, which we already knew, the file size, timestamps and the sectors that the file is occupying.

Metadata for files on FAT file systems is stored in two locations. Each file has a FAT Directory Entry that lists the file name, starting cluster and length. Another location for metadata is the File Allocation Table (FAT) that maintains two pieces of information, cluster allocation status and which clusters a given file occupies.

For each cluster on the disk there’s a corresponding entry in the FAT indicating if that cluster is allocated or unallocated. For FAT16, each cluster entry is a two byte value (16 bits, hence FAT16). For allocated clusters, the two byte cluster entry in the FAT will contain a number, that number will be the cluster address for the next cluster the file occupies on disk. So, the FAT Directory Entry tells where the first cluster of the file is, and the FAT tells what additional clusters the file occupies.

Using a hex editor, we can look at the directory entry for a file to determine its starting cluster, then look at the contents of that starting cluster’s entry in the FAT to see the second cluster the file occupies. We can then look at the value stored in the second cluster for the file to see the third cluster the file occupies and so on, until we hit an End-Of-File marker in the FAT cluster chain (for simplicity sake 0xFFFF, see Brian Carrier’s amazing File System Forensic Analysis book for full details as I’m oversimplifying a bit). (Carrier’s book is an essential reference for digital investigators, if you don’t own a copy, you owe it to yourself to check it out, there’s a reason it’s provided to students taking 508.)

Let’s take a quick look, then we’ll wrap up and next time we’ll cover what we’re seeing in the hex editor in more depth. Let’s look at the two metadata locations, first the FAT Directory Entry for our deleted file and its corresponding FAT:

Recall that the FAT Directory Entry tells us, among other things, the file name, starting cluster address and file size. We’ll cover some of these details in more depth in the next post.

And here we see the FAT cluster entries for our deleted file. Just as we expect, they’ve been zeroed out because the file has been deleted.

But wait a minute, if the cluster chain for the file has been zeroed out, where did istat get that list of sectors that the file occupies?

Ponder that. We’ll talk about it next week.

Dave Hull, GCFA Silver #3368, is a technologist focusing on incident response, computer forensics and application security. He can be found on the web at TrustedSignal.com.

The winners of the Best Practices Contest 2009 were announced at the FIRST conference in Kyoto, Japan. Read the winning submissions.