Ayoi’s

Finally I have one machine (old one but I think can do the job btw) to run sguil. Because I dun have the luxury of having many machines (it will take quite a loooooooooooooooooooooooong time to get one btw) so I have the sguil server and sensor installed in that *cough testing *cough machine. Managed to savaged the RAM from other unwanted machines (pc133 RAM is lil bit difficult to find here).

lil bit info of the machine:

FreeBSD sguil.mss 6.2-RELEASE-p2 FreeBSD 6.2-RELEASE-p2 #0: Tue Feb 27 22:41:06 UTC 2007

Intel(R) Pentium(R) 4 CPU 1.50GHz (1523.56-MHz 686-class CPU)
real memory  = 805306368 (768 MB)
avail memory = 778682368 (742 MB)

Filesystem        Size          Used   Avail       Capacity    Mounted on
/dev/ad0s1a    496M     36M    420M          8%                /
devfs                 1.0K         1.0K      0B            100%           /dev
/dev/ad3s1d     36G       16K     33G             0%               /nsm
/dev/ad0s1e     33G       1.2G    30G             4%              /usr
/dev/ad0s1d    1.7G       39M    1.5G             2%             /var
For time being, I only plan to deploy this machine to monitor our SOC network only. Hmm I do need another machine to be placed in front of our firewall as well. Initially I plan just to use the data gathered by our internal and external sensor but after second, third and fourth thought I think better for me to request one manageable switch to mirror all the traffic to the sguil. I just don’t want to answer many queries later.

The purpose of this machine :

1). Actually to see the size required to store full content data, at least one day’s worth.

2). The data collected will be used in my training that I have to conduct later.

3). To introduce the usage of all the data collected by sguil in validating/investigating incidents or suspicious traffic to the analyst at the SOC. I might call it NSM awareness.

4).  Perhaps we can do some data mining and traffic threat analysis

5). For Attack and Defense project. Our pen tester will run/scan/brute force any exploits or 0-dayz exploit developed by our TSS team on a machine or machines placed in the SOC. We will try to detect this activities (some of it will not be triggered by IDS, so the ability and knowledge to do traffic analysis will be beneficial).

6). To compare the detection / data collection mechanism with our current SIEM. Perhaps in the future we can integrate the session and full content data collection besides only alerts and devices logs.

7). Needed for my so called white paper.

Actually there’re thousands reasons why I want my sguil deployed. But those above are the main factors. Maybe sguil will be used in the SOC later or maybe not or maybe we finally realized that those data are important.

p/s: I just realized that the time stamp on my sguil-client is not correct. While the clock on my windows  taskbar shows 10:39 AM, the time shown at the Sguil-client is 01:29. But after doing some minor adjustment to the SguilUtil.tcl, everything solved and the time is shown correctly.

This is what I do :

C:\sguil-client-0.6.1\sguil-0.6.1\client\lib\SguilUtil.tcl (I just edit the file using wordpad)

Just change from true to false (-gmt true –> -gmt false)

# GetCurrentTimeStamp: Returns date/time in YYYYY-MM-DD HH:MM:SS.
#
proc GetCurrentTimeStamp { {clockOption {today} } } {
set timestamp [clock format [clock scan "$clockOption"] -gmt true -f “%Y-%m-%d %T”]
return $timestamp
}
proc GetCurrentTimeStamp { {clockOption {today} } } {
set timestamp [clock format [clock scan "$clockOption"] -gmt false -f “%Y-%m-%d %T”]
return $timestamp
}

p/ss: I still believe a knowledgeable analyst still needed in detecting incidents. Nothing can beat human intuition, instinct and judgement. I wish we do have the fully automated super SIEM/SEM but I dun think it will happen. Human intervention will always be needed.

Comments RSS