legal contact rss
 

Fight againt Phase 3

This is the first act of many to protect againt the ACTUAL ATTACK.

THe most important lesson I've learned are below three steps:

    1. Patch your systems
    2. Patch your systems
    3. Patch your systems

A patched system is strong enough to face an attack. - Although there are 0Days in the field, imagine you're being compromised by someone using the MS08-067 to hijack your server.

To find your weak systems, run vuln. scans weekly and convince your admins of patching the weak servers. - Breaking into the system yourself by using the existing gap's, is an excellent prove of your arguments. 

 

A basic rule

If you don't need a service, stop and deactivate it.

This helps your server by not waisting CPU cycles on a services nobody uses AND helps your security team, to lower the available attack surface.

The same thing for the whole server by the way. I can't remember how often I've heard the phrase "this should have been switched off long time ago". - So check youre environment and system owners regulary, if they really need every machine.

Again, the vuln scan (or "nmap [-o|-so]") will help you to find outdated operating systems and services.

 

The human factor

Unfortunately, you can have the best patched and secured system in the world, if the people using it are not training in security, it's all worth nothing.

Best example is the hack of the Deutschen Bundestag. - By sending some spear phishing emails, the attackers got hold of the complete network with all it's users and servers by creating a "golden ticket".

So train your employes and make them aware of the very basics of security.

Running own phising attacks will be a very good way of motivation and understanding. But have training bevore AND after the campain for the guys.

 

Anomaly detection

This is still (very much) under construction. Although a lot of information of this section is already available, I still haven't finished yet. - So please be patient and come back a little later. THX

How to find anomalies in your data and logfiles.

Splunk:

An easy way to be done with Splunk's "predict" function.

Below is an analysis for http traffic seen on a FW/proxy.

sourcetype=syslog device_id="xxxxxxxxxx" log_component=HTTP| timechart span=1m count(dst_ip) as distinct_count | predict distinct_count | rename upper95(prediction(distinct_count)) as ceiling | rename lower95(prediction(distinct_count)) as floor | eval excession=if(distinct_count > ceiling, "100", "0") | eval recession=if(distinct_count < floor, "-100", "0")

The intresting part is the excession line that shows intresting traffic, worth further investigations.

Below is an analysis for IDS (snort-id) traffic seen on a FW.

sourcetype=xxx srcip=* | `ids_enhance`| search NOT (at_action=xxxx OR at_action=xxxx) | fillnull value="N.A." | timechart span=15m count(at_filter2) as distinct_count | predict distinct_count | rename upper95(prediction(distinct_count)) as ceiling | rename lower95(prediction(distinct_count)) as floor | eval excession=if(distinct_count > ceiling, "100", "0") | eval recession=if(distinct_count < floor, "-100", "0")

Working version. IDS data taken and computed a new priority based on the severity of the SID, the reputation of the "outside" asset and the priority of the "inside" asset. (done in my ids_enhance macro.

sourcetype=xxxx srcip=* | fillnull sid value="N.A." | `ids_enhance` | timechart span=30m count(adjusted_priority) as distinct_count | predict distinct_count |rename upper95(prediction(distinct_count)) as ceiling | rename lower95(prediction(distinct_count)) as floor | eval excession=if(distinct_count > ceiling, "100", "0") | eval recession=if(distinct_count < floor, "-100", "0")

 

More reading:

http://info.prelert.com/products/anomaly-detective

http://www-users.cs.umn.edu/~kumar/dmbook/dmslides/chap10_anomaly_detection.pdf

https://en.wikipedia.org/wiki/Anomaly_detection

http://alumni.cs.ucr.edu/~wli/Anomaly0.5/AnomalyDetection.html