Monday, October 29, 2012

Do you really need an SIEM?

One of the major tasks of an information security group is to monitor the status of the systems, devices, etc. from a security perspective. Traditionally, IT systems were expected to generate log records according to different standards and best practices. Log management, including the maintenance, storage and analyzing log data has been widely known as a security requirement for  IT systems. In recent years, with the growth of Security Event Management (SEM) systems, more companies are going to deploy SIEMs. But a common mistake here is that the SIEM can/should be used as the alternative to a log management solution. Therefore, some companies that are not matured in terms of log management and security monitoring also decide to use SIEM. I always try to explain the case for such companies, and to convince them not to do so. 
The SIEM related posts by Dr. Anton Chuvakin in his personal blog are strongly recommended.       

Monday, October 22, 2012

Log management: centralized or non-central solutions?

Big organisations often use security devices of various brands. Maintaining and management of generated logs of theses devices is an important task for security monitoring. In a recent case, I was asked by an organisation whether they should buy the log analyzer appliance of a specific brand, which they had decided to buy two UTMs from. The organisation have some log analyzer appliances installed in the network. Also the products of the same brand may bring more compatibility and ease of use, the benefits of centralized logging and reporting should not be forgotten.         

Sunday, October 21, 2012

MMPC Threat Report: Rootkits

Microsoft Malware Protection Center (MMPC) has published a short threat report on rootkits.
This Microsoft Malware Protection Center (MMPC) Threat Report examines one of the more insidious types of malware threatening organizations and individuals today — the rootkit. The report examines how attackers use rootkits, and how rootkits function on affected computers. The report describes some of the more prevalent malware families that use rootkit functionality in the wild today, before presenting some recommendations that can help organizations mitigate the risk from rootkits.

Friday, October 5, 2012

Estimating possible collisions of SHA-1

In a recent post, bruce schneier reprinted an analysis made by Jesse Walker (Skein team member) about the time needed to see a practical collision for SHA-1. It was interesting for me the way the writer goes through the calculations:

According to E-BASH, the cost of one block of a SHA-1 operation on already deployed commodity microprocessors is about 214 cycles. If Stevens' attack of 260 SHA-1 operations serves as the baseline, then finding a collision costs about 214 * 260 ~ 274 cycles.
A core today provides about 231 cycles/sec; the state of the art is 8 = 23 cores per processor for a total of 23 * 231 = 234 cycles/sec. A server typically has 4 processors, increasing the total to 22 * 234 = 236 cycles/sec. Since there are about 225 sec/year, this means one server delivers about 225 * 236 = 261 cycles per year, which we can call a "server year."
There is ample evidence that Moore's law will continue through the mid 2020s. Hence the number of doublings in processor power we can expect between now and 2021 is:
3/1.5 = 2 times by 2015 (3 = 2015 - 2012)
6/1.5 = 4 times by 2018 (6 = 2018 - 2012)
9/1.5 = 6 times by 2021 (9 = 2021 - 2012)
So a commodity server year should be about:
261 cycles/year in 2012
22 * 261 = 263 cycles/year by 2015
24 * 261 = 265 cycles/year by 2018
26 * 261 = 267 cycles/year by 2021
Therefore, on commodity hardware, Stevens' attack should cost approximately:
274 / 261 = 213 server years in 2012
274 / 263 = 211 server years by 2015
274 / 265 = 29 server years by 2018
274 / 267 = 27 server years by 2021
Today Amazon rents compute time on commodity servers for about $0.04 / hour ~ $350 /year. Assume compute rental fees remain fixed while server capacity keeps pace with Moore's law. Then, since log2(350) ~ 8.4 the cost of the attack will be approximately:
213 * 28.4 = 221.4 ~ $2.77M in 2012
211 * 28.4 = 219.4 ~ $700K by 2015
29 * 28.4 = 217.4 ~ $173K by 2018
27 * 28.4 = 215.4 ~ $43K by 2021
A collision attack is therefore well within the range of what an organized crime syndicate can practically budget by 2018, and a university research project by 2021.
Since this argument only takes into account commodity hardware and not instruction set improvements (e.g., ARM 8 specifies a SHA-1 instruction), other commodity computing devices with even greater processing power (e.g., GPUs), and custom hardware, the need to transition from SHA-1 for collision resistance functions is probably more urgent than this back-of-the-envelope analysis suggests.