We can’t tackle the “process improvement” problem with our open source provides like we can with those who build our software in-house, or those vendors from whom we acquire code.

Understanding, based on this, we lack as many ‘knobs and dials’ for improving the cleanliness of the pipes through which open source software flows… we may have a flow rate problem as well. Though I lack hard evidence, I’d bet this represents a proverbial iceberg’s tip:

An organization may deploy as much or more open source code as their own in-house developed code.

It’s interesting to think about the money organizations spend to secure the code they build vs. the amount of open source they consume in this light… (participants indicated they didn’t track this spend separate from their development efforts).

Harumph. Our breakout group generated great ideas worth sharing. First, we unearthed a lot of things attending organizations already do. Next, we brainstormed valuable next steps. Here’s categories of activities we came up with:

• Inventory & Inventory Control


• Vulnerability Identification (Assessment)


• Vulnerability Management


• Ownership of Open Source


• Policy (use)


• Policy (Contribution)

What did each entail?

Inventory & Inventory Control

• Identification – All Participating organizations had a manual discovery process for open source usage. Many wanted better automated schemes, despite some existing tool usage.
• Identification of masked open source – Many participating organizations realize that not only do they adopt open source software directly but that the 3rd party code (and open source) they absorb also contain open source software. Discovering this ‘masked open source’ software represents as big a problem as identifying the open source software used directly.
• Centralized open source distribution – Some organizations allow development & deployment of open source software from the web directly whereas others only allow access to and use of open source from a centrally managed repository. Centralizing deployment usage may provide only improved integrity, or may be used to implement an ‘approved package list’.

Vulnerability Identification (Assessment)

• Using assessment tools – About three-quarters of workshop respondents used the same tools they use to assess their application security posture on their open source assets. This, to me, seems worth its own blog entry. I had to wonder aloud, “as organizations move from detective assessment schemes (SCR, PT) to so-called preventative (threat modeling, architecture analysis, misuse/abuse cases) how do they consider open source?” I’m finding that organizations blazing trails into security architecture work commonly omit discussion of their open source frameworks.

Ownership

• Maintain a white list of open source – Seemingly related to the “centralized distribution” item (but surprisingly uncorrelated in our survey), this meant that someone, from security, owned assessing the risk and proffering a “thumbs-up” or “thumbs-down” that can inhibit white list membership.


• Revisit white list – Organizations expressed that they found value in pruning the approved list of open source software based on non-use, newly identified risk, and similar factors. About one-quarter of our group engaged in this activity.


• Ownership of identified risk – Some participants avidly encouraged use of open source within their applications. In these organizations, when a developer chooses to include open source (as opposed to writing a widget themselves), they own any newly identified risk when in that open source. This reminded me eerily of Wall St. traders. Equity investment creates risk. Margin calls create leveraged risk. In this metaphor, choosing to adopt open source seems like a margin call. It’s very possible that a developer can absorb more risk into the organization than they themselves could effectively own up to in black-swan scenarios. It’s unclear how to measure this exposure when adopting open source.
• Collaboration – Certainly an organization-specific and an unsolved problem, participants indicated there may be a “third stakeholder” in the process of identifying and managing open source vulnerability. Two examples given were 1) clearing houses from which organizations purchase open source software and 2) support organizations (a la RedHat).

Vulnerability Management

• Root Cause Analysis – When a vulnerability is found (regardless of means or source: internal/external), organizations sometimes can point to a person or group who understands the vulnerable component (notable exceptions exist for purchased software or that software maintained by a development team that’s vanished). In open source, the organization must expend resources in order to “get smart” on vulnerability’s root cause and make trade-offs about mitigation strategies and their impacts. This represents extra cost on which I’d enjoy having greater visibility.


• Vulnerability Impact Analysis – Almost every participant had some regime by which they discovered (through assessment, feeds, or other means) new vulnerabilities within their adopted open source code base. Everybody possessed some ability to figure out which lines-of-business or development teams might be affected by newly discovered vulnerabilities.


• Patch Management – Only about one half of participants had, in their minds, a good strategy–having assessed the impacted teams–for distributing a patch that remediated open source vulnerability in an organization-wide manner. More strategically, several schemes seemed available to organizations beyond the straightforward “penetrate-and-patch” loop here. Alternatives included:
  
  
  1. Wrapping open source
     
  2. Hardening open source (and centrally distributing)
     
  3. Sandboxing/compartmentalizing open source
     
  
  

Policy (Use)

• Security Policy/Standards – About half participants had some kind of security policy or standards addressing how to securely use open source software within the organization.
• Training – About one quarter of participants trained their developers to use some portion of their open source securely. Interestingly enough, the one quarter of our respondents that trained developers did not line up well with the one half that had security standards. Wild.

Policy (Contribution)

• Legal permission to contribute to open source – Some organizations see open source contribution as a key activity. Others did but have suffered clamp-down from their legal departments because legal fears liability. Others never liked the idea.
• Community Notification on Vulnerability – When an organization contributes to open source and later finds (or is notified of) vulnerability in its contributions, it may need a way to notify the broader community. Organizations also complained about very high latency in the community notifying them of vulnerability in their code. This proved a surprising problem in our brainstorming session. Why? Contributors complained that this was because, often, their contributions were either 1) forked or 2) baked into other products that masked use of the contributions. In either case, it wasn’t evident to those disclosing the vulnerability that the (contributing) organization was responsibly for vulnerable code.

I will absolutely not let it go without saying that though this entry contains many of my own thoughts it heavily relies on the work of many in our breakout session, well-lead by HP’s Brian Chess. Thanks all for a great discussion.
-jOHN

A clear evolutionary path for the family of security toolkits lies ahead. In order to achieve broader adoption and greater effect in larger enterprises the project’s participants must focus not just on API-level design but also on what I’ve dubbed enterprise readiness. Enterprise readiness entails:

• Centrally managed development road map
• Predictably periodic release schedule
• Increased modularity and reduced dependencies
• Adopter-centric documentation
• Stated backward compatibility
• Integration with scanning technologies, demonstrating correct usage

Interestingly, the project in current release form already addresses some of the above items. Users’ complaints prescribe an upgrade-even if that entails only more prominent communication of existing resources.

Road Map
Since 2008, the project underwent a multiple management changes. Now firmly in the hands of individuals focused on secure development, it’s time to form a steering committee or other community process that results in the creation of a single shared direction for all involved parties. Organizations need to know not only what ESAPI represents today but also what it wants to address and offer in the next 12-36 months.

Release Schedule
The 2.0 GA release accomplished much but suffered from a changing and delayed schedule. In order to reliably fit into organizations’ own release plans adopters must be able to rely on a release schedule for their own planning purposes.

It would be helpful if development efforts published and adhered to a “software development lifecycle”, regardless of how agile. Why? Such a move would demonstrate maturity and would help individuals from adopting organizations follow and predict progress against schedule releases.

Pushing features to release compels security folk by deflecting criticism and reducing adopters’ risk. However, from the adopting organizations’ perspective, it creates work. Even if they don’t adopt new releases immediately, it forces information-gathering and decision work. Predictability outranks both feature progress and frequency of releases.

Modularity
Tinkerers and serious adopters complain that a large list of dependencies creates undue collisions and conflicts, complicating both adoption and maintenance. Splitting each language’s code base up (call that better componentization, modularization, or <whatever>) should help address that problem. Truly upgrading existing tightly coupled elements into a la carte modules will require comprehensive refactoring, dramatic changes in dependency choice, and clever use of namespaces and dynamic loading (Spring-style dependency-injection has already been discussed).

Because modularity produces not only its intrinsic benefits but also clarifies subsequent road map definition and reduces risk in release schedule planning, I count pursuit of this goal as the task of paramount importance. Chris hopes to schedule a modularization tiger team shortly.

Documentation
When one [successfully] adopts a particular implementation, what security problems should they expect to no longer find in assessments? What steps will adoption require? How much effort does customization, integration, and implementation entail? Increasing enterprise readiness requires user-centric documentation.

• Define a threat model, scoping toolkit objectives/effect
• Outline user stories, indicating workflow support (and addressed misuse/abuse)
• Produce adoption guide, enumerating steps acquiring organizations need to successfully adopt and implement a security API

Summit participants rightly concluded that early adopters can best help close these documentation gaps based on their own experiences. Later, more specific ‘specification’ of toolkit function can follow.

Backward Compatibility
Throughout its evolution, the toolkit’s implementers balanced backwards compatibility with progress. However, one of the first “user comments” at the summit was, “We need backward compatibility.” This represents the prime example of need for better (perhaps more formal?) communication.

Scanning Tool Support
Finally, getting credit drives good behavior. Providing organizations “rule packs” for static and dynamic assessment tools that show alleviated risk from toolkit use should increase adoption. Updating leading commercially-produced SAST products (or SaaS) with rules that remove findings where provided security functionality effectively mitigates risk requires more thought than existing first-pass “ESAPI rule packs” incorporate.

Contributors must carefully consider the level such rules should target. Yes, unit testing shows quality of the toolkit’s implementation itself, but does not demonstrate correct integration of the toolkit with an application. Toolkit contributors, unfortunately, can not produce a generic parametrized system-level security test either demonstrating adopting applications bear no vulnerability.

Conclusion
Summit participants showed support across this broad set of suggestions and discussed each item in relative depth. Now, the objective will be to follow-through on each without loosing momentum.

One possible facilitator could, of course, be private funding. Such funding could facilitate several factors of enterprise readiness simultaneously by 1) defining a road map, 2) proposing, funding, and therefore guaranteeing a work schedule, and 3) narrowing focus to a particular aspect of (increased) modularity (or documentation). Excitement regarding the possibility of both accelerating and focusing progress caused me to blog about the Interaction Model in my last post.

In the meantime, as summit members return home to day jobs and dig themselves out from under inevitable mounds of e-mail and TODOs, I reflect on the possibility of the ESAPI project with renewed interest.

1. Integration with standard-fare open source and commercial middleware commonly used to deploy organizations’ web-apps (e.g. CA SiteMinder, MQ-Series, Documentum, etc.)
2. Greater predictability (and later maturity) in asset delivery road maps and schedule
3. Complete and user-centric documentation regarding adoption, implementation, and configuration
4. Progress against existing asset gaps deemed barriers to adoption by an organization

Jeff Williams and I collaborated on a Straw Man Partnership Model that describes ways for organizations to interact with OWASP.

As describe above here, the “buyer” (an organizational stakeholder) drives interaction. For this, I posit a buyer-driven work flow (see figure below)

(Buyer-driven workflow available: here )

Summarizing, the buyer coordinates with the OWASP project owner (either directly, or through a partner such as Cigital), determines things like: level of effort (LoE), division of responsibilities, and what will ultimately be shared. The producer then works with OWASP project team resources to hit scheduling and roadmap sign-posts.

If you’re interested in helping your organization with benefiting from open source projects, perhaps I can help there. If you’re interested in helping mature the projects themselves, I can definitely help–especially with OWASP ESAPI or cheat sheets. I’m also very interested in feedback on the whole partnership model. Please send mail.

To address this concern in conversations conducted as part of the OWASP Threat Modeling project, I worked with Cigital’s Sammy Migues to construct a Glossary of Threat Modeling Terms. Sammy has long been a proponent of such approaches to glossaries: sticking firmly to nouns as nodes and relating those nodes with action verb edges. See figure below:

Please feel free to download and use Glossary of Threat Modeling Terms stored as a Google Doc. (*1)

As you consider the terms and their relationships in this diagram, you may wonder about how/why we sourced what we did when defining terms. We used the following heuristics:

• Favor the earliest definition known


• Allow a more recent definition to update or color a previous definition, especially with respect to application security context


• Do not allow a more recent definition to change direction without having been journal (or similarly peer-review) accepted


• Favor software development and especially architecture sources over security sources

The definitions provided by the OWASP wiki, in particular, fail that third heuristic a fair amount, while often providing the second’s benefit.

As for “why”, perhaps it’s Sammy’s pedigree combined with my years in research and doing both magazine and journal review for IEEE. You’re instructed for better or worse, that there must be a good reason to replace an existing definition. Comparing the published result with Cigital’s internal docs, source material differs considerably. A lot of our internal material on threat modeling relies on work from decades ago. ISACA material, most commonly used in the diagram above, applies more directly to a context of web-applications (remember, the glossary was done for an OWASP project) than ours, which must face a much broader assessment context. Additionally favoring existing externally available documentation, especially from an architecture context such as ISACA, serves to create a better chance for engaging those who we most want in a application security threat modeling discussion: architects, development teams, and development-centric organizations.

The biggest complaint with the glossary thus far has been with regard to its handling of “risk”. Basically, risk management remains largely out of scope of this glossary of terms, which instead chooses to focus on threat, attack surface, and vulnerability enumeration. Yes, analysis of likelihood (whatever that means) and impact are vitally important aspects of threat modeling. These two concepts, however, tend to be organization-/philosophy-specific. As such, they remain out of scope of this series of blog entries as well.

All that having been said, I meant the glossary to be a “worksheet” rather than “the 10 Commandments”. So, I think we have something to start with, improve, and evolve. Feel free to refer back to this either in your own work or as you read coming entries.

-jOHN

(*1) – If you’d like OS X or Windows “source code” to this diagram, simply email me.

Cigital has always favored delivery of holistic assessments (those assessments that consider architecture/design as well as code, leveraging static & dynamic tools, and using both tool-assisted and manual techniques). During my tenure as Director of Security, we found the following distribution of findings:

• Static tool: 20%


• Dynamic tool: 5% (*1)


• Manual SCR: 15%


• Architecture Risk Analysis: 60%

Those numbers may surprise and demand some explanation. For instance, though Microsoft at one point reported 50% of their findings were “flaws”, Cigital was finding 60% (on average, with as much as 70%) of its issues as ‘flaws’. If anything, our classification of ‘flaw’ was less inclusive though, and at the time I looked into this, I concluded that our larger percentage could be due to technique, focus on architecture in methodology (LoE), or level of customer familiarity/maturity with the tech-stack they developed on.

Likewise, our process started with a “whitebox” triage then shifted to exploratory testing (aka: dynamic) rather than the other way around (which I find common elsewhere) and that order-of-operations probably moved balance from dynamic to static. So, in practice we “found” vulnerabilities statically and then supported those findings with dynamic tests to validate their exploit-ability and impact (though perhaps dissatisfying, static gets the point in our data set here).

Slicing by technique
Our experience made it pretty evident to us: skip assessment techniques and expect to miss some critical vulnerabilities.

Slicing by vulnerability type
As I’ve mentioned in previous blog entries and mailing list posts, security managers need the capability to assess and report on their ability to find particular classes of security vulnerability as well. WASC’s Web Application Security Statistics provide a starting point for both classes of attacks you might expect to find and their probability. There’s no shortage of vulnerability taxonomy work out there, so we’ll leave this topic at this superficial level.

Optimizing a Security Practice
Whether you know what percentage of your reported findings come from each assessment technique, or you’re just starting to build your assessment practice, optimization (measurement, analysis, iterative improvement) should be a goal. To do this we combine our knowledge of the techniques we’re employing and the enumeration of vulnerabilities we want to find and report.

Confined to the context of static analysis, I described the following loop in a previous blog post to do just that:

• Use a representative sample of your applications to observe a static analysis tool’s performance, not a contrived test suite.
• Consider the tool’s findings relative to pen-testing findings on the same app.
• Did new and interesting findings result?
• Did pen-testing findings found by the static tool provide adequate root-cause analysis and remediation advice to fix problems earlier?
• How long did it take to on-board an app? How will this scale to your portfolio of apps?
• How long did it take to triage the results? How will this scale?

The purpose of this trial experimentation was to provide some basic comparison between assessment techniques (though you could easily come up with a more thorough approach). Of course, you’d want to consider findings from the perspective of all techniques, not just static tools.

Internally, we had our assessment lab managers write up a qualitative comparison of assessment techniques we employ, comparing how well each is “suited” to finding vulnerabilities against common vulnerability taxonomies (*2) and came up with the following:

• ARA: 14%


• Static tool: 12%


• Manual SCR: 21%


• Manual Pen: 21%


• Dynamic Tool: 12%


• Sec Testing: 20%

At this point, the reader may be asking why my experience differs from our lab managers’. Specifically, for instance, “why are dynamic techniques over-estimated here as compared to to historical findings rates?” Two reasons (at least) come to mind:

1. The balance of techniques that constitute our assessments are “moving back” towards dynamic as software-under-test and market forces evolve


2. There’s a difference between how suited a technique is to discover something and how we choose to find it (I guarantee that in some circumstances this gap represent ‘optimization opportunities’, while in others it represents explicit technology or methodological choices).
   

The Caveat You’ve Come to Expect From Me
Whether your considering a vendor’s assessment service, an assessment standard, or your own internal assessment practice, it’s key to be able to detect biases. When others supply you assessment data you’ll likely uncover biases (though it may not be apparent to those reporting initially). Be careful, I doubt you’ll be able to compile, combine, or relate numbers you receive from varying sources for this reason.

If you’re compiling assessment data for the purpose of motivating practice improvement, you may want to either 1) extract universal similarities from the data you get and present those lessons learned to management, or 2) just list the others’ experience separately. This can provide those to whom you’re presenting a compelling view to your perspective on differing assessment approaches.

In fact, many factors will muck up assessment comparison. For instance, when people report a percentage (like I did above), did they mean finding instances, findings, by type, or something else (*3)? What was their methodology, level-of-effort, and how did they conduct assessment. For instance, risk-based assessments produce a very different distribution (with wider variation) than time-boxed techniques, which more frequently drive to an explicit (or worse, implicit) checklist.

One thing universally seems true though: the more assessment techniques a software security practice makes use of, the more types of vulnerabilities it can expect to report.

-jOHN

(*1) – Clarification: our use of dynamic tools is human-assisted (both in terms of crawl and in follow-up with manual effort or leveraging internally developed tools).

(*2) – WASC, OWASP Top 10, CWE Top 25

(*3) – My data is comprised of reported vulnerabilities. Answering questions about what risk-level I reported requires some abstraction as clients differ in their requirements there. Likewise, behavior regarding instances vs. buckets of ‘related vulns’ requires addl. explanation.

In his post he discusses the need to consider the cost of things in terms of the opportunity lost by doing them:

“Jim Rogers has a great practice on saving – when you think of buying something today, simply multiply its cost by twenty to see how much it will be worth down the road when you are retired. A dinner out is “only” $75, but would you still go out to eat if you figured the cost at $1,500? Warren Buffett pithily sums this up as – do I really need a $300,000 haircut?”

Indeed.

What about the reverse? As a security manager, please ask yourself,

“What am I not doing incrementally that I’m going to regret having made no progress on in the future?”

Today, as I look back on complaining about the dynamism of Java EE applications, I could kick myself for not spending a few hours each week building scanning technology to address these issues. Bygones.

What about you? Run an assessment practice? Couldn’t you just kick yourself for not spending a few hours each week:

• Measuring what vulnerabilities you found, and what techniques paid off to find them?


• Measuring which finds were fixed and which most frequently resulted in regression?

How about those of you working with developers and security toolkits? Couldn’t you just kick yourself for not spending a few hours each week:

• Collecting the ‘best examples’ of validation code from your reviews?


• Writing a security widget to encode output for a particularly popular context?

Just as the future cost of (even seemingly small) wasted expense today can be staggering, the regret for not addressing daunting problems with an almost negligible amortized effort can be staggering later.

What can you start addressing incrementally now?

So, why talk about false positives in the first place? Well, tool adopters I correspond with unilaterally indicated that “dealing with false positives” was their big challenge. I thought, “Address the pain directly.”

However, this is not strictly how I went about it with more savvy folk. Instead, we focused on positively identifying those vulnerabilities we could easily verify as needing fixed. This may sound like two sides of the same coin–and to some extent it is: reducing false positives reduces the pile of hay in which one must look for needles.

However, other techniques bore just as much (or more) fruit. We successfully tuned through other means such as:

1. Adding scanning capability (sometimes custom rules, sometimes custom scanners) for vulnerabilities that always slipped by source code review but for which testing verified existance.


2. Separating and promoting those vulnerabilities that take more time/effort to verify with testing alone


3. Plainly removing those rules that produced inaccurate results easily found by testing *gasp*


4. Discussing pain-points with operations staff: what weaknesses attributable to source code were they constantly chasing in production?

This tuning scheme is very myopic: fixating on assessment. That is, it focuses on the relative effort associated with various different security assessment activities. It ignores broader risk management factors (discover-ability, probability of exploit, and impact) and remediation factors (effort to fix, regression rate, etc.).

Advanced practices use all these factors to tune. But, organizations without risk management practice or development relationships can use these assessment-driven measures to drive improvement without external dependencies today.

Expect more on the topic of “Focusing on what to fix” from me.

In the software development circles I travel, the topic of adding a mobile channel onto existing application/system infrastructure has come up a bunch recently. With regards to threat modeling a ‘move to mobile’ represents an ideal opportunity to revisit threat modeling. Remember, I don’t necessarily prescribe threat modeling for well-known system arch-types (such as classic n-tier) and technology stacks as much as when teams attempt new and lesser known architectures.

The natural question: how do my threats change when I bring a mobile channel into my existing application? Consider, for instance, a generic application, as depicted below:

Existing Application w/ New Mobile Channel

This application supported a User and CSR through a browser interface, and had other connections to RESTful services in its middle tier. Now, we’ve added more controller and presentation tier logic, perhaps opting to reuse almost all the former application’s model. In this case, the new functionality aims to provide a more numerous set of users (2-4X as many as the plain browser interface) access to their accounts and services but with considerably lower bandwidth. The intent is that a sub-set of services would be offered (rate comparison and ACH transfer being omitted) and all available services will be provided in a crisp, simple, and responsive format.

Since we’ve discussed this example (and many like it) in threat modeling classes, we’ll leave these users and threats to the original system alone for now.

New portions of the system, being constructed to support mobile, are depicted in blue. In a future post, we’ll discuss how to more clearly identify the change in attack surface due to these additions. For now, let’s just consider the new Threats themselves. Again:

Threat – A class of individuals or software agent executing on behalf of such an individual

When we model threats we describe a threat’s capabilities, level of access, and skills to start. Let’s apply a few of Threat Modeling techniques to identify new threats to consider.

1. Consider the system’s users
When teams add new functionality to a system, or when they start a new development effort entirely, they commonly create user stories or perhaps even detailed use cases and requirements.

The first (and easiest) way to identify new threats to the system is to mine user stories, use cases, and other usage documentation (even marketectures often work) for their users. Then, consider:

• What evil or insidious behaviors could a user engage in?
• What obnoxious or stupid behaviors could a user cause trouble with?

Two users come to mind as we look at proposed new mobile functionality:

1. Mobile device user (in this case, a smart phone)
2. Neighboring network user

Combining the first items from our two lists above, we come to our first threat: a malicious mobile device user.

1. Malicious Mobile Device User – Device users possess the credentials to the device (including any UI, ‘app store’, or other username/password tuples) and likely possess the carrier account/credentials. Access includes physical access to the device and use of both of its applications and browsers. This threat can install applications, sync, and explore device contents with their computer. Of course, this threat has access to device SDK and simulators as any developer would. See this threat depicted in the figure above with label “1″.

When we discuss attack surfaces, we’ll discuss what kinds of access and capabilities these threats possess in a technology-specific fashion. Some conceptual actions include:

• Transfer device contents to computer for debugging, reversing, etc.


• Install purpose-built (malicious) applications on device


• Manipulate application settings, set up a proxy for web interaction, etc.


• Use both browser and application to access the same services/resources


• Jailbreak device

Consider Evil/Insidious User Action
The last behavior piques particular interest. When the user decides, with malicious intention, to jailbreak their device, additional malicious behaviors are available to them. Regardless of whether or not the jailbreak was motivated by malicious intent, the device’s security controls are compromised. In this case, applications can no longer trust that security features such as application signing apply or that a confidential path for their data exists between the application and network. Documenting threats in a traceability matrix allows one to show this escalation of privilege from one threat to another directly:

In summary, this behavior gives rise to another class of threat:

2. Malicious Mobile Device – This threat has all the capabilities and access of a malicious mobile device user, but can also compromise or augment the device OS and its drivers. The figure above depicts this threat labeling it “4″.

A broad range of capabilities results from this opportunity and if a device is compromised prior to the a victim application being loaded, malicious behavior can observe and affect the application installation process itself, or user signup/registration processes–which may include initial credential/key material exchange. This imagined scenario may quickly turn an application’s entire security proposition into a house of cards.

Consider Obnoxious/Stupid User Action
Once you start, it’s hard not to imagine a multitude of stupid things a user could do with their mobile device. Let’s focus on a common and important one: the user could leave the device somewhere, for it to be stolen. This scenario has two effects: first, this dramatically increases the population of Threat #1: malicious device user. Let’s split this threat into 1.A (previously described) and 1.B: malicious device user (same as 1.A but without the user’s credentials). However, Threat 1.B also increases the population of Threat #2–malicious devices because thieves can jailbreak devices even without user credentials.

An important third scenario impacts certain applications, like the generic one we describe above. If our threat traceability matrix (above) was filled out during a previous secure design exercise, it might include “password reset” use described in the mitigation column. Indeed, during many threat modeling courses jOHN teaches his participants indicate “we can remove the malicious CSR threat entirely by doing password reset out-of-band using a mobile phone.”

In the case that a phone is stolen and possesses the bank’s MobileBankingApp, perhaps which caches the user’s name, how effective is this control?

Many password reset implementations jOHN observes (using his accounts) suffer full compromise under the ‘stolen phone’ scenario. In this case, the identification of a new threat causes us to reconsider or augment the design of our system so that it again demonstrates the security properties we desire.

A Brief Diversion into the Mobile Threat Population
Looking superficially at search results, it appears as though ~120,000 phones are stolen in the UK annually; ~200,000 in Australia. Another site indicated 26M phones are stolen annually and resold. Regardless of how accurate these numbers are, this represents a much larger threat population than expected from security researchers and nefarious parties alone.

Not Stolen, “Something Borrowed”

Consider more generally the notion of the device being “out of sight” interaction briefly, perhaps through the following vectors:

• Because stolen (unknown to the device’s user) and returned after being tampered with


• The device is plugged into another individual’s machine (perhaps for charging or for app download)


• Device lent to individual for momentary use (phone call, game demo, contact/weather lookup)


• Grey-market phone, donated phones, recycled/returned phones

Each of these cases exposes the whole of the device’s attack surface to exploitation without visual cues to the phone’s user.

And Who ‘Owns’ These Devices Anyways

This is perhaps a good time to point out that the phone’s user may not be the phone’s owner. Family and corporate phone plans often provide access to the phone, remotely, unbeknownst to the user. In these cases, the phone’s owner must be considered a (yet unpictured in our diagram) threat from the user’s perspective.

From the phone (or account) owner’s perspective, the user represents a similar threat: the user can potentially add/modify/remove software without visual cues or notification. Our ‘single-user’ device actually serves multiple masters:

1. Me


2. The Account Owner


3. Our Benevolent Dictators: Google/Apple… RIM/Microsoft?


4. Carriers: ATT, VeriZon…


5. Device Manufacturer

We know the benevolent dictators retain the right/capability to remove applications from our devices. What other capabilities must an application publisher be concerned about within their Threat Model?

Here in the diagram, you see the inevitable separation of the application store curator and the current set of benevolent dictators listed–Amazon’s new application store is a prime example.

Reconsider Old Model’s Threats
Having conducted a threat model on the classic n-tier system before, a man-in-the-middle (MiM) threat was undoubtedly considered. Reconsider this threat in terms of the new architecture.

A common mistake modelers make in considering mobile MiM is to forget that devices contain not only applications that make Internet connections but that they also possess browsers:

3. MiM – This threat has access to traffic sent over the Internet (OR carrier network) sent either from the app to server or
vice versa. When a device contains a browser, this threat can see both app to server traffic and browser to server traffic from the same account/device. This threat may be able to see traffic through (active or passive) interposition, or through landing code (script) w/in the device’s browser using classic web attacks (Depicted as Threat #4 in the figure above).

Whether or not one needs to consider both Internet and carrier-based sniffing depends on other factors within the threat model. Cigital has always considered carrier-level compromise part of its mobile threat model, at a low barrier to entry. However, it bears mentioning that as recently as 2004 it was challenge to convince organizations that individuals could “be the mobile network”. It’s somewhat vindicating to see this as a consumer-grade scenario now.

This isn’t the half of it though (and we’re getting ahead of ourselves a little bit in talking about attack surface here, but). Consider the following ‘radio-based’ surfaces on the phone:

1. GSM Stack


2. CDMA Stack


3. 802.11


4. Bluetooth


5. NFC (coming soon to a device near you!!!)

Remember, vulnerability in any of these implementations may cause our user to suffer a “drive-by owning“, leaving him/her with Threat #2: Malicious Device.

Other Old Threat
Taking another cue from former efforts, modelers must consider the possibility that malicious applications will run alongside their applications within a mobile device. This scenario is no different than that of a browser, or any application running on the almost forgotten host computer.

4. Malicious Application – Threat represents either a compromised victim application on the device, a Trojan, or other malware (depicted in the figure above as #3). The causal vector may have been data interpreted and executed by a vulnerable app, a malicious application placed in an app store (or otherwise available for download), or different entirely. Such applications (malicious or corrupted) can attempt to poke and prod at your victim app directly, exploit the underlying device OS, or focus on server resources directly. The malicious app may possess a valid signature (or not, as advantageous) and has access to the device’s services (as per what the user has granted it).

Summary
Hopefully, this thought exercise has shown its reader threats they hadn’t considered. Hopefully it shows the reader the advantages of reconsidering a threat model as the architecture changes through normal means:

1. Start with the users/user-stories


2. Think maliciously


3. Think ‘stupid’


4. Re-consider old threats in the new architecture


5. Understand, you’re not the only device ‘user’, ‘owner’

It continues to surprise me that these techniques pay off even when only threats (the ‘who’) themselves are considered.

Next, we’ll write up how consideration of the attack surface differs as we ‘move to mobile’ and begin to see how this expanded surface can have dramatic implications on the security posture of existing functionality.

you will find our observations regarding static analysis shared by others. It’s encouraging to note that Flash Sheridan observes many of the same difficulties and more formally treats them in his ISSRE ’10 publication. It’s worth a read.

A few commentators shared some decent points I wanted to address in a comment. I’m cross-posting my commentary here:

Comments treating the application of static tools as a distinct (and unfavorable) alternative to “fixing your SDLC” disappoint me, especially from the OWASP community (of which I am a contributing paid member). In fact, the community’s OpenSAMM project actively prescribes use of static analysis in not one but four (4) unique activities. So, both BSIMM and SAMM see static analysis as a part of fixing one’s SDL. **Note that in both models, all activities are not compulsory.

“Fix your code” is another red-herring alternative to static analysis. I believe static analysis inseparable from effective usage of a secure programming toolkit (such as OWASP’s ESAPI or an organization’s own toolkit) because static analysis tools can meet the need for organizations to 1) detect consistent and thorough use of secure APIs (and non-use of dangerous ones) as well as 2) detect incorrect usage of such APIs (whether through broken call-order, un-paired functions, or other bugs). We shouldn’t forget, as Mr. Manico indicates, 3) running static tools on these security toolkits themselves finds problems that careful review may not otherwise have found.

So, secure SDL models indicate usage and we–as a community–see use in these tools in helping remind developers how to correctly build secure code. I think we have to agree static analysis tools find exploitable bugs (even though sometimes in an overly expensive or time-consuming way). So, I think we’re stuck with them as a ‘best practice’ in the short term, however little some of us may like them. To dynamic vendors out there, I’d even go so far as saying, “Early adopters have begun to over-rely on static means to find problems more effectively/efficiently found with dynamic tools. Don’t worry, the ones I’m working with will begin to tilt the balance back using assessment data”.

I would like to put a face-and-name on the key notion that almost all commentators have thus-far touched: the static analysis tool that gets used by a majority of application developers out there, in the future, will likely not look like the ones we have today. And that’s fine too.

Dan Cornell wrote a blog post on static analysis coverage. He observed that while the static tool he used completed its scan, it didn’t find things it should. He implicitly referred to this as coverage.

I’ve often put things as follows:

Your tool can’t find what it can’t see and it can’t see what it doesn’t parse.

This got said often years back because at the time it was quite difficult to integrate tools effectively into a builds so that they would in fact ‘see’ everything and successfully parse it (*1). We referred to this concept of how well we, as operators, had integrated as providing visibility into the code. These days, market leading tools don’t have nearly the problem they used to with finding the code they need to parse… or parsing that code successfully (*2).

These days, the frameworks developers use for persistence, object remoting, application navigation, and view display challenge visibility most. Tools see the code for your controller and parse it successfully but they don’t necessarily understand what it represents. This happens in almost every application I scan, even the painfully simple ones.

We couldn’t have our Consultants going out into the world armed with tools bearing only spotty visibility into applications so I wrote a utility identifyEntryPoints to find entry points on its own. We don’t want Consultants guessing at what their static analysis tool missed or popping the hood open to try to discern what it found and not doing what they’re paid to do: assess the application, so I wrote another utility entryPointCompare to compare what the tool found vs. what I was able to find programmatically. See actual output below (I’ve replaced the static tool’s name with ‘TOOL XXX’):

Sanguine:demo jsteven$ /Users/jsteven/code/demo/working/engine/util/entrypointCompare.py
2011-02-06 09:07:08,158 INFO     bois_1.0        bin.execPythonRobot STARTING: /Users/jsteven/code/demo/working/engine/util/entrypointCompare.py
Factory 31, [TOOL XXX] 0
 TOOL XXX missed set(['Index', 'csrchat', 'accountsList', 'Transfer', 'editProfileFormBean', 'newAccountFormBean', 'fileList', 'Auth', 'newClientFormBean', 'qaFormBean', 'UserProfile', 'SetupProfileAction', 'uploadFile', 'VerifyAnswerAction', 'BeanEditProfileAction', 'existingClientFormBean', 'GetDocuments', 'ChatPoll', 'announcements', 'modifyDocument', 'BeanCreateAccountAction', 'ChangePasswordAction', 'VerifyClientAction', 'ChatSend', 'Help', 'fileUploader', 'BackOfficeAdmin', 'passwordFormBean', 'BeanCreateClientAction', 'action', 'Accounting'])

Here, I ran the test on Cigital’s own internal “Bank of Insecurities”, which is a simple Struts1 application. The utility’s output represents all the actions and forms that account for web-based input in their own respective ways. Sure looks like some pretty important stuff was missed in there huh?

The next step was to write a third program registerEntryPoints which would write rules for the missing entry/exit points as appropriate so that the beefy commercial static analysis tool could do what it does best. These utilities represent just some of the internal workings of Cigital’s ESP platform.

Yes, but my tool finds stuff all the time
Would a tool not find any findings without detecting entry points? Well, it would likely find potential vulnerability but only using more local syntactic analysis. Remember, “you can’t find what you can’t see…”

I’m sensing a theme in your posts jOHN
OK, so, that’s two blog posts (Mr. Cornell and my own) complaining about what I refer to visibility. Now what?

Spend time cataloging your chosen tool’s performance
Cigital experience indicates that as few as 10-13 reasonably chosen applications can serve as a representative sample for as many as 300 applications on the Java platform. When you pilot those 10-13 applications, conduct the following steps to avoid the visibility failures seen above in the portfolio as a whole:

1. On-board the application using whatever tool interface gives the most feedback about missing artifacts (*3)
2. Explore scan logs for identified entry points
3. Manually explore the application’s deployment descriptors and critical configuration files
4. Document controller logic as framework default or developer extended
5. Identify key entities within the DAO/persistence framework

When you’ve done that for 10-13 apps, our representative sample, stop and take stock of what you’ve collected. You’ll have created a very good list of items for which you’ll want to create custom rules. Different tools call the kind of rules you’ll create different things, but suffice it to say you’ll be writing rules to tell the tool that it’s:

• Entry: Taking input from untrusted web sources
• Entry: Taking input from untrusted partner applications
• Exit: Placing data in a untrusted view (browser, service repsonse, etc.)
• Exit: Conducting CRUD operations on entity data

The above list is by no means exhaustive. Indeed, you’ll want to look at data originating from the persistence tier and headed to the web (not listed above) but we often consider this as a second phase of customization. You’ll also want to begin considering data entry/exit from 2nd and 3rd party components within the applications being tests. Again, another good subsequent customization phase.

Gosh, this sounds expensive
Yes; ‘well. Compared to simply running a static analysis tool using its IDE-based GUI, triaging results, and calling it quits this is darned expensive. However, it dramatically raises your visibility into an application’s vulnerability (you should also expect false-positive reduction).

Compare this to the potential difference in quality and depth of a manual, tool-assisted penetration test and an automated vulnerability scan. An engineer running AppScan costs much less than an expert penetration test and organizations have come to not only expect different results, but see these as two very different services. I predict that we’ll see a similar distinction between two services (automated and more expert-driven) in the static space in a few years.

Leveraging Manual Efforts Across Assurance Activities
If your organization doesn’t conduct manual penetration testing and is unwilling to pay your engineers to properly on-board applications into its static analysis tool, then neither static nor dynamic analysis will benefit from high visibility into applications under test. The cost will look “high” and “extra” as well.

Conducting the kind of analysis described by this entry (targeting entry and exit points) can inform both static and dynamic analysis alike. Conduct this exercise for applications built with representative technology stacks. On the static front, write custom rules based on your work. On the dynamic side, furnish this work to your dynamic testers (even if they are external vendors) so that their exploration benefits from it.

(*1) – Coverity’s Prevent was always a notable exception and able to integrate with even challenging build environments without much pain.
(*2) – Limitations still exist with complex (distributed) build systems, code-generation schemes, and even the more mundane JSP compilation process.
(*3) – Ask if you need help here, last time I published tool details, vendors got cranky.