Benjamin Tomhave wrote about “tiering” security guidance when I cross-posted a comment to my last blog entry on the SC-L mailing list. Quoting him:

The higher up you are in the policy framework, the more general and time-enduring the content should be. The farther you progress down the framework to a more detailed level, the more perishable the content will be, out of necessity.

Later he continues:

…is because implementers need it. They’re not security experts (usually) and do not necessarily grok security the same way a seasoned (salty?) security person might.because “implementers need it”.

This tiering was implicit to my first post. In fact your most senior security resources can probably use nothing but Security Principals (as described by McGraw’s BSS Book and the famous Saltzer paper) and find both insidious vulnerabilities as well as brand-new “Game over” architectural flaws with new development technologies they aren’t familiar with. But, the more junior (inexperienced) or development-oriented (constructive) the person being targeted, the more specific the guidance must be in order to be valuable without requiring inordinate effort.

Because we’re trying to change the behavior of the majority of our Developers–who range in skill from OK to Hero and whom may have never had even a security awareness class–I find “technology-specific” guidance moves the ball the furthest.

In my previous two posts I talk about forms various levels of standards take, and the way in which one might create it. It occurs to me that I all but showed the bigger picture and might as well follow up to do so. Below, you’ll find a map of how I show security guidance flowing throw and effecting a software development team (click-through for full detail):

As information moves from top to bottom and from left to right it becomes more specific and actionable, but also more perishable (as has been said). To build security in, one must think about security’s implications throughout the lifecycle, so I see no reason why security knowledge (regardless of how specific) shouldn’t mirror artifacts used to construct the application itself: software requirements, design, and the code itself.

Though not central to this discussion, the diagram has been annotated to indicate who should produce and consume this information. Here, I’ll point out that your centralized Application Security Resources can probably most effectively and efficiently create the generic security guidance, but will need help of Security Architects to create the more technology-specific guidance and garner broad buy-in.

My last post presented a brief model of how one might organize and fund this in practice.
-jOHN

Technorati Tags: knowledge architecture, software security

The process of writing security guidance is just as important to the quality of the resulting standards as is the target: technology-specific, code-centric constructive statements. How do you succeed? By using the same muscles you exercise when you conduct secure design.

When I write Security guidance, such as the technology-specific standards I blogged about last week, I start with a threat model for the system (or design paradigm) I’m trying to protect. This could be as specific as a single system or as generic as all my client’s customer-facing 3-tier J EE Apps. I aim to remove attack vectors with sets of standards. I don’t write standards that don’t directly prevent a particular attack I’ve already documented in the same way Agile Developers ignore abstraction not mandated by the current user stories. Eventually though, removing a subsequent attack vector will require a smidge of refactoring or (more likely) augmentation.

Thinking about each attack vector individually gives necessary focus to the process and will help get past hapless statements of context-free specificity. Years ago I saw, “All data must be protected with 128-bit encryption???, within a customer’s standards. Admirable though the specificity was, the limitations of this as a standard become immediately obvious. Would 128-bit encryption suffice for archival-grade needs—such as log files? What does the plain-text or cipher-text data get used for? If we’re looking at attacks on session management within our imaginary web-app, simply encrypting a session token doesn’t effectively protect against theft and replay does it? Remember last week’s entry. There, in my example, I sought to protect against the circumstance in which (due to omission or later maintenance) a Developer forgot to explicitly demand authentication prior to accessing a piece of functionality.

Think of security standards as requirements driving a design that resists the attacks you outlined in your model. This focuses authoring and often alleviates the writer’s block a blank page can impose. Improving and completing guidance becomes tractable. In my crypto example above, the client was attempting to secure exchange of data between two systems (thick Java clients) over the Internet in a circumstance in which they could not rely on SSL being present. Data from each transition persisted beyond a single session, but had a short span of value—say a day, or week (depending on the volatility present in pricing). You’re probably already conjuring ideas about what you’d expect to see in a secure implementation. With as little context as this, my explanation of the design begins to illuminate attack vectors. From these, you can begin to answer the questions I posed above about ciphers, structure of data, and from there secure design becomes an exercise in trading off difficulties of key maintenance, performance/overhead of the encryption, and others with resisting the attacks you’d enumerate.

Not shockingly, HOW you build this guidance is as important as ending up in courier font. And, (again) it shouldn’t surprise you that I’ve chosen to get end up with code (courier) through design (via threat modeling). This is how software is built—and security should be no different. This does mean you’ll need security architects (who can code—not the corporate librarian types) to write good, detailed security standards though.

Technorati Tags: software security

While speaking at a conference out west an interested attendee challenged me: “You said I should make my security standards as specific as possible, but the other speaker said, ‘Keep them general’, what gives???? This type of exchange happens all too often in the software security space these days. I could do a piece on that alone, but instead, I’ll address the challenge.

The confusion stems from two competing goals driving standards creation: 1) providing useful security know-how that benefits developers and 2) obtaining ‘coverage’ of all the security concepts, technology stacks, and development/deployment platforms your organization uses. To be useful to developers–to truly change the way they behave when “Their butt hits the seat in front of their compiler???—one has to speak their language. Developers speak and write code. Documents like security policy, tend to be written by Corporate Security, or worse: lawyers. These groups speak and write legalese. There’s a big difference and it’s easily detected: one usually comes in 12pt. Courier.

Your objective: answering questions about how to do things right for developers by showing them the right way… while leaving enough flexibility and room in the guidance for them to remain creative and solve the business problems their application was intended to.

Writing technology-specific guidance engages Security Architects in helping directly solve Developer problems. Rather than specifying “Do not allow direct access to Servlets by name” (a decent agnostic standard, when used in concert with others) show them how:
——
Using Struts, map an impossible-to-assign role, such as noaccess to every Servlet but one–a single front controller–that mediates access to your other Action Servlets like this:

 <web-resource-collection>
   <web-resource-name>Application</web-resource-name>
              <url-pattern>/functionality</url-pattern>
       </web-resource-collection>
  <auth-constraint>
   <role-name>noaccess</role-name>
  </auth-constraint>
 </security-constraint>
 <login-config>
  <auth-method>DIGEST</auth-method>
 </login-config>
 <security-role>
  <role-name>noaccess</role-name>
 </security-role>

Place all Action Servlets in a single directory, for ease of maintenance (/functionality in the example above). Demand authentication prior to access to the single front controller and delegate actions from that Servlet.
——

Alternatives may be necessary. For instance, while the standard prescribes lumping functionality in one directory–that may not be possible. For those cases, the standard should describe how extension based url-patterns can aid in casting the broadest net possible.

Standards, at this level, should always state a preference however. The worst offense of failing to do so is nearly every J2EE book’s discussion of both declarative and programmatic means of authorization without indicating which should be used when.

Next week I’ll move on and discuss detailed, technology-specific security guidance in more detail, but first I would like to recognize the value less specific guidance provides. Detailed, technology-specific guidance requires significant time and effort to produce. Such guidance is perishable and becomes useless as you upgrade or update your technology stack. Technology agnostic guidance, or guidance kept at the level of security concepts insulates you a bit more. Organizations should certainly start with this level of guidance, getting coverage over the broad array of security topics needed to educate their developers before diving down a rabbit hole and writing technology-specific guidance.

In other words, one level of guidance does not replace the other. Instead, less specific guidance serves as safety net underneath the more specific, catching inquiring minds when the specific guidance hasn’t been written yet or when it doesn’t apply (as often happens when a team faces constraints like deploying an old version of Tomcat).

I hope, however, that in the meantime I’ve shown an example of how being technology-specific, code-centric, and detailed about standards can engage security folk in development, engage Developers in their own language, and actually push projects forward more quickly by making hard security decisions for them. This is just one of the activities your Security Architects can undertake when they parachute into development teams… a concept I introduced in my blog entry on research in the 50’s.

Technorati Tags: software security

Sammy aimed two recent entries at those attempting to govern security and expenditure in an organization. I’m using his posts as license to wax more philosophically. Specifically, I’m going to use Digital Rights Management (DRM) as a lightning rod for conversation about protecting data end-to-end in one’s system (the topic of my next–far more focused–post). I’ve been thinking about this ever since McGraw’s Dark Reading column: on Vista, and it’s driven me mad.

In posting this message, I’ll skirt more topics than I cover; I apologize. In return, I’ve included a lot of links worth reading. I don’t presume to answer the question, “Is DRM ever a good idea?” I believe most computer security folk simply answer “no,” bemused because in the end they know consumers MUST use protected data and algorithms in their full quality, to be satisfied. Some gifted albeit misguided security folk attempt to trade data quality for what they perceive to be security. Peter Gutmann’s working paper covers Microsoft’s attempts through Vista.

When I replied to Gary’s Dark Reading article, defending Apple’s DRM, I had purchased about $350 worth of music from iTunes. The standard caveats applied:

1. Apple could change their DRM scheme out from under consumers at any time
2. DRM still provides no value from the consumer’s perspective
3. DRM imposes limitations, potentially limiting competition between vendors

but I still found myself unable to come to any other conclusion but the mighty unpopular: Apple’s DRM seems a reasonable compromise between affording protection and remaining flexible to consumers. Remember, I said ‘unpopular’, so feel free to argue with me.

Now, $450 into the fray, something very interesting has happened: Apple and EMI have decided to sell some music electronically but DRM-free (see:
http://news.bbc.co.uk/2/hi/technology/6516189.stm ). Unprotected music will be encoded at 256KBps (twice the bit rate of Apple’s protected files) and will cost $1.29, rather than $0.99.

Now, consumers have an interesting choice to make: “Do I want to pay an extra $0.30 for the ability to copy the music I purchased freely?” Some may be willing to pay extra for the quality–but that’s not what we’re interested in right now.

In asking local “kids,” I’ve gotten consistent reply: “I’d only pay more if I liked the band.” Questioning them further immediately reveals they perceive the music to be free (and rightly so–it’s just too easy to pirate). They make their purchase/steal decision based on their feeling of loyalty towards the band. Can your business rely on such good will? I used to pay for single pieces of bulk candy at the grocery store–but I wouldn’t bet my business on others doing so. At the same age (prior to driving) I’d hack games’ copy protection, give copies to my friends and say, “Ok, but call me before you play it… to make sure only one of us is using it at a time.” Why am I only now explicitly aware they never called? Guess they never played it ;)

More fundamentally, will consumers perceive your product or service as being free? Think back to Windows ‘95… did anyone you know have a problem copying it?

An interesting question to ask one’s self is this: At what increase of price can I afford to protect my data less for the sake of other business drivers? Presumably, EMI has come to the conclusion that the answer, in their case, is $0.30. Interesting. If protected music accounts for only 2% of sales (dubious estimation by extrapolation of iPod size + sales compared to iTunes sales), how much does EMI expect that number to jump if the price has moved to $1.29? If physical sales still occur at $1.99 per single, how much less piracy does EMI expect from electronic sources as compared to physical ones? What does this even mean–given that pirated physical wares will almost immediately take the electronic form for ease of distribution?

Finally, what numbers could Apple put on the cost of developing and maintaining their DRM scheme? What affect does that price have on their profits (if any) in the case of EMI’s unprotected content versus that which is protected?

Part of me wonders if any of this will have even the slightest effect; given the ubiquity of the protected content, unlocked and freely available from peer-to-peer sites. If all’s for naught, is EMI making a good decision, or a mistake? God, I hope there’s no analog for that in your data.

I have no idea how successful Apple’s iTunes model will be, or whether or not consumers will accept Vista’s DRM, but with EMI’s decision to distribute unprotected music along side protected songs, those of us in security-land potentially gained data to look at. What will it tell us? And, while it’s very unlikely that you’re distributing electronic music, dear reader, or even passing content directly to end-consumers, EMI’s move should raise questions about how you’ve calculated the value of data, the protective mechanisms you’ve placed around it, and the impact on usability those protections imposed.

Technorati Tags: drm, apple, data security

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