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.
Overview:
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.

Sunday, September 23, 2012

Hotmail limits passwords length

According to threatpost, Microsoft web mail service - Hotmail - has put a limitation on users maximum password length. It is observed that the passwords longer than 16 characters are not accepted. The amazing point is that there is a claim that the first 16 characters of old long passwords is accepted as the new password! This may lead to the conclusion that Hotmail passwords has not been more than 16 chars from the first day! Or one may think that Hotmail stores the passwords in plain text instead of storing password hashes ...

Thursday, August 23, 2012

Tools for windows security

Performing a security test on windows servers requires the use of several tools. Sysinternals security tools are a set of useful tools that help improve the speed and quality of the white box security assessments. Dumpwin is another favorite tools of mine that enables you to collect system and security related information.   

Tuesday, August 14, 2012

Blogging on the go

I am beginning to use the android app "blogger" on my tablet and hope to be here more than the past.

Saturday, March 17, 2012

Best security blogs of RSA 2012


I wanted to list here the best security weblogs that are selected by the RSA 2012. Some of my favorite ones are also selected: 
Best Corporate Security Blog:

Fortinet Security Blog http://blog.fortinet.com/
Trend Micro Cloud Security Blog http://cloudsecurity.trendmicro.com/
Veracode Security Blog http://www.veracode.com/blog/
Kaspersky Lab Blog https://www.securelist.com/en/
Sophos Naked Security Blog http://nakedsecurity.sophos.com/

Best Security Podcast

Threat Post http://threatpost.com/en_us/podcast The Network Security Podcast http://netsecpodcast.com/
The Southern Fried Security Podcast http://www.southernfriedsecurity.com/

The Most Educational Security Blog
The New School Security Blog http://newschoolsecurity.com/

The Most Entertaining Security Blog

Andrew Hay's Blog http://www.andrewhay.ca/
Uncommon Sense Security/Jack Daniel http://blog.uncommonsensesecurity.com/
New School Of Information Security/Adam Shostack http://newschoolsecurity.com/
Securosis Blog http://securosis.com/blog

The Blog That Best Represents The Security Industry

Krebs On Security http://krebsonsecurity.com/
Uncommon Sense Security http://blog.uncommonsensesecurity.com/
SANS Internet Storm Center http://isc.sans.org/

Wednesday, February 22, 2012

Man-in-the-Browser Attack

The idea of Man-in-the-Browser attack is similar to the traditional Man-in-the-Middle (MITM) one, where a malicious third party sits between the client and the server and intercepts the traffic. But it can be more dangerous because of the position of the malware: inside the victim's system, acting like a legal process, that helps the malware get access to the abstractions of the application layer easier than MITM. That is how trojans like Zeus manipulate online banking transactions and perform unauthorized transactions.       

Friday, February 3, 2012

Learning Web App. Penetration Test

I was browsing some security blogs, and I saw this great post introducing a set of vulnerable web applications available for learning purpose. I am familiar with the OWASP broken web apps collection, and the following table from securitythoughts will help to select the next candidates to test.

S.No.Vulnerable ApplicationPlatform
1SPI Dynamics (live)ASP
2Cenzic (live)PHP
3Watchfire (live)ASPX
4Acunetix 1 (live)PHP
5Acunetix 2 (live)ASP
6Acunetix 3 (live)ASP.Net
7PCTechtips Challenge (live)
8Damn Vulnerable Web ApplicationPHP/MySQL
9MutillidaePHP
10The Butterfly Security ProjectPHP
11Hacme CasinoRuby on Rails
12Hacme Bank 2.0ASP.NET (2.0)
13Updated HackmeBankASP.NET (2.0)
14Hacme BooksJ2EE
15Hacme TravelC++ (application client-server)
16Hacme ShippingColdFusion MX 7, MySQL
17OWASP WebGoatJAVA
18OWASP VicnumPHP, Perl
19OWASP InsecureWebAppJAVA
20OWASP SiteGeneratorASP.NET
21Moth
22Stanford SecuriBenchJAVA
23SecuriBench MicroJAVA
24BadStorePerl(CGI)
25WebMaven/Buggy Bank (very old)
26EnigmaGroup (live)
27XSS Encoding Skills – x5s (Casaba Watcher)
28Google – Gruyere (live) (previously Jarlsberg)
29Exploit- DBMulti-platform
30The Bodgeit StoreJSP
31LampSecurityPHP
32hackxorPerl(CGI)
33OWASP – HackademicPHP
34Exploit.co.il-WAPHP