While reading last week’s Economist, I stumbled on an article on Innovation (available without a subscription online). The article discussed how commercial entities have changed the way they fund R&D. They’ve fundamentally changed the structure of research and development groups–as well as their interaction. I began my Cigital career in the company’s research division and later moved into a purely operational role as “Consultant.” “Principal,” my current role, demands artful compromise between the two, so the article immediately caught my attention.

When a client asked about “Getting in front of AJAX from a security perspective…” this week, I connected dots between organizations’ need to innovate and the realities development require.

The big change: Big research labs (such as PARC, Bell Labs, IBM’s labs) have become extinct and hoping for “tech transfer” after stand-alone research investment represents a fatal chasm between “Research” and “Development” unlikely to be crossed… or improperly exploited even when crossed.

I see an analog for this in today’s software shops, especially pursuant of security. Right now, organizations don’t understand software security well enough to treat it as development. For them, it’s still research. While not science, in its strict sense, people don’t know much about software security. They’ll have to read, think, experiment, and be very creative before moving into a engineering/development mode.

That’s why my client said, “We want to get in front of AJAX…”; he, his organization’s software security guardian, sees a problem development can’t solve, and he doesn’t yet have the answers either. He needs a leap or two forward before he can communicate solutions to hard problems well enough to empower development to “build security in.” These problems include personal data protection, authentication, and even the very process by which his organization creates software. That’s probably why he called Cigital.

My client faces a common situation. Organizations drive their businesses, for the most part, reactively. Product companies react to customer needs (features, deadlines) and IT shops react to opportunities and risk the businesses they support face. Unless driven by compliance, publicized incident, or a similarly dramatic driver, these businesses’ development teams don’t react to software security’. As a result, development doesn’t possess engineering skill and experience in software security.

What to do about it: Organizations depending on innovation must 1) foster practical engineering (development) behaviors in those individuals with the horsepower for research and 2) embed them in development teams towards a practical end.

First, get qualified individuals. But, I’m not referring to wild-haired mathematicians. You probably already employ some of what you need in your org. I’m talking about your gifted individuals that attend conferences, avidly consume literature, and possess an advanced degree in computer science (or similar). These individuals frame the problem, hypothesize a solution, observe, then iterate.

This person probably has an uncanny knack for coming up with lateral approaches to your design problems. They may be a complainer–ineffectively shackled by their current position. A former mentor to me used to comment, “You seem to always have ‘just read something’ useful in every meeting I bring you to.” That’s what you’re looking for.

I like to focus on “Security Architecture,” so I look for these types in the Enterprise Architecture group (though, the do-nothing librarian type need not apply). Specifically, you don’t want someone that ONLY reads, or with no (or outdated) hands-on technology experience. We’ll call these people your innovators.

Second, embed these people IN development teams. Preferably, innovators should be ‘leased’ to the team solving the difficult problem: securing credit card data without increasing its (representational) size unduly, for instance.

As part of a development team, innovators should be held to a schedule and budget, like everyone else. I like the idea of managing them to a final delivery a release or two out, but with important constructive deadlines within the current release, showing progress. Managing these interim deadlines between “Hail Mary checkpoint” and “incremental main-line progress” depends on how ambitious the overall goal is.

I argue that organizations lose when they fund research with development project money directly or comp. (bonus) innovators with project metrics directly. Having these individuals report to someone else (shared services?) will allow them to focus on their technology goals. If their manager sits as a peer to those managing development, tough conflicts regarding project schedule and security program priority can be resolved reasonably.

However, that’s not to say that the development team shouldn’t participate in cost though a “tax.” After all, they do benefit from the extra horsepower applied to their project. Likewise, the researcher should be evaluated, in part, based on development project impact.

This approach naturally lends itself to a consulting model. You can hire someone or use your own internal team (which one of our clients does particularly effectively). First, make sure they’re qualified: exploiting code can be pretty easy and some consultants give bad advice generalizing quickly from something they’ve seen once. The “use POST not GET” advice OWASP gives serves me consistently as an example. I’ll cover this example and poor advice in a later post.

Beware the “’sploits-and-splash” failure mode. Embedded security resources must be constructive. Simply pointing out how not to do things doesn’t produce secure code faster and disenfranchises developers. Advice about how to pay and measure these individuals applies here. Instead, focus innovators on the tough design problem it will likely take two-to-three releases to iron out, and that might be useful on a whole class of products within a line of business. Make them responsible for producing a solution; not just pointing out problems in every product team’s smaller attempt at one.

Cigital believes in research, in the true sense of the word. We talk about the value a lab provides in each of our strategy meetings. We believe in practically applying more theoretical solutions in a consulting model as well. I believe injecting a research mentality, as a ‘thread’, into development serves as counter-weight to reactive mentality, helps solve software security problems, and gives the necessary horsepower boost to “build security in.”

I think you’ll find that architectural flaws your organization’s software exhibit require solutions “bigger than a single release” and set the stage for this topic nicely. The alternative? Fall prey to a purely engineering mentality making small incremental improvements that remove a single attack vector but leave the endemic flaw at large. This causes continual development churn and leaves the software exposed, ultimately.

Technorati Tags: ajax, software security, enterprise software security

Because Cigital spends time helping clients document “technology-specific” security standards, to aid developers and architects, I get asked, “What do you think about [new technology XXXX]” alot. Questions regarding AJAX have crossed the threshold, so I’ll post what I think here.

Quick disclaimer: I make no comment about the technologies or security in a Web 2.0 world (I’ll leave that to Captain Technology Curmudgeon, Scott).

The world still wrestles with how to best use AJAX, so a lot remains in flux. But, I believe if you’ve got teams prototyping its use, you’ll need to consider the following:

1) Picking an AJAX toolkit - There’s a quite a few out there and each covers different ground. What’s more, people are plugging in their own approaches to things (like password management) into toolkits and riding the wave.

People always used to ask, “Websphere or Weblogic?”. I’m no product’s salesman. Usually each possesses strong advantages and disadvantages. I wanted organizations to understand tradeoffs and make an informed decision themselves. One group heard me out, took a look at price, and picked Weblogic. Their rushed decision forced them to need _me_ to implement clustering robust enough to handle the scale they desired; Plain shortsighted.

Just like your choice of containers in the Enterprise Java world, your choice of AJAX toolkits provides much of the backdrop for your software development efforts. Because the toolkit handles a lot of client-server plumbing, the security posture of your application will depend on the toolkit’s implementation. Do not make this choice lightly. Consider elements of security along-side supportability, usability, and the other decision factors.

You need to technically vet the toolkit. As I said in the case of containers, this toolkit will act as a security “table cloth” that could be pulled out from under ALL the applications you implement on top of it. Have your security group leverage any existing threat models it’s constructed for n-tier applications so that they’re not starting their analysis from scratch.

My next entry will indicate what “development scenarios” one should put each toolkit through the paces on in order to help their development teams be productive.

Moral: Spend enough time prototyping with candidate toolkits to make an informed decision about “best for you” and the realities of integration.

2) Exploring Toolkit Architecture - A natural ‘next step’ after #1, perhaps the later stage of a thorough technical assessment into a particular toolkit. Any time you move to a new technology, you need to “get smart”. Most people skip this step unfortunately. An architecture team can save security guys a lot of time by steeping themselves in a technology, writing a primer, and distributing it to developers.

When financial companies started writing their back-ends in Java, they all fell down on String processing. They just weren’t prepared for how differently (and expensively) this ‘new’ technology manipulated strings. I spent a lot of time with development teams showing them, on a whiteboard, how XML-processing affected Java’ memory management–and how to ‘game’ it. You want to “fight these battles” once, centrally, and then share the battle scars before they occur again.

In AJAX, we’re finding toolkits handle different segments of requests client-side and impose differing amounts of requests on client-server interaction. Find out how your candidate toolkits handle requests and which side of the client-server divide weight for those factors affecting security fall. WRITE THIS DOWN. Get an adoption and user’s guide out to your earlier adopter teams. Have them write version 1.1 of the document.

Moral: Share institutional knowledge gained by vetting toolkits.

3) Don’t leave real design time with short-shift to ‘buzzword’ architecture - Selection of a platform, framework, or toolkit (perhaps all three) does not constitute an architecture. Patterns, messaging protocols, threading/event models, state machines, and similar high-brow concepts constitute the language of Design. Design should address both the structure and behavior of a system. Toolkits may help address design concerns and certainly impact design–but they do not themselves constitute the design.

During an architectural analysis of a 1.0 –> 2.0 product transition, the chief architect said, “Well, we’re just going to use struts on top of tomcat, the end. Oh, for authentication we’re using Acegi.” After extended silence I asked, “In terms of how many factors does the authentication decision get made and how will you represent those factors in Acegi and elsewhere?” The answer to these questions plagued their development team for over a month. As it turns out, they couldn’t just ‘outsource’ authorization design to the fine members of the Acegi framework.

“Buzzword” architecture produces no better a result when AJAX makes the list. You still have decide what’s asynchronous and what you’ll make more persistent connections to resolve. The matter of dividing model, view, and controller (especially the last: controller) between components and tiers becomes more difficult. With a distributed application controller, application state transition becomes sticky.

Moral: Don’t let enterprise or application architects off the hook for design because they say [Technology: AJAX] will handle it. Make them specify real design; it’s their job.

More news @ 11…

-jOHN

Technorati Tags: software security, ajax

Frequently, those directing software security initiatives ask what others in their space are doing. I believed this was a perfectly reasonable question and answered, dutifully protecting each side’s confidentiality as best as humanly possible. Indeed, this kind of perspective represents one key value Cigital provides to our clients.

Over time my relationship with clients deepened, as did their maturity in software security. Their questions also deepened, getting more specific: “How far down the static analysis tool adoption path are my competitors?” I can’t see any way of answering questions this specific without giving away others’ competitive advantage, potentially exposing them to risk, or violating their trust (not to mention NDAs). Stuck wondering if I would be unable to provide further perspective, I began to question this perspective’s real value:

“Is the Jones family really the goal?” I asked myself. Actually, I’m pretty sure it isn’t. Each organization’s security efforts should grow very differently from one and other. They’ll start at different places, sure. Not only that, but even if you tackle the same problem as your competitor chooses to tackle, the ‘optimal’ approach for each organization differs. Why? Because each IT shop grew up to support their business differently. Metaphorically both you and the Joneses have children—but both sets of children have very different special needs.

Certainly, hallmarks of a good program exist. At this point, I consider organizations behind unless they:

• Conduct source code and architectural reviews of software produce and acquire;
• Leverage a static analysis tool suite in reviews;
• Train developers using hands-on instructor-lead courses;
• Augment training with continuing education;
• Distribute technology-specific security guidance, showing developers proper use of open source toolkits, frameworks, and COTS components;
• Subject applications to penetration testing in production;
• Measure both the vulnerability of software as well as the effectiveness of means by which software is secured.

While not exhaustive, the above list indicates a firm commitment to whitebox analysis. Cigital helps companies deploy the above means, in lock-step with each other, in order to get maximum benefit. Without help though, which measure you focus on next depends your organization. But additionally, how you make each effective will also depend on specifics of your organization. I’ve listed several factors that play into software security initiative decision making:

• Do you build, acquire, or buy most of your deployed software?
• Is your company an IT shop, supporting a business, or a product company?
• How do you characterize the bulk of your developers: Off-shore, out-sourced, contracted, seasoned, new to the field?
• What background do your Security resources possess: Network security, Development, Architecture, Management?
• What languages do you use, primarily, for software development?
• How varied is your development platform and build environment?
• Where do security resources report in the organization?
• Is the organizational culture centralized, one of strong governance? Or, does the organization rely on engineers to direct its efforts?
• What architectural paradigms does your application suite conform to? Are they primarily n-tier, monolithic, client/server, or federated? What messaging, transaction, structural, and behavioral patterns do they implement?
• What assets do the applications protect: functionality, data?

Obviously, when we conduct an organizational assessment we augment the above questions with a wealth of others.

Having explored data the above prompts gather, I suggest organizations build on their strengths rather than attacking weakness head-on. For instance, rather than foisting security analysts on development to do architectural analysis, I suggest teams subscribing to an agile methodology begin by augmenting use cases with misuse/abuse cases. Later, those teams can build towards threat modeling and begin to add elements of architectural analysis into their process of re-factoring. Augmenting a familiar activity always proceeds more smoothly than adding another (perhaps foreign) step. This advice stands in complete opposition to what I commonly give to IT shops with strong central governance: begin conducting architectural risk analysis immediately.

Over time, your security efforts will achieve coverage over prescribed best practices. Playing off your organization’s strengths can keep development more comfortable as it maneuvers to deal with security, often a new objective. If your security group succeeds in rolling out security practices synergistically development will view them as resources, not annoying cops. Ideally development begins to pull security into their efforts—requesting their time proactively because they see the value.

Remember, there’s no one-size-fits-all solution, especially in a discipline as young as software security. What will work best for you depends on the specifics of your organization. So rather than worrying about the Joneses look to understand your own situation better and respond to it in turn.

-jOHN

Technorati Tags: software security