Archive for September, 2012

Symantec DLP vs. Websense DLP - my opinion

Wednesday, September 5th, 2012

From my experiences of both the DLP technologies, below is a quick comparison table that I have come up with. Please share anything else that I might have not yet covered.

Comparision of DLP technologies - Symantec DLP vs Websense DLP

Comparison of DLP technologies - Symantec DLP vs Websense DLP

Good read for understanding Malware and how it works….

Wednesday, September 5th, 2012

I happened to meet a friend of mine Wyman Stocks (wymanstocks.com) and he was relating his experience of Malware and how malware attacks can be understood and analyzed. Once we understand how malware attacks are performed, we can mitigate or avoid these attacks. The following diagram is a good start. Scroll down below for more information.

Cyber Kill Chain

Cyber Kill Chain

Here are some interesting reads:

a. http://papers.rohanamin.com/wp-content/uploads/papers.rohanamin.com/2011/08/iciw2011.pdf

b. http://www.digitalbond.com/2011/11/22/applying-the-cyber-kill-chain-to-ics-part-1/

c. http://www.digitalbond.com/2011/11/29/applying-the-cyber-kill-chain-to-ics-part-2/

d. http://www.cs.cmu.edu/~scenariograph/sheynerthesis.pdf

Companies like Lockheed Martin are standing behind these initiatives - do  you know such concepts that you are intrigued? Please let us know.

Malware: Top 5 reasons and what you must know

Tuesday, September 4th, 2012

Our computer system is now similar to our body. Our body has certain weaknesses or vulnerabilities and you fix them by increasing your immunity. Similarly, our computer systems have weaknesses. What are the top few weaknesses or vulnerabilities and how do you fix them?

The top 5 vulnerabilities (or reasons) for the most infamous malware exposure (aka. malware attacks to happen) in 2012 are below. These are not necessarily in the order of vulnerabilities and these are based on my experience on SIEM and the root cause analysis of what led to the malware exposure. These might change as malware writers gets more sophisticated or malware reverse engineers moves more faster to fix them

  1. Java JRE
  2. Adobe Flash
  3. Adobe Reader
  4. Apple Quicktime - yeah, who would have guessed this?
  5. Microsoft Office
For the most part, the above 5 applications act as a host for external bodies similar to viral or bacterial attacks on our body.
How do we fix them?
We patch the above applications regularly with the most recent patches from the above applications. These patches will fix “buffer overflow” type language level vulnerabilities to ‘man in the middle’ type handshaking vulnerabilities - I know I have oversimplified here but this is just to give you some idea what these patches do.
In summary, malware is like bacteria or virus around us - its not fair to say, we can get rid of them however, we can reduce their existence. Similarly, we can reduce the existence of malware.

Hire More People OR Deploy Tools?

Tuesday, September 4th, 2012

A bit of background here before we get into the discussion here: the top 5 reasons for malware exposure (aka. malware attacks to happen) are below. These are not necessarily in the order of highest exposure.

  1. Java JRE
  2. Adobe Flash
  3. Adobe Reader
  4. Apple Quicktime
  5. Microsoft Office

We recently got into an intriguing discussion within IT Management. When we were discussing the time / cost of fixing the spambots / malware and how to avoid this spending, we arrived at 2 options in front of us

Reactive Option: Fix them as we detect them with tools such as SIEM, IDS/IPS, etc.

Proactive Option: Deploy a tool that mandates systems with patches and patches those new systems (including BYOD) with patches

It got even more interesting as we tried to see if these are really options (pick one of the above) or needs (do both). Furthermore, our internal study showed (although preliminary and the population size is not big enough to substantiate as a thumb-rule), that over 60% of the malware was detected after 90 days of the known attack date and in essence

a. the patching would have fixed a majority of malware attacks if the patches did fix what they said they would

b. the patching would also have reduced the long dragging malware exposures which meant that the cost was long dragging and spent incrementally

In other words, in theory, if we deployed a tool to automate patching, we would have potentially reduced the incremental and long dragging costs.

The management asked me the question “Given that this is an incremental cost and not a one time investment (to deploy tools), why not just keep the incremental cost approach?”. In other words, they were leaning towards hiring more people offshore and deal (reactive response) rather than investing money into patching tools / similar to avoid attacks (pro-active response)

I may not necessarily agree with this decision however, this is right now the viable solution. What do you think?