Application Security Monitoring

I found the following quote by Microsoft's Ray Ozzie, in The Web 2.0 World According to Ozzie, to be fascinating:

"In terms of managing trust boundaries, one of the huge challenges that enterprises are going to have is...managing trust between components of composite applications...

"We believe there should be significant auditing within service components—such that when you do expose a partner to certain enterprise data...you have a complete record of the kinds of things that their app did." (emphasis added)

I think Mr. Ozzie is advocating application security monitoring, a cousin of network security monitoring. If Mr. Ozzie is being as clever as I think he might be, he's realizing that it's going to be nearly impossible to run Web services and the like "securely." We're going to have to rely on monitoring and response since prevention will be far too complex. Resistance will be tried, but will be -- you guessed -- futile.

Read More

Thoughts on Gates Security Memo

While reading Gary McGraw's great book Software Security, I had a chance to re-read the famous Bill Gates security memo of January 2002. I wasn't blogging back then, so I didn't record my reaction to it. Almost five years later, the following excerpt struck me:

[E]ven more important than any of these new capabilities is the fact that it is designed from the ground up to deliver Trustworthy Computing. What I mean by this is that customers will always be able to rely on these systems to be available and to secure their information. Trustworthy Computing is computing that is as available, reliable and secure as electricity, water services and telephony.

Today, in the developed world, we do not worry about electricity and water services being available. With telephony, we rely both on its availability and its security for conducting highly confidential business transactions without worrying that information about who we call or what we say will be compromised. Computing falls well short of this, ranging from the individual user who isn't willing to add a new application because it might destabilize their system, to a corporation that moves slowly to embrace e-business because today's platforms don't make the grade. (emphasis added)

Hold the phone (no pun intended). "[A]vailable, reliable and secure as electricity, water services and telephony"? You mean the solid electricity system that blacked out the northeast US in 2003? Or the two water pipes running into New York City that could be disrupted or poisoned? Or the telephone system owned by the Phone Masters in the late 1990s or spied upon by three letter agenices in this decade?

I propose that the main reason that electricity, water, and telephony are (wrongly) considered "secure" is the fewer number of threats facing them. Networked digital resources are exposed to far greater numbers of threats than analog resources like electrical power plants, water treatment facilities, and telephone closets. This is changing as all of these analog resources are being controlled by IP-enabled systems with global reachability.

This makes me wonder if digital security is being held to a higher, possibly impossible, standard. Is there any other system in the world that could be accessed by any threat, at any time? This is not a wise-guy question -- I'd appreciate your thoughts on this. What sorts of man-made systems are relentlessly under attack by intelligent adversaries? I'm adding intelligence here to remove comparisons to diseases, weather, earthquakes, and so on.

The first system that came to mind was the modern casino. People are always trying to cheat, so the threat level is high. A variety of financial systems come to mind, although I'm trying to avoid systems with close ties to digital functionality. Physical security probably has a few useful lessons.

What do you think?

Read More

Thoughts on Software Assurance

Last night I attended a talk at my local ISSA chapter. The speaker was Joe Jarzombek, Director for Software Assurance for the National Cyber Security Division of the Department of Homeland Security. Mr Jarzombek began his talk by pointing out the proposed DHS reorganization creates an Assistant Secretary for Cyber Security and Telecommunications working for the Under Secretary for Preparedness.

This is supposed to be an improvement over the previous job held by Amit Yoran, where he lead the National Cyber Security Division, under the Information Analysis and Infrastructure Protection Directorate. According to this story, "Yoran had reported to Robert P. Liscouski, assistant secretary for infrastructure protection, and was not responsible for telecommunication networks, which are the backbone of the Internet." Mr Jarzombek said that people who are not Assistant Secretaries are "not invited to the table" on serious matters.

Turning to the main points of his presentation, Mr Jarzombek said the government worries about "subversions of the software supply chain" by developers who are not "exercising a minimum level of responsible practice." He claimed that "business intelligence is being acquired because companies are not aware of their supply chains."

The government wants to "strengthen operational resiliency" by "building trust into the software acquired and used by the government and critical infrastructure." To that end, software assurance is supposed to incorporate "trustworthiness, predictable execution, and conformance." Mr Jarzombek wants developers to "stop making avoidable mistakes." He also wants those operating critical infrastructure to realize that "if software is not secure, it's not safe. If software can be changed remotely by an intruder, it's not reliable." Apparently infrastructure provides think in terms of safety and reliability, but believe security is "someone else's problem."

I applaud Mr Jarzombek's work in this area, but I think the problem set is too difficult. For example, the government appears to worry about two separate problems. First they are concerned that poor programming practices will introduce vulnerabilities. To address this issue Mr Jarzombek and associates promote a huge variety of standards that are supposed to "raise the bar" for software development. To me this sounds like the argument for certification and accreditation (C&A). Millions of dollars and thousands of hours are spent on C&A, and C&A levels are used to assess security. In reality C&A is a 20-year-old paperwork exercise that does not yield improved security. The only real way to measure security is to track the numbers and types of compromise over time, and try to see that number decrease.

Second, the government is worried about rogue developers (often overseas and outsourced) introducing back doors into critical code. No amount of paperwork is going to stop this group. Whatever DHS and friends produces will be widely distributed in the hopes of encouraging its adoption. This means rogue developers can code around the checks performed by DHS diagnostic software. Even if given the entire source code to a project, skilled rogue developers can obfuscate their additions.

In my opinion the government spends way too much time on the vulnerability aspect of the risk equation. Remember risk = threat X vulnerability X asset/impact/cost/etc. Instead of devoting so much effort to vulnerabilities, I think the government should divert resources to deterring and prosecuting threats.

Consider the "defense" of a city from thieves. Do city officials devote huge amounts of resources to shoring up doors, windows, locks, and so forth on citizen homes? That problem is too large, and thieves would find other ways to steal anyway. Instead, police deter crime when possible and catch thieves who do manage to steal property. Of course "proactive" measures to prevent crime are preferred, so the police work with property owners to make improvements to homes and businesses where possible.

I asked Mr Jarzombek a question along these lines. He essentially said the threat problem is too difficult to address, so the government concentrates on vulnerabilities. That's not much of an answer, since his approach has to defend all of the nation's targets. My threat-based approach focuses on deterring and capturing the much smaller groups of real threats.

Mr Jarzombek then said that the government does pursue threats, but he "can't talk about that." Why not? I understand he and others can't reveal operational details, but why not say "Federal, state and local law enforcement are watching carefully and we will have zero tolerance for these kinds of crimes." Someone actually said those words, but not about attacking infrastructure. These words were spoken by Alberto Gonzales, US Attorney General, with respect to Katrina phishers.

This approach would have more effect against domestic intruders, since foreign governments would not be scared by threat of prosecution. However, if foreign groups knew we would pursue them with means other than law enforcement, we might be able to deter some of their activities. At the very least we could devote more resources to intelligence and infiltration, thereby learning about groups attacking infrastructure and preventing damaging attacks.

Since I'm discussing software assurance, I found a few interesting sites hosted by Fortify Software. The Taxonomy of Coding Errors that Affect Security looks very cool. The Fortify Extra is a newsletter, which among other features includes a "Who's Winning in the Press?" count of "good guy" and "bad guy" citations. This site is not yet live, but in October DHS will launch buildsecurityin.us-cert.gov. The Center for National Software Studies was mentioned last night.

Also, the 2nd Annual US OWASP Conference will be held in Gaithersburg, MD 11-12 October 2005.

Read More

Thoughts on Web Application Security Consortium

Rather than post to his own blog, Aaron Higbee decided to bait me with a link to the Web Application Security Consortium's Web Security Threat Classification guide. Uh oh, there's that magic word -- "threat." Immediately I suspected this document's use of the word "threat" in the title might be problematic, as I doubted it would be a classification of the parties with the capabilities and intentions to exploit vulnerabilities in assets.

The document description states "The Web Security Threat Classification is a cooperative effort to clarify and organize the threats to the security of a web site. The members of the Web Application Security Consortium have created this project to develop and promote industry standard terminology for describing these issues. Application developers, security professionals, software vendors, and compliance auditors will have the ability to access a consistent language for web security related issues."

That sounds to me like an open invitation for a debate on their language!

Before you get too cross with me, note that I was pleasantly surprised to see most of the content correctly framed as "attacks." Other content was not labelled correctly. Here are a few examples, which I will let you assess before I suggest an alternative way of looking at these issues.

1. A Brute Force attack is an automated process of trial and error used to guess a person's username, password, credit-card number or cryptographic key.


2. Insufficient Authentication occurs when a web site permits an attacker to access sensitive content or functionality without having to properly authenticate.


3. Weak Password Recovery Validation is when a web site permits an attacker to illegally obtain, change or recover another user's password.


4. Credential/Session Prediction is a method of hijacking or impersonating a web site user.

Can you guess which terms are vulnerabilities, and which are attacks? The attacks are easy; they are 1 and 4. The document authors correctly call number 1 an "attack" in its description. The vulnerabilities are items 2 and 3. These are easy to spot, too. The document authors didn't want to call these conditions vulnerabilities, so they bailed out by using the phrases "occurs when" and "is when". This is a sure sign that the term is not an attack, but is something else. Here are the other vulnerabilities in the document, listed as "attacks":

1. Insufficient Authorization is when a web site permits access to sensitive content or functionality that should require increased access control restrictions.


2. Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization.


3. Automatic directory listing/indexing is a web server function that lists all of the files within a requested directory if the normal base file is not present.


4. Information Leakage is when a web site reveals sensitive data, such as developer comments or error messages, which may aid an attacker in exploiting the system.


5. Insufficient Anti-automation is when a web site permits an attacker to automate a process that should only be performed manually.


6. Insufficient Process Validation is when a web site permits an attacker to bypass or circumvent the intended flow control of an application.

So, that's a great list. Add those six items and the earlier two and you have eight total vulnerabilities. At this point I would recommend breaking the document into two sections: (1) Vulnerabilities and (2) Attacks. The document itself should be renamed the Web Vulnerability and Attack Classification Guide.

If you think for a moment you can even pair attacks properly labelled in the document with the relabelled vulnerabilities above. Consider item two in this second list -- Insufficient Session Expiration. Its extended description says

"Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization. Insufficient Session Expiration increases a web site's exposure to attacks that steal or impersonate other users."

Notice the term "exposure"? That's a vulnerability that can be exploited by the following attacks listed in the guide:

• Session Fixation is an attack technique that forces a user's session ID to an explicit value. [me: like old session credentials?]


• Credential/Session Prediction is a method of hijacking or impersonating a web site user. [me: by predicting old session credentials?]


• Abuse of Functionality is an attack technique that uses a web site's own features and functionality to consume, defraud, or circumvents access controls mechanisms. [me: like insufficient session expiration?]

So there you go Aaron. I've probably angered twenty-odd more security professionals by debating their security classification program. (At least I know Mike Shema on that list, and he owes me for leaving to attend a concert during an incident response!) I'm hoping that this quote from Pete Lindstrom (who recently emailed with a link to his blog) is accurate:

"'The need for consistent technical terminology for web related security issues has a significant impact on risk assessment and remediation activities,' Pete Lindstrom, research director of Spire Security, said in a statement Monday. 'Establishing a standard approach for identifying these issues, along with a common terminology that everyone can adhere to, will help to thwart the increasing security risks associated with Web applications.'"

I would also say the Web Application Security Consortium's Distributed Open Proxy Honeypots (aka "proxypot") is an awesome idea. Again, I have no issue with the technical work by these groups, as they far outweigh anything I have done in those fields. However, I would be very happy to see industry-wide consistency in core security terms.

Read More