SIEM Deployment - Creating Logs on Linux Servers with audit.rules

As I mentioned in several other blog articles, your Security Event Management infrastructure is only as effective as your source auditing capabilities. If you are not generating the necessary logs, containing useful information and in an understandable and meaningful structure, no matter how correctly you deploy your log management product, you end up failing.

That is actually why I am spending this much time (and you also should) examining each and every source system and write about them here in several articles. My first articles were on the mere basics you should follow to see your logs on the log management platform. In these new series of articles, I will mention about what events, as a minimum, we should care and how to log them. Let’s get started!

In Linux systems, what events are going to be logged is managed by the audit.rules file which is most of the times located under /etc/audit/ folder. In the scheme below you can see the way the audit mechanism works in Linux.

The good point concerning auditing features of Linux comparing to Windows Servers is that you can pretty much audit everything and customize the logs according to your needs. You can write audit rules for any process or command you want, you can specifically audit the actions of a special user or audit only a specific action (write, read, execute, append). The name tags that you can add to your log messages may greatly simplify your job when you will be writing your correlation rules on your SEM engine.

The way how an audit rule is written is explained in auditctl man page. Below I am giving a nice template which covers most of the general situations. You should make sure that you cover all your critical processes by adding audit rules for them.

An important thing to know about using this file is to adapt it to your own systems. One of the first things you should do is to use arch= parameter accordingly whether you are using a 32 bit system (b32) or a 64 bit system (b64). Some files and commands change from older versions to newer ones, eg. faillog file which keeps the failed log attempts in Red Hat Enterprise Linux 5 does not exist anymore in later versions and you should configure for pam_tally process and files. Also, please change the comments in rules (text after –k parameter) according to your needs.

Finally there are 2 parameters that need to be used with caution. Do use “e -2” parameter in the end of the file to prevent tampering without logging and reboot. The second parameter “h -2” is more likely to be used in military/defense environments, causes system to halt if logging is crashed, so it should be used with caution.

# First rule - delete all -D

# Increase the buffers to survive stress events.

# Make this bigger for busy systems

-b 8096

# Feel free to add below this line. See auditctl man page

#Capture all failures to access on critical elements

-a exit,always -F arch=b64 -S open -F dir=/etc -F success=0 -k CriticalElementFailures

-a exit,always -F arch=b64 -S open -F dir=/bin -F success=0 -k CriticalElementFailures

-a exit,always -F arch=b64 -S open -F dir=/sbin -F success=0 -k CriticalElementFailures

-a exit,always -F arch=b64 -S open -F dir=/usr/bin -F success=0 -k CriticalElementFailures

-a exit,always -F arch=b64 -S open -F dir=/usr/sbin -F success=0 -k CriticalElementFailures

-a exit,always -F arch=b64 -S open -F dir=/var -F success=0 -k CriticalElementFailures

-a exit,always -F arch=b64 -S open -F dir=/home -F success=0 -k CriticalElementFailures

#Capture all successful deletions on critical elements

-a exit,always -F arch=b64 -S unlinkat -F success=1 -F dir=/etc -k CriticalElementDeletions

-a exit,always -F arch=b64 -S unlinkat -F success=1 -F dir=/bin -k CriticalElementDeletions

-a exit,always -F arch=b64 -S unlinkat -F success=1 -F dir=/sbin -k CriticalElementDeletions

-a exit,always -F arch=b64 -S unlinkat -F success=1 -F dir=/usr/bin -k CriticalElementDeletions

-a exit,always -F arch=b64 -S unlinkat -F success=1 -F dir=/usr/sbin -k CriticalElementDeletions

-a exit,always -F arch=b64 -S unlinkat -F success=1 -F dir=/var -k CriticalElementDeletions

#Capture all successful modification of owner or permissions on critical elements

-a exit,always -F arch=b64 -S fchmodat -S fchownat -F dir=/etc -F success=1 -k CriticalElementModifications

-a exit,always -F arch=b64 -S fchmodat -S fchownat -F dir=/bin -F success=1 -k CriticalElementModifications

-a exit,always -F arch=b64 -S fchmodat -S fchownat -F dir=/sbin -F success=1 -k CriticalElementModifications

-a exit,always -F arch=b64 -S fchmodat -S fchownat -F dir=/usr/bin -F success=1 -k CriticalElementModifications

-a exit,always -F arch=b64 -S fchmodat -S fchownat -F dir=/usr/sbin -F success=1 -k CriticalElementModifications

-a exit,always -F arch=b64 -S fchmodat -S fchownat -F dir=/var -F success=1 -k CriticalElementModifications

-a exit,always -F arch=b64 -S fchmodat -S fchownat -F dir=/home -F success=1 -k CriticalElementModifications

#Capture all successful modifications of content

-a exit,always -F arch=b64 -S pwrite64 -S write -S writev -S pwritev -F dir=/etc -F success=1 -k CriticalElementModifications

-a exit,always -F arch=b64 -S pwrite64 -S write -S writev -S pwritev -F dir=/bin -F success=1 -k CriticalElementModifications

-a exit,always -F arch=b64 -S pwrite64 -S write -S writev -S pwritev -F dir=/sbin -F success=1 -k CriticalElementModifications

-a exit,always -F arch=b64 -S pwrite64 -S write -S writev -S pwritev -F dir=/usr/bin -F success=1 -k CriticalElementModifications

-a exit,always -F arch=b64 -S pwrite64 -S write -S writev -S pwritev -F dir=/usr/sbin -F success=1 -k CriticalElementModifications

-a exit,always -F arch=b64 -S pwrite64 -S write -S writev -S pwritev -F dir=/var -F success=1 -k CriticalElementModifications

-a exit,always -F arch=b64 -S pwrite64 -S write -S writev -S pwritev -F dir=/home -F success=1 -k CriticalElementModifications

#Capture all successful creations

-a exit,always -F arch=b64 -S creat -F dir=/etc -F success=1 -k CriticalElementCreations

-a exit,always -F arch=b64 -S creat -F dir=/bin -F success=1 -k CriticalElementCreations

-a exit,always -F arch=b64 -S creat -F dir=/sbin -F success=1 -k CriticalElementCreations

-a exit,always -F arch=b64 -S creat -F dir=/usr/bin -F success=1 -k CriticalElementCreations

-a exit,always -F arch=b64 -S creat -F dir=/usr/sbin -F success=1 -k CriticalElementCreations

-a exit,always -F arch=b64 -S creat -F dir=/var -F success=1 -k CriticalElementCreations

#Capture all successful reads (only for High-Impact Systems)

-a exit,always -F arch=b64 -S open -F dir=/etc -F success=1 -k CriticalElementReads

-a exit,always -F arch=b64 -S open -F dir=/bin -F success=1 -k CriticalElementReads

-a exit,always -F arch=b64 -S open -F dir=/sbin -F success=1 -k CriticalElementReads

-a exit,always -F arch=b64 -S open -F dir=/usr/bin -F success=1 -k CriticalElementReads

-a exit,always -F arch=b64 -S open -F dir=/usr/sbin -F success=1 -k CriticalElementReads

-a exit,always -F arch=b64 -S open -F dir=/var -F success=1 -k CriticalElementReads

#Monitor for changes to shadow file (use of passwd command)

-w /usr/bin/passwd -p x

-w /etc/passwd -p ra

-w /etc/shadow -p ra

#Monitor for use of process ID change (switching accounts) applications

-w /bin/su -p x -k PrivilegeEscalation

-w /usr/bin/sudo -p x -k PrivilegeEscalation

-w /etc/sudoers -p rw -k PrivilegeEscalation

#Monitor for use of tools to change group identifiers

-w /usr/sbin/groupadd -p x -k GroupModification

-w /usr/sbin/groupmod -p x -k GroupModification

-w /usr/sbin/useradd -p x -k UserModification

-w /usr/sbin/usermod -p x -k UserModification

#Ensure audit log file modifications are logged.

-a exit,always -F arch=b64 -S unlink -S unlinkat -F dir=/var/log/audit -k AuditLogRemoval

# Monitor for use of audit management tools

-w /sbin/auditctl -p x -k AuditModification

-w /sbin/auditd -p x -k AuditModification

# Ensure critical apps are monitored.  List will vary by mission.

-a exit,always -F arch=b64 -F path=/sbin/init -k CriticalAppMonitoring

-a exit,always -F arch=b64 -F path=/usr/bin/Xorg -k CriticalAppMonitoring

-a exit,always -F arch=b64 -F path=/usr/sbin/sshd -k CriticalAppMonitoring

-a exit,always -F arch=b64 -F path=/sbin/rsyslogd -k CriticalAppMonitoring

#  Ensure attribute changes are audited

-a exit,always -F arch=b64 -S chmod -S chown -S fchmod -S fchown -S setuid -S setreuid -S getxattr -S setxattr -k AttributeChanges

Considerations About a Successful SIEM and Log Management Project

You may spend a lot of effort to build up an infrastructure of SIEM and Log Management composed of source systems, connectors, loggers, rule creation and correlation engines and management systems and then see very little of valuable output….if you do not pay attention to the first thing you actually do in the first place: Define a proper auditing policy.

A recent and very successful approach for building Log Management and SIEM capabilities actually consists of an inverse installation process. Some Security Service Providers come and collaborate with your teams to apply defined risk scenarii on your infrastructure to see if your infrastructure components generate the log messages which should alert you that something unusual and odd is going on. It is at this very step that your SIEM team learns which type of events they should be collecting among a big pile of others, which in many cases constitute most of your log storage without actually providing a value.

Such an approach may create huge differences in outputs and may trigger changes in your infrastructure. I know companies which changed some of their components just because they do not provide essential log information which would allow security alert generation.

A very important thing to keep in mind when deploying SIEM solutions is the involvement of all infrastructure and application teams. No matter how qualified IT Security guys responsible for SIEM deployment, they do not master Operating Systems as much as Windows, Linux and UNIX administrators do, also considering different versions of OSes that can be in place. To my experience, I know that 3 generations of Windows Servers coexist in majority of companies without counting R2 versions. It goes the same way for databases and applications. A SIEM project would probably fail or underperform if all IT teams do not collaborate with SIEM project team and stay isolated in their silos.

Another way of dealing with this issue would be to create a security team composed of security masters in each domain. First difficulty in that approach is to bring together such talents which is very costly and the second challenge is to keep them in the company and provide consistency because such people are highly in demand. This option seems applicable only in very large structures such as multinationals, especially in finance sector where there really are some things to be at stake, money and also reputation.

There are of course lots and lots to say about other aspects of SIEM and Log Management projects. But maybe the most important things to know about them are to set the expectations correctly (Benefits, Aim: “Security?, Compliance?, Both?”, Scope, Schedule and Budget), be patient, provide continuous support and monitor the output closely. The technology in this market is rapidly evolving and it still has much more to offer in years to come.

SIEM Deployment - HP Arcsight Logger Installation

HP Arcsight Logger product constitutes the log management part of HP's Security Event Management and Log Management product portfolio, ESM being the security event management part.

Before getting this much into SEM and Log Management, they both meant the same thing for me, as most of the products available on the market were trying to do. Architecture-wise, Arcsight managed to distinguish its offerings  for different needs and markets. This issue is the topic of another blog entry however if you are looking for a product which will allow you to store all your logs in a stable way and query specific patterns very quickly then Arcsight Logger is the solution you are looking for.

As of mid-2015, the latest version of HP Arcsight Logger is the 6.0 SP1 version with no known security bugs. Arcsight 6.0 SP1  :

• Distributes latest version of OpenSSL, 0.9.8zc, which addresses multiple vulnerabilities including CVE-2014-0224.
• Resolves the Bourne-Again Shell (Bash) Code Injection Vulnerability, including CVE-2014-6271, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187, CVE-2014-6277, and CVE-2014-6278.
• Disables support for SSL v3.0 encryption, to address the Padding Oracle On Downgraded Legacy Encryption (POODLE) vulnerability (CVE-2014-3566).

Version 6.0 SP1 also brings support for doubled local storage size. Each instance of logger now can support up to 8TB of logs before sending logs to archive.

In this article, I tried to resume how you can get your Logger up and running in a short amount of time. This is also the first time for me to include a video which obviously makes the article more interesting.

The installation of Arcsight Logger is a 2 step process, Preparation and Installation itself.

For the preparation you should of course have your server equipped with necessary resources (just like all other Log Management products, Logger also is greedy in resources), Logger software, license,user accounts (root privileges are required for the installation) and ports.
PREPARATION
Server Requirements
OS

• Red Hat Enterprise Linux (RHEL) versions 6.2 and 6.5 (64-bit),
• CentOS versions 5.5 and 6.5 (64-bit)

Hardware

For the Trial Logger and VM Instances:
CPU: 1 or 2 x Intel Xeon Quad Core or equivalent
Memory: 4 - 12 GB (12 GB recommended)
Disk Space: 10 GB (minimum) in the Logger installation directory (/opt/...)
Temp directory: 1 GB

For the Enterprise Version of Software Logger:
CPU: 2 x Intel Xeon Quad Core or equivalent
Memory: 12 - 24 GB (24 GB recommended)
Disk Space: 65 GB (minimum) in the Software Logger installation directory. (/opt/...)
Root partition: 400 GB
Temp directory: 1 GB

For performance reasons, it is preferable to use dedicated hardware for Logger rather than using virtual machines. For faster searchs archive connections should be over direct fiber channel rather over NFS.

Logger interface can be reached through all known browsers with recent versions.

Logger can be installed using root and non-root accounts but following points should be taken into consideration:

• For root installs, allow access to port 443 as well as the ports for any protocol that thelogger receivers need, such as port 514 for the UDP receiver and port 515 for the TCP receiver.
• For non-root installs, allow access to port 9000 as well as the ports for any protocol that the Logger receivers need, such as port 8514 for the UDP receiver and port 8515 for the TCP receiver.

INSTALLATION
You can follow instructions given below. The video also follows the same steps.

1. Install Linux Server (Minimal Server with GUI for trial installations). Do not "Easy Install" when using Vmware and manually set partitions

2. Adjust partitions as below as a minimum:

/ 10240 MB
/home 10240 MB
swap 4096  MB (Typically half of your RAM but do not exagerrate)
/opt 70000 MB (Give Minimum 65 GB, more is better)
/tmp 2048  MB

3. Create arcsight user

groupadd arcsight
useradd -c "arcsight_software_owner" -g arcsight -d /home/arcsight -m -s /bin/bash arcsight

4. Copy sources and license to /home/arcsight

5. Set hostname in /etc/hosts

#vim /etc/hosts

192.168.X.Y logger.mycompany.com

6. Make sure system time is correct

7. Create /opt/arcsight with arcsight user
chown arcsight:arcsight /opt/arcsight

8. Disable selinux and iptables for performance (Use Network Firewall instead !!)

Selinux can be an important performance drawback!

#chkconfig iptables off
#chkconfig ip6tables off
# vim cat /etc/sysconfig/selinux

SELINUX=disabled

9. Change release file if not using recommended versions
vim /etc/redhat-release
CentOS release 6.5 (Final)

10. Make OS changes specific to Logger
chmod +x /sbin
chmod +x /sbin/ifconfig
chmod +x /sbin/lspci
chmod +x /usr/sbin

#vim /etc/security/limits.d/90-nproc.conf
* soft nproc 10240
* hard nproc 10240
* soft nofile 65536
* hard nofile 65536

#reboot

11.Install Logger
#cd /home/arcsight

#./ArcSight-logger-6.0.0.7307.1.bin

SIEM Deployment - Collecting Logs from Linux Servers

Most companies run their business critical systems on Linux servers, which are famous for their stability, performance, security among other capabilities. Collecting logs from Linux servers thus becomes an important step in realizing Log Management projects.

Log management problem and need for Linux and UNIX servers is thought and taken care of long before it is finally taken seriously by Microsoft; therefore configuration is more straightforward and works more stable in my experience.

There is however a list of items to be followed carefully in order to be sure that everything works fine. The list may be hard to keep in mind comparing to steps in Windows, so I list them down below.

1. Check auditd daemon configuration to see if auditing service works fine (/etc/audit/auditd.conf)
2. Check audit event dispatcher configuration (/etc/audisp/audispd.conf)
3. Configure audit event dispatcher syslog configuration (/etc/audisp/plugins.d/syslog.conf)
4.  Create audit rules by editing /etc/audit/audit.rules file (More detail below)
5. Configure the syslog daemon to redirect log messages to a collector server.
6. Restart the daemons to activate the configurations.

I took RedHat family of Linux systems (RHEL, CentOS, Fedora,etc.) for configuration example in this article and configuration steps and commands apply to almost all Linux distributions with small changes.

There is not much to say about first and second steps, as they are routine controls to see if daemons are enabled and fine tunings may be done if necessary.

At the third step, under the syslog.conf file we should configure the args parameter to say what facilities we want to send to the syslog. To be coherent with the below configuration I set it as below:

args = LOG_INFO LOG_LOCAL5 LOG_LOCAL4 LOG_LOCAL3

Then comes a very important step, configuring the audit.rules file which actually is your audit policy for the server. If you are up to this point, most probably your company should already have one and your audit.rules file should not be empty. But in case you started being interested with linux servers just for the sake of log management (like me), I would suggest you to first read and edit, and then copy the usr/share/doc/audit-x.y.z/stig.rules document as your audit.rules file. stig.rules file is a really well prepared document to guide you to write your own rules and it is very good for a starter honestly. In my case the configuration applied was like below:

[root@localhost etc]# vi /usr/share/doc/audit-2.3.7/stig.rules

[root@localhost etc]# cp /usr/share/doc/audit-2.3.7/stig.rules /etc/audit/audit.rules

cp: overwrite `/etc/audit/audit.rules'? y

I can also suggest you to add below lines in your audit.rules file as a best practice. (For 64bit systems in this example)

-a always,exit -F arch=b64 -S sethostname -S setdomainname -k HOSTNAME_CHANGED

-a always,exit -F arch=b64 -S kill -F a1=9 -k KILL9

-a always,exit -F arch=b64 -F subj_type!=ntpd_t -S settimeofday -k SYSTEM_TIME_CHANGED

-a always,exit -F arch=b64 -F subj_type!=ntpd_t -S adjtimex -k SYSTEM_TIME_CHANGED

-a always,exit -F arch=b64 -F subj_type!=ntpd_t -S clock_settime –k SYSTEM_TIME_CHANGED

-w /etc/localtime -p wa -k SYSTEM_TIME_CHANGED

-a always,exit -F arch=b64 -S mount -k DEVICE_MOUNTED

-a always,exit -F dir=/boot -F perm=wa -k SYSTEM_FILE_CHANGED

-a always,exit -F dir=/root -F perm=wa -k SYSTEM_FILE_CHANGED

-a always,exit -F dir=/etc -F perm=wa -k SYSTEM_FILE_CHANGED

-a always,exit -F dir=/bin -F perm=wa -k SYSTEM_FILE_CHANGED

-a always,exit -F dir=/sbin -F perm=wa -k SYSTEM_FILE_CHANGED

-a always,exit -F dir=/lib -F perm=wa -k SYSTEM_FILE_CHANGED

-a always,exit -F dir=/lib64 -F perm=wa -k SYSTEM_FILE_CHANGED

-a always,exit -F dir=/usr -F perm=wa -k SYSTEM_FILE_CHANGED

-a always,exit -F dir=/net -F perm=wa -k SYSTEM_FILE_CHANGED

-a always,exit -F dir=/sys -F perm=wa -k SYSTEM_FILE_CHANGED

-a always,exit -F dir=/cgroup -F perm=wa -k SYSTEM_FILE_CHANGED

-a always,exit -F dir=/selinux -F perm=wa -k SYSTEM_FILE_CHANGED

-a always,exit -F dir=/var/adm -F perm=wa -k SYSTEM_FILE_CHANGED

-a always,exit -F dir=/var/lib -F perm=wa -k SYSTEM_FILE_CHANGED

-a always,exit -F dir=/var/spool/cron -F perm=wa -k SYSTEM_FILE_CHANGED

-a always,exit -F dir=/var/spool/at -F perm=wa -k SYSTEM_FILE_CHANGED

-a always,exit -F dir=/var/spool/anacron -F perm=wa -k SYSTEM_FILE_CHANGED

-a always,exit -F path=/var/log/messages -F perm=wa -F subj_type!=syslogd_t -F subj_type!=logrotate_t -k LOG_ALTERED

-a always,exit -F path=/var/log/dmesg -F perm=wa -F subj_type!=syslogd_t -F subj_type!=logrotate_t -k LOG_ALTERED

-a always,exit -F path=/var/log/secure -F perm=wa -F subj_type!=syslogd_t -F subj_type!=logrotate_t -k LOG_ALTERED

In the fifth step, we should configure the syslog daemon. In Linux systems, rsyslog service is responsible from reading the events and writing them to specific log files. To decide which actions are going to be logged /etc/rsyslog.conf file should be edited with a text editor.

More specifically RULES section in rsyslog.conf file should be edited like below:

#### RULES ####

# Log all kernel messages to the console.

# Logging much else clutters up the screen.

#kern.*                                                                                          /dev/console

# Log anything (except mail) of level info or higher.

# Don't log private authentication messages!

*.info;mail.none;authpriv.none;cron.none                           /var/log/messages

# The authpriv file has restricted access.

authpriv.*                                                                                    /var/log/secure

# Log all the mail messages in one place.

mail.*                                                                                          /var/log/maillog

# Log cron stuff

cron.*                                                                                         /var/log/cron

# Everybody gets emergency messages

*.emerg                                                     

# Save news errors of level crit and higher in a special file.

uucp,news.crit                                                                        /var/log/spooler

# Save boot messages also to boot.log

local7.*                                                                                   /var/log/boot.log

#Log Management

syslog.info; auth.info; daemon.info;                               @@CollectorServerIP

authpriv.info; cron.info; kern.info

# System log information

local5.info, local4.info, local3.info                                 @@CollectorServerIP

In the above configuration @ sign symbolizes log sending over UDP 514 port and @@ symbolizes TCP 514 port. In order to not to lose any logs I configured it over tcp. I have been told by a colleague recently that this may add a significant load on systems where number of logs are important, but I still believe that tcp method should be given a chance before switching to udp, if it is deemed inevitable.

If you want to complicate things you may choose to send your logs you may send them encrypted but that configuration is not a part of this article.

As a final step, we restart the auditd and rsyslog services. At this point we must be able to see on the collector server log messages arriving to the syslog server software installed.

SIEM Deployment - Collecting Logs from Windows Servers

An important step in SIEM deployments is to collect logs from servers on which your infrastructure, applications and middleware run.

The event collection from servers is to be seen in the 2nd step in a 3 step approach in SIEM deployment, first step being network and network security devices and last step being the applications.

Microsoft proposes a well-designed log collection infrastructure with 2 options left to the administrators. Both methods use WinRM protocol and are safer than collecting logs using RPC.

In the first method, the collector server connects to event sources and pulls the logs with the help of a domain user which is added to the Event Log Readers group. This method is known as “Collector Initiated Event Forwarding” in Microsoft world and can be better remembered as PULL method. This is the easier method but does not scale well in large environments and may be inefficient as the collector server should regularly contact event sources whether they have logs to transmit or not.

In the second method, which I will detail more in this article, event sources push logs to a collector server over http or https. This method is known as “Source Initiated Subscription” and can be better remembered as PUSH method. This method scales much better to larger environments and is definitely more secure when https option is used as transmission protocol. This method requires less configuration when configured through Group Policy. However special attention must be paid for the collector server when logs are sent over https, especially about listener configuration as it is not that well documented on Microsoft’s documentation and needs good system administration skills.

EVENT SOURCE CONFIGURATION

First of all, the winrm service should be activated from the command line with winrm quickconfig command.

In the Local Group Policy Editor, under Computer Configuration -> Administrative Templates ->  Windows Components -> Event Forwarding menu, “Configure the server address, refresh interval, and issuer certificate authority of a target Subscription Manager” setting should be configured as below:

            

At this point you can prefer to use http or https protocols to transmit your logs to the collector server. The only difference at the event source is the port numbers used for http and https protocols which are 5985 and 5986 respectively as shown below:

Server=http://Servername.Domain:5985/wsman/Subscription Manager/WEC,Refresh=60

Server=https://Servername.Domain:5986/wsman/Subscription Manager/WEC,Refresh=60

Log sending period is chosen as 60 seconds in these examples.

 Once event forwarding configuration is done, the group policy must be updated with  gpupdate /force command.

 In Local Security Policy screen, audit policy settings under Security Setttings -> Local Policies ->  Audit Policy should be configured. It is recommended to enable logging for both successful and failed attempts for all policy items except “Audit object access”, as this setting may generate too many logs if both successful and failed attempts are logged. I recommend configuring this setting only for failed attempts for the beginning and deciding later according to the criticality of the server.

EVENT COLLECTOR CONFIGURATION

First of all, Windows Event Collector service and WinRM service should be enabled from the command line by using wecutil qc and winrm qc commands respectively.

 After this step, Event Viewer is launched and a new Subscription should be created by right clicking on Subscriptions menu item and selecting Create Subscription or selecting from the menu on the right.

Once the Create Subscription window opens, for source initiated subscriptions settings are configured as below.  These settings largely depend on your own needs however there are real life experiences to follow such as collecting logs in “Hardware Events” destination as logs from this folder are correctly parsed at Arcsight and need no further efforts.

Subscription name: Event collection

Destination log: Hardware Events

Subscription type: Source computer initiated

  

Configuration ends after this step and if there are no problems, like firewall rules blocking the traffic, you should be seeing transferred logs in your target log collection folder. The best way to check if there is a problem or not is to use "Runtime Status" option from the menu on the right.

For more details you can read the Technet article below:

https://msdn.microsoft.com/en-us/library/windows/desktop/bb870973(v=vs.85).aspx

Introduction to Security Event and Log Management

Starting from this article, I will share my experiences and insight on Security Event Management and Log Monitoring. I hope you will find some useful information for yourself in them.

To start with: maybe the most important point to know at the start of a SIEM project is to correctly set the expectations from such project. As very important sums of money and effort are put to these projects, the expectations of several units of your company (not only the IT by the way) may be very high.

So, at the kick-off it is important that you know and make sure that others understand:

• that a SIEM solution is not a big box where different parts of IT throw all their logs until the day they will need it. The importance of “Security” word in SIEM must be underlined. Even though by the very nature of SIEM systems, they are considered as Big Data systems but so far they are only “Big Data like” and maybe they should stay so. Peer Teams in IT should take their time to think which category or type of alerts they have to keep, to find out an anomaly in their own systems or which can be meaningful when it comes together with other piece of information.
•  that sizing is one of the critical steps of SIEM project’s success. A strict sizing in such projects is of course impossible but EPS numbers should be guessed with up to 20% accuracy. After that comes the decision of retention period. Most admins would enjoy seeing what website your colleague in the next cubicle visited a year ago but for an effective forensic analysis, a period from 3 to 6 months is advised to be aimed. A failure in not correctly predicting the storage size may cost you having your critical log data overwritten when you most need it. Not to forget, these numbers are also important for the financials, software licenses and appliances sizes and sometimes even the solution architectures change according to the number of logs to be processed.
• that SIEM projects may be huge and should not be tried to be swallowed at once, your company choke while doing so. A wise approach would be to start with Security and  Network Security systems including but not limited to Firewalls, UTMs, IPSs, VPN boxes, Access Control Systems (Radius, Tacacs+), Web Application Firewalls, DOS protection devices, NACs, Load Balancers, Wireless Controllers and Endpoint Security Systems. After these should follow the Infrastructure components, namely OSs and Middlewares of your critical systems. At the last step, you will finally be ready for integrating your applications, which obviously is the most laborious and time-consuming part as several teams will have to come together and discuss.
• that you should document your project very well. SIEM systems are like those puzzles with thousands of pieces and almost every company cooks that soup to its own taste. The way you collect the logs, reduce them and correlate them largely differs. Without proper documentation, you may have serious problems in roll-outs, troubleshooting and handing it over to somebody else or even outsourcing.
• that even to everybody is into it and the technology is very promising, it is still a reactive solution. It will help your company to discover important breaches, learn from important misconfigurations and mistakes and improve your incident response skills and practices but that is all. Everything still depends on your agile, well-documented and respected incident response procedures… Unless you deploy SIEM as a compliance box or to show off your C-level executives.

      After taking into consideration these important facts, you are ready to start choosing your SIEM product. I will mention about SIEM product selection criteria in my next article, before diving into more detail on implementation.

Perimeter Security Devices Evaluation - Part 1

Firewall (Next Generation Firewall, UTM) Selection Criteria – Part 1

Firewalls and other perimeter defense appliances are the most essential security devices of today's IT infrastructures. Almost all security administrators have their favorite vendor when it comes to the selection of the appropriate device for their environment. I have even seen people supporting vendors and products like supporting a sports team.

I for long times have thought about the criteria to be considered when choosing an appropriate perimeter defense device and this article is the result of it. I am not going to criticise or praise any specific product or vendor, I will just try to give a view of the points that should be considered. One should know that a perimeter device to  be used in an SMB may  (and must) differ from a large enterprise and sectors in which the company operates is another important factor.

So, let’s begin naming those criteria one by one.

Functionality

We all know that the days in which firewalls were used just as IP and port filter ACL devices and session state checkers are over a long ago. Everybody expects more from those devices providing efficiencies in many terms starting by cost and efforts.

But how far should a firewall go with functionalities?

Today most firewall products offer additional functionalities such as Intrusion Prevention, Web Content Filtering (Web Proxy), Remote Connectivity Gateway (SSL VPN), Data Loss Prevention, Malware - Spyware Protection, Security Event Management, Endpoint Protection Console Services and Bot Protection. This list may include other functionalities and capabilities according to different vendors but most common ones are these.

While SMBs would like to have all-in-one solutions and they may be right on their approach, special care must be taken at this point. Licensing is the keyword in the selection of many security products and firewalls are no exception to that. SMBs with low information security maturity levels really should not opt in for too many capabilities as it will not serve them that much other than increasing their Operational Expenditure budgets. I believe the key functionalities to be selected as a minimum should be Next Generation Firewall, Intrusion Prevention, Web Proxy and SSL VPN. Administrators should also pay attention to not to put all the functionalities in one box even though they may have cluster configurations.

Leaving security intelligence for several functions to just one vendor is another risk to be aware of.

For larger enterprises, the pros and cons of selecting a multipurpose perimeter security device is more obvious. From one angle having the least number of devices to manage is very important in a time where collecting logs from a big number of different sources is really  a burden for security administrators not even mentioning the cost and licensing advantages.

However, till what moment we can put different functionalities into the same basket.

Vendors all have different hardware designs for their appliances and even one vendor proposes very different products according to the segments. Having multiple functionalities means that a problem in one function may have damaging effects on other functionalities, even though the processes may be isolated the hardware in most cases is not isolated in many vendors (the cost goes higher if hardware isolation exists). You may have to sacrifice certain capabilities in some situations in favor of others, which is really a not desired situation for most people.

Briefly, adding too much in the same basket has its risks and each enterprise should take its decision independently on that subject. In a world where there are really no standard metrics for measuring the computing power of these  appliance, this is the truth security administrators should face.

My experience on this subject is that more and more enterprise should migrate over security products which have hardware isolation for different functionalities starting from separating the management plane from the data plane. I believe many security administrators at least once faced that annoying situation which prevented them to access their devices in case of a serious problem just because data plane is too busy and consuming all the resources. In today's world resource exhaustion attacks are still a major issue to be resolved and until it is resolved processing cycles must be allocated and consumed very very carefully.

No matter what the size of the company some functions should be very carefully thought of in the selection process. In a company where data classification scheme, data roles (owner, custodian, user, etc.) and responsibilities are not clear Data Loss Prevention functionality should not be added to the list. Basic clear text filtering options are present in most of the products present in the market and can be used for basic needs, whenever needed.

Choosing Endpoint Protection Management functionality on the appliance may be wise if you have an enterprise up to 50 employees. From that number on, it is wiser to use a separate system for such a need than consuming very precious resources which may be attributed to more important security functions.

Final observation on perimeter security devices is the Next Generation Firewall capabilities which may be resumed basically to application (including applets and modules) recognition and domain integration (user recognition). These are the musts of such appliances in today's world and must not be taken lightly. Even the biggest vendors with considerable market share are performing these functionalities on the paper, which actually means that they are not performing those functionalities in a stable manner or simply just pretend to do it. In many products they say that the appliance recognizes thousands of applications while in fact those thousands of applications consist of different social media modules and old chat programs. The most needed and critical business applications ( ERP, CRM, Database, Productivity suites) are not recognized and they give you no insight about your business critical data flow.

CISSP - Passed exam in 2 months and at the 1st attempt

My journey to get CISSP certification started with my wish to prove my experience and competency on Information Security, almost a year ago.

My first decision was to get CISM certification which by its name is for people who aim to be “Information Security Manager”s. I did my research, adhered to ISACA and the local chapter and ordered the book. Once the book in hand I was very enthusiastic to get to know what is inside the book and my first disappointment dates back that moment. It was a book of 250 pages, very dry and not really for a person coming from a technical background. During the first week, my record was 4 pages before sleeping on the book and that for 6 days on a row. Plus after that week I almost retained nothing from what I read that far, so I decided to take things a bit easier.

When sharing my experiences with a colleague, he told me about CISSP which seemed to be a more complete program both covering the technical aspects of Information Security and Information Security Management. When I read more about CISSP, I was convinced that giving CISSP the first chance would be a better idea and I very slowly started reading about it.

An interesting series of events made me leave the company I was working for, creating the ideal environment for me to spend more time on my personal development, including the certifications for which I was really not able to spare time and focus. So I started studying seriously for CISSP by the beginning of March 2014.

At the beginning finding the correct resources to study was very important. There are tons of resources both for studying and for practice tests and if you are like me which means if you always want to be 150% sure of what you are doing, that may be very confusing. Techexams.Net Forum on CISSP was a great place to follow as many people who were about to pass the exam and who already passed it share their experiences, creating a very nice community. I would definitely suggest you to follow that forum if you need guidance or a second opinion (even if you do not need anything, go and read! :) )

After reading people’s comments, I decided to use the famous All in one (AIO) 6th Edition book from Shon Harris to study. Many people find that book overly detailed, dry and containing bad humor (I personally would not be that harsh) but like it or not, the book explains everything you need for CISSP easy enough for a 5 years old (That’s the way I like it, that’s a shame but I assume). I can even say that although many people insist that the best resource for CISSP is naturally the ISC²’s Official Guide, the bible of CISSP is the AIO book. You can definitely count on it and use solely that book to pass the exam… If only you have too much time and that much of interest in detail, which I did not have (both).

At that moment Eric Conrad’s CISSP Study Guide 2^nd Edition came as a life saver, which is half the pages AIO makes and a lot easier to read with very nice examples (I will never forget the example about Object Oriented Programming concepts thanks to that perfect example). That book helped me to cover all of the 10 domains in a month.

So by the beginning of April, I was finally able to test myself with practice tests covering questions from all domains to give me an overall opinion, which also encouraged me to take some full length practice tests in a very short period. So basically what I have done during April was to do a full length test per day at least and then evaluate the wrong answers to understand why I was mistaken. Surprisingly from the beginning till the end no matter what test engine I used I was constantly getting scores in 79% and 81% range. By mid-April, I was confident enough to schedule the test for the last week of April or the first week of May. Some domains were really tough for me because I did not have specific work experience on those domains (Almost nobody can have I believe) and the reasoning behind some choices was not logical and clear. You will also meet such situations quite often. My advice is to listen to yourself built from your proper real life experiences and  the voice of common sense in such situations, instead of what book A or book B says (There are surprisingly many points that they disagree, that’s also why using more than 2 books is distracting and confusing).

Be careful about selecting the date and the test center because as in my situation, you make your plans to take the exam next week without doing any arrangements (of course doing arrangements is a bit scary, exam costs 520 euros or USD, that is nothing to joke) and find out that the only test center in your city is fully booked for next 2 months.

So finally made up my mind and booked the test in the nearest city for the first week of May. No matter how much you study, after reading the experiences of many different people with totally different experiences and background, without taking the exam once, you will never be sure enough.

Many people who took the exam say having the managerial (high level) mindset dealing with the questions is essential and most of the questions are long and scenario based…I do respect them but that is not what I think. First of all, in my short working experience of 10 years, I have never seen a manager interested with such level of technical details; most of the stuff in the exam are very technical indeed. And secondly, to my opinion scenario based questions are not like what you have seen in AIO book, very short and easy to get ones and only cover very limited part of the exam, so relax.

Finally I went to the nearest city (500 kms away) and entered the exam. At the end of 20 questions, I already knew that I was going to pass because it was not that much different from what I have seen in practice tests. I was already thinking about my blog entry about passing the exam during the exam, which I would not suggest to anyone :). It took me 4 hours to answer 250 questions in one round and 30 more minutes to revise 25 flagged questions, including the breaks. One’s ability to handle questions greatly decrease along the exam, in the last 30 questions or so, I remember myself reading the same short question 3 or 4 times. If your proctor is not an annoying person, take a break of at least 5 minutes for every hour. What I mentioned is even more valid for those whose native language is not English. Time to answer a question literally increases exponentially. My right eye was f..ked off after carefully staring at the screen for almost 5 hours and I still had 5 hours to drive back to home at night.

So to resume, if someone asked me a prescription for passing the exam I would say:

Read

1. AIO 6^th Edition from Shon Harris (Do all the tests in the book)
2. CISSP Study Guide 2^nd Edition from Eric Conrad (Again do all the tests)

Study

Equivalent of 150 hours including the reading sessions at least in dedicated mode (another clue :) )

Practice

1. Software included in AIO book (Total Tester, the best resource IMHO)
2. Eric Conrad’s 2 Free Full Length Tests
3. Cccure.org’s paid practice tests (Just because every else does it IMHO)
4. McGraw Hill’s free practice tests

Know

Cornerstone concepts that one sees everywhere and every day such as Business Impact Analysis, System Development Life Cycle, BCP/DRP, Incident Response Plan, Risk Analysis and Assessment. Do not memorize the steps but know the flow, the logical order.

Don’t

Memorize the Orange Book levels :)

I wish all of you good luck in your quests to pass the exam and I will definitely keep my blog live with Information Security related article which can be useful for CISSP preparation.