You can reply the webcast and get copies of the slides here.

The jist of the presentation is that SOA Security often gets equated to WS-Security (or perhaps devolves into WS-Security). The problem with WS-Security is that it’s often applied at the wrong level, so there needs to be a better architectural approach to addressing security within an SOA. By combining SDL, ARA and SAE, we’ve found that it’s possible to look at a layered approach to security based on trust zones and SOA governance tooling.

I’ve been continuing to work on documenting the details of the SDL, ARA and SAE integration with John Butler from Everware-CBDI. We’ll be doing something more formal when we have something that can be published.

Web applications suffer more than their share of security attacks. Here’s why. Websites and the applications that exist on them are in some sense the virtual front door of all corporations and organizations. Growth of the Web since 1993 has been astounding, outpacing even the adoption of the television and electricity in terms of speed of wide spread adoption.

Web applications are playing a growing and increasingly prominent role in software development. In fact, pundits currently have us entering the era of Web 3.0. The problem is that security has frankly not kept pace. At the moment we have enough problems securing Web 1.0 apps that we haven’t even started on Web 2.0, not to mention Web 3.0.

Before I go on, there’s something I need to get off my chest. Web applications are an important and growing kind of software, but they’re not the only kind of software! In fact, considering the number of legacy applications, embedded devices, and other code in the world, my bet is that web applications make up only a small percentage of all things software. So when all of the software security attention of the world is focused solely on web applications, I get worried. There are plenty of other kinds of critical applications out there that don’t live on the Web. That’s why I think of myself as a software security person and not a Web application security person.

In any case, Web application security and software security do share many common problems and pitfalls (not surprising since one is a subset of the other). One common problem is treating security as a feature, or as “stuff.” Security is not “stuff.” Security is a property of a system. That means that no amount of authentication technology, magic crypto fairy dust, or service-oriented architecture (SOA) ws-* security API will automagically solve the security problem. In fact, security has more to do with testing and assurance than anything else.

Enter this book. Boy, do we need a good measure of web application security testing! You see, many “tests” devised by security experts for web app testing are not carried out with any testing rigor. It turns out that testing is its own discipline, with an entire literature behind it. What Paco and Ben bring to the table is deep knowledge of testing clue. That’s a rare combination.

One critical factor about tests that all testers worth their salt understand is that results must be actionable. A bad test result reports something vague like “You have an XSS problem in the bigjavaglob.java file.” How is a developer supposed to fix that? What’s missing is a reasonable explanation of what XSS is (cross-site scripting, of course), where in the bazillion-line file the problem may occur, and what to do to fix it. This book has enough technical information in it for decent testers to report actionable results to actual living developers.

Hopefully the lessons in this book will be adopted not only by security types but also by testing people working on web applications. In fact, Quality Assurance (QA) people will enjoy the fact that this book is aimed squarely at testers, with the notions of regression testing, coverage, and unit testing built right in. In my experience, testing people are much better at testing than security people are. Used properly, this book can transform security people into better testers, and testers into better security people. Another critical feature of this book is its clear focus on tools and automation. Modern testers use tools, as do modern security people. This book is full of real examples based on real tools, many of which you can download for free on the Net. In fact, this book serves as a guide to proper tool use since many of the open source tools described don’t come with built-in tutorials or how-to guides. I am a fan of hands-on material, and this book is about as hands-on as you can get.

An overly optimistic approach to software development has certainly led to the creation of some mind-boggling stuff, but it has likewise allowed us to paint ourselves into the corner from a security perspective. Simply put, we neglected to think about what would happen to our software if it were intentionally and maliciously attacked. The attackers are at the gates, probing our web applications every day.

Software security is the practice of building software to be secure and function properly under malicious attack. This book is about one of software security’s most important practices—security testing.

—Gary McGraw, July 2008

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]

Sure, most of what you see when you walk into a big IT shop is still monolithic applications, but those are echoes of IT history—dead men walking. SOA won because it is a natural evolution and logical extension of the way we have been building systems since Grace Hopper showed us the light. Our first programs looked monolithic, but only on the surface. We learned that good practice requires us to decompose our programs into procedures, subroutines, (or whatnot depending on the language) that had limited functionality with well-defined interfaces—nothing too large to fit in the space between our ears. Code reuse as the Holy Grail.

SOA is just the extension of good programming practice except that high bandwidth, reliable, standards-based networks and emergent standards for things like message transport, service registration and service invocation mean that our systems need not operate in a single memory space. The acronym SOA may not survive. Software sales dudes always come up with new names to sell a polished up version of the same-old, same-old, but service-oriented architecture and, more importantly, service-oriented architecting is here to stay; its centrality in future systems is as inevitable as the sun rising in the east.

With that rant out of the way, what I want to say here is that there are unique security issues related to security. I plan to discuss these in forthcoming blog entries, but I have a meeting today with the Ettienne Reinecke, CTO of Dimension Data, one of the best networking companies in the business. I have been thinking hard about how the guys like him play in SOA beyond giving us reliable pipes. Let me share my thoughts.

Networks work really well—software not so well. Why? I suggest that the success of the networks lies in three factors—componentization, standardization and that management. Networks are not monolithic. They are composed of lots of individual pieces, each with a well-defined function (sound like SOA?). The performance and interfaces of each component type are very well-defined by standards. This means that different components can be integrated with moderate ease and some reasonable expectation that they will work together. It also means that the people who develop the components can continue to refine their designs—to polish them until they are sparkle, making each generation, faster, better and cheaper—as long as they keep the interface constant.

Finally, the network guys assume that the network isn’t going to work. They assume that components will break, so they instrument the network to monitor its performance and they watch it carefully. Good network engineers also design for graceful degradation—the ability to lose performance in increments rather than catastrophically (think escalators vs. elevators). We on the software side can learn from this. The presumption of fallibility and the capacity for graceful degradation are alien concepts in the software world. They shouldn’t be.

In moving to SOA, we are componentizing. In adopting web-service standards we are standardizing, though our standards are much less mature than those for networks. Good for us—we have to two of the lessons down—componentization and standardization.

Let’s take the final step, and build our SOAs with the assumption that they will fail (a safe assumption) and engineer-in monitoring and the capacity for graceful degradation from the beginning. We can “ping” network components to see if they are alive, query their state, test them and change their state during operation. We should be doing this for SOA services. Ultimately, system operators should be able to look at panels like those now used for network operations, showing in color codes the status of each service. They should be able to detect problems and fix them on the fly.

Essentially, as we move towards SOA we are shifting from thinking of our systems as discrete entities to thinking of a computing ecosystem that runs 24 hours a day, 365.2564 days per year (more or less). This model is completely unnecessary for a simple program that does one thing, and only runs once in a while, but these are becoming an endangered species.

The trend in IT has always been towards greater integration. The data from one program feeds into the next, and the next…and the next. We can think of a data store as the DMZ between two applications or we can think of it as a cache in a larger system. The boundaries between systems are often arbitrary and are often simple reflections of org-chart boundaries rather than computational or business logic. At the level of the enterprise, we are evolving towards a more comprehensive view, beginning with simple shared services like database and directory, but moving, inexorably and inevitably towards shared functionality.

The network engineers have already made this transition. We should lean from them and relentlessly componentize, standardize and manage.

[tags]software security[/tags]