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.

The notion of externalizing the access control is spot-on from a design standpoint. There are many reasons to externalize and one can argue that many of the problems with web application security is that the auth/auth got shoved into the application and the application developers were not qualified to write such code.

I think what was making Will nervous was the question of WHO makes the decisions when configuring this externalized mechanism. It’s also the case that WHEN do these configuration questions get handled. The answer to date is that there is some sys-admin or app-admin that does this after the application is deployed.

Historically, this hasn’t been done very well and/or the RBAC systems put in place to configure and manage such auth decisions have been notoriously difficult to administer at scale. I will, however, say that one of the arguments for externalizing the mechanism is that the job of implementing auth/auth requires more than the PDPs/PEPs in the app; it’s all of the additional software for managing/updating the PIPs where the bulk of the work resides in building a robust access control mechanism. Again, the app-dev guys aren’t the best person to write all of the management software and you wind up with the problem where administrative functions is just a series of configurations handled through a command shell or your favorite editor.

This still doesn’t properly answer the question of WHO. Admins don’t have the knowledge to properly configure and the developers don’t have a proper notion of who should be using the interfaces they create.

This is really an architects job, but while the architect has the breadth of knowledge to make the decision yo (trying out this new gender-neutral pronoun) lacks the tool to understand the actual interfaces that exist. The architect will have pre-defined about 80% of the actual interfaces, but the implementers will have created others to solve implementation level problems. So, 20% of the interfaces will be entitled without much thought.

So, let me make another point of externalizing the auth/auth mechanism. That is what we need here is a tool that can turn all of the code into (UML) descriptions of all the interfaces. We need to decorate that list with the entitlement data, but we can only do so if there is a canonical way for the tool to read the entitlement information about said interface. If we can do this, now we’re cooking with gas since we could then write some kNN-like algorithms to compare each interface with other interfaces like it so we could see where there are potential, logical inconsistencies.

[tags]access control, entitlements, design, architecture[/tags]

Another example of this interception technique is visible in some XACML implementations. In XACML, the Policy Enforcement Point (PEP) is decoupled from the application logic. Several of the implementations of PEP’s I’ve looked at use some form of interception in front of the web service to hook the service invocation. The PEP can then extract the information it needs to perform the entitlements check.

This interception technique raised the question amongst one of my colleagues as to whether using such a scheme represented “bolt-on” security or “built-in” security. I believe that the concern is that, when used for input validation, the interception mechanism allows the validation to be done outside of service. In fact, the validation can be developed even after the service has been deployed.

I argue that this mechanism is “built-in” and not “bolt-on” security. I believe that this technique merely represents an extension of the aspect-oriented programming (AOP) concept of a cross-cutting concern within the context of a service-oriented architecture. It’s like “aspect-oriented service architecture.” Having aspects within a service-based architecture is good for all of the same reasons that aspects are good within a programming framework.

Now, I’m not suggesting that all uses of interception can be classified as “built-in.” I think that for such security aspects to be considered “built-in” that there must be some level of binding between it and the action. For example, for input validation to be considered “built-in,” the validation aspect must be able to have access to all of the input data values and must perform specific validations based on the semantics of the service being invoked. It’s not sufficient to have some lame black-list filter that looks for “<” and claim that this is “built-in” security. No, the input validation aspect must know about the data types and semantics of all the data coming into the service and have specific validation for each datum.

Maybe I’m over generalizing the notion of cross-cutting concern in service architectures. Maybe these two aspects (and they are conceptually closely related) are the only two aspects that can be factored out of the application logic so cleanly. But, just because they can be factored out and implemented independently from the application logic, I don’t think that the factoring justifies it being called “bolted on.”

[tags]soa, software security[/tags]