SECURITY METRICS - Attack Surface Metrics

Operational security metrics are the metrics we are most familiar with in our lives. When we measure the height, width, or length of an object we are using an operational metric. When we write the date, have a birthday, or ask the score of a game we are using operational metrics. An operational metric is a constant measurement that informs us of a factual count in relation to the physical world we live in.

They are operational because they are numbers we can work with consistently from day to day and person to person. It is difficult to work with relative or inconsistent measurements like choosing a specific hue of yellow to paint a room, starting work at sunrise, having the right flavor of strawberry for a milkshake, or preparing for the next threat to affect your organization’s profits because the factors have many variables which are biased or frequently changing between people, regions, customs, and locations.

For this reason, many professions attempt to standardize such things like flavors, colors, and work hours. This is done through reductionism, a process of finding the elements of such things and building them up from there by quantifying those elements. This way, colors become frequencies, work hours become hours and minutes, flavors become chemical compounds, and an attack surface becomes porosity, controls, and limitations. So we can now quantify the attack surface as "ravs".

Details at ISECOM

PHP Security Course

PHP Security Course – Advanced PHP Auditing at Source and Bytecode level

Two weeks after the Month of PHP Security closes Stefan Esser will teach an advanced PHP security course at the SyScan Singapore security conference.

The course will cover advanced methods and techniques for PHP applications audits at source code and at bytecode level. The students will get to know the most common PHP security problems and how to find them at source code and bytecode level. Throughout the course several free and open source software tools will be introduced and used in order to visualize application structure, find security problems with static and dynamic analysis on source code and bytecode level and also to break PHP bytecode encryption.

THC and The Nokia Rom Images

THC and The Nokia Rom Images - 2006-09-06

In mid july Nokia charged THC with copyright infringement and threatened with a lawsuit. THC took down thc.org to prevent further cost and a legal disaster.

A month earlier THC discovered significant security flaws in Nokia's Operating System. To proof it THC published ROM images of 3 phones. THC did not publish the source code or tools but one thing became apparent: To extract the ROM images core security features had to be breached. THC's ability to load kernel modules and gain access to the core of the OS (including the GSM stack) was something Nokia did not like.

At the time of the release THC was not aware of any copyright protected material inside the roms. The question has to be asked if Nokia chosed the right method by threatening THC with a lawsuit or if an email could have achieved the same. Was their concern really copyright infringement? The software in the rom-images could not be used, not be ported and not be run on any other mobile phone. In addition all software is already available on every phone. Phones that are given away by the mobile operators for 1 Euro or sometimes even for free. So if everyone has access to the software anyway what is the point in threatening THC? What was their real intend? We might never find out. But what we know is that they managed to silence THC for a month.

If this is professional practice? We do not know. It is certainly the practice that Nokia chose. We also know that no attempt was made by Nokia to inquire about the security vulnerability. We also know that Nokia did not provide any updates for their customers.

Making sure that the hardware we purchase is secure is not a crime. In fact taking a look at what we buy should be our duty. We should not trust big corporates who claim in TV advertisements how secure and safe our data is. We have to test it and proof them wrong whenever we can.

In fact researchers should demand that manufactures like Nokia must provide full documentation of their hardware. The buyer becomes the owner of the mobile phone and thus has the right to know how to program the hardware. Nokia does not provide any of such information. Free software or a different operating system can not be used because of limited access to documentation. This is a classic example of a hardware giant allowing only his own software to be used. This is what some people would consider a Monopoly and an abuse of power.

THC is deeply concerned that Nokia did not choose the diplomatic route.

Source: http://freeworld.thc.org/thc-rom/

Something to quote

"Software is like sex. It's better when it's free." -- Linus Torvalds
"A chain is only as strong as its weakest link." -- Charles A. Lindberg
"I have seen the fnords." -- Historical graffiti on Anarchy Bridge, UK
"Testing can prove the presence of bugs, but not their absence." -- E. Dijkstra
"Hi, my name is Pete and I'm an OSSTMM user." -- Pete Herzog
"The GNU people aren't evil." -- /usr/src/linux/Documentation/CodingStyle
"There are always errors in real data." -- The AWK Programming Language
"When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl." -- Anonymous