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

Operation Aurora

Operation Aurora is a cyber attack which began in mid-2009 and continued through December 2009.^[1] The attack was first publicly disclosed by Google on January 12, 2010, in a blog post.^[2] In the blog post, Google said the attack originated in China.

The attack has been aimed at dozens of other organizations, of which Adobe Systems,^[3] Juniper Networks^[4] and Rackspace^[5] have publicly confirmed that they were targeted. According to media reports, Yahoo, Symantec, Northrop Grumman and Dow Chemical^[6] were also among the targets.

As a result of the attack, Google stated in its blog that it plans to operate a completely uncensored version of its search engine in China "within the law, if at all", and acknowledged that if this is not possible it may leave China and close its Chinese offices.^[2] Official Chinese media responded stating that the incident is part of a U.S. government conspiracy.^[7]

The attack was named "Operation Aurora" by Dmitri Alperovitch, Vice President of Threat Research at cyber security company McAfee. Research by McAfee Labs discovered that “Aurora” was part of the file path on the attacker’s machine that was included in two of the malware binaries McAfee said were associated with the attack. "We believe the name was the internal name the attacker(s) gave to this operation," McAfee Chief Technology Officer George Kurtz said in a blog post.^[8]

According to McAfee, the primary goal of the attack was to gain access to and potentially modify source code repositories at these high tech, security and defense contractor companies. “[The SCMs] were wide open,” says Dmitri Alperovitch, McAfee’s vice president for threat research. “No one ever thought about securing them, yet these were the crown jewels of most of these companies in many ways — much more valuable than any financial or personally identifiable data that they may have and spend so much time and effort protecting."^[9]

Source: Wikipedia

Forget ROI and risk. Consider competitive advantage

1. "ROI-centric discussion"

Security person: Hello boss. We need to implement our security program because it has a ROI of $1 million dollars.
Boss: You mean if we adopt your program we're going to earn $1 million dollars?
Security person: No, we'll save $1 million.
Boss: Get out of my office. Come back after you've taken a finance class.

---

2. "Risk-centric discussion"

Security person: Hello boss. We need to implement our security program because I've calculated our risk to be 1.35.
Boss: What does that mean?
Security guy: Hmm, ok I'll leave now.

---

3. "Competitiveness discussion"

Security person: Hello boss. We need to implement our security program because it will provide a competitive advantage to our businesses.
Boss: That's a new one. Tell me more.
Security person: We have adversaries who try to steal, and sometimes do steal, our data.
Boss: So what. Isn't it just World of Warcraft credentials?
Security person: Our adversaries steal intellectual property like design plans, pricing data, negotiation strategies, and other information which means they might understand our business as well as we do.
Boss: Is that true? You mean we could lose deals because our products are copied, our bids undercut, our positions already known? I wonder if that's why we lost a deal to MegaCorp last month...
Security person: Now that you mention it, here is a report on suspicious computer activity involving MegaCorp last week. Our team managed to interdict their theft attempt, but in the future we'd like to be able to detect and respond faster, as well as make it more difficult for the adversary to have a chance to steal our information.
Boss: Now you're talking. Sit down, let's discuss this.

---

"Notice what happened here. Magazines written for CIOs, CTOs, CISOs, and so on constantly advocate "speaking the language of the business." Unfortunately this "language" has been assumed to be finance. As a result security people tried to shoehorn their projects into ROI or ROSI, to laughable results.

As we've seen during the last few years, "risk" has turned out to be a dead end too. The numbers mean nothing. Even if you could somehow measure risk, it's easy enough for managers to accept a higher level of risk than the security manager.

Competitiveness, on the other hand, is everything to business people. They are constantly looking for an edge. It a tight economy, gaining an advantage over the competition could mean the difference between thriving or going out of business.

Notice that discussing competitiveness also avoids the death spiral associated with ROI discussions: cost. When conversation is ROI-centric, digital security is perceived as being a loss prevention exercise and a cost center. IT in general is often seen in this light. Don't dump money in a cost center -- cut spending instead!

When you turn the focus on the adversary -- you are threat-centric -- and discuss how he is trying to beat you and how you can beat him, you are likely to strike a primal chord in the mind of the business person. The executive is likely to wonder "what else can we do to give us a competitive advantage?" Suddenly the digital security shop is seen as a business partner in a common fight with the competition, not a cost center dragging down the "productive" elements of the business.

This isn't a new idea, but it's largely absent in the mindshare of digital security professionals. (If anyone has an ACM account I'd like to read Using information security to achieve competitive advantage by Charles Cresson Wood, 1991.) In addition to mentioning ROI and risk, it's important to remember that compliance is the other driver that is likely to justify funding. However, I believe we are more likely to see security shops spending resources explaining why their current activities meet regulatory requirements. I doubt new programs are going to be created to meet compliance needs, since compliance is basically a ten-year-old justification at this point."

- source taosecurity

Advice for Academic Researchers

Quoted from TaoSecurity Blog's

A blog and book reader emailed the following question:

I am an info sec undergrad and have been granted a scholarship to continue my studies towards a phd with the promise of DoD service at the other end. It is critical for me to research and select the most important area of security from the Defense Department's perspective.

My question to you is this: Drawing upon your knowledge, what specific area(s) of information security do you feel will be most critical in the next several years (especially in the eyes of the Dept. of Defense)?

I post this question because I'm sure blog readers will contribute interesting comments.

For my part, I'm really interested in the following: characterizing network traffic. In other words, develop tools and techniques to describe what is happening on the network. (I'm sure a few commercial vendors think they are doing this already, but nothing approaches the level that we really need.)

Without understanding what is happening, we can't decide if the activity is normal, suspicious, or malicious. Current approaches are far too primitive and limited. This work is not as "shiny" as developing a new detection algorithm, but getting back to basics is the sort of approach that could survive in a research environment.