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

Software security veterans have all certainly thought about the idea of ‘securing the SDLC’… I can tell because every consulting firm’s collateral that I’ve seen in the past year has a new bullet under their ‘services’ section referring to something like ‘Secure development process integration’ or ‘Secure SDLC services’. That being said, let’s talk about what this means for a second. Fundamentally, there are a few ‘different’ schools of thought out there (and as it’ll turn out, they’re not all that different at all).

I know of three popular ways of looking at the problem, 1) Microsoft SDL 3.0 (with a recent book by Howard and Lipner to codify the subject), 2) Software Security Touchpoints from Gary’s book Software Security, and 3) CLASP (originally developed by Secure Software, Inc, and now an open project through OWASP). BTW, if anyone knows of other publicly usable process methodologies, by all means email me since I’d love to read about them.

After spending a bit of time thinking through all these different ideas, a few interesting points emerge. First, there’s not much difference between SDL, the Touchpoints, and CLASP. There’s just about nothing I can see where these processes fundamentally disagree. The differences are really only in the timing and the extent of the prescribed activities (i.e. they each cover the bases of what you should be doing, some just give different orderings to the activities and talk about the sub-steps in different ways). My personal opinion is that SDL is particularly suited for companies like MS (large ISVs with large user populations) and process like the Touchpoints and CLASP are a bit more flexible and widely applicable.

So what’s the deal? Do we have the problem of dev process augmentation solved and put to bed? Heck no. Consider the following quote that popped up in a discussion my buddy Gunnar Peterson and I had at the recent OWASP conference in Milan: “Amateurs talk about tactics, debutants talk about strategy, but professionals talk about logistics.??? (this quote has many variations and is hard to find a definitive source, but it’s likely from a US military officer many years ago). As the software security space was emerging, you bet we had to crawl from the primordial ooze by figuring out some tactics to stop the bleeding. Logically following, lots of smart folks sat down and figured out the right way (via experimentation, mostly) to look at the problem from a high-level. Hence, strategy for software security was born. Now, the proverbial last mile is the logistics of how you get the job done within an organization that’s got 50,000 real-world constraints that complicate everything.

Regardless of your favorite security-enhanced SDLC method, you’ll notice that they really are, at their core, a collection of activities, procedures and artifacts (tactics). Don’t get me wrong, it’s great stuff in terms of what’s needed to do the job well and it’s generally assembled and presented in a full-blown, whole-hog, flying-car way (strategy). If you’re in the shoes of the person in charge of augmenting your company’s dev processes, you’re handed a large collection of great things to think about, but little that’s directly actionable in terms of answering ‘what do I do tomorrow?’ (logistics).

What I’m getting at is that I think we’ve gotten to the point where if you’re still debating tactics of what to do or the strategic vision of what needs done for process integration, you’re solving the wrong problem. It’s about rubber-to-the-road logistics. We need to build on the work that’s been done already and come up with plans that make it accessible and usable for an average human that hasn’t made a career on thinking about these things. That’s a serious challenge, but not an impossible one. At Cigital, that’s what our SDLC process gigs are all about (providing the company a detailed plan of how to get it done). What’s needed now is to get a more abstract way of looking at the various factors that contribute to logistical differences (e.g. type of business, market vertical, organizational hierarchy, regulatory constraints, etc.). I strongly believe that we can formalize these factors and I think that goes a long way to breaking the back of the problem. I fact, I’ve been working with folks in the OWASP community on this very problem (and would love to get anyone else with field experience involved). Much of that work will be released in a new version of CLASP in the next week or so, so stay tuned if you’re interested (I’ll post another entry here announcing it).

Technorati Tags: software security, sdlc

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

In the course of my career I have been involved in a fair number of startups. I’ve had pretty good luck, and most of them have been successful. One, however, was a complete failure. I refer to that experience as my DIY MBA. You can learn more from failure than you can from success. It is very difficult to determine what made something succeed (apart of course from our genius, hard work, and moral virtue), but if we look at something long enough and with whatever objectivity we can muster, we can usually find a root cause for failure. If we’re smart, we won’t that make that particular mistake again.

One of my favorite books is Engineers of Dreams: Great Bridge Builders and the Spanning of America by Henry Petroski, the wonderful writer on engineering. It is a book about extraordinary success – the construction of the great bridges of America, but it is as much about failure as success. Bridges fall down throughout the book, but each failure shines light on another aspect of bridge design and the limits of the materials. The heroes (the great engineers) learn from their experience and continually build better and longer bridges. What I took from this book, beyond an appreciation of the bridge builder’s art, science, and mastery of the political (all big projects involve politics) is that that failure is something to be treasured once you get past the pain.

My one entrepreneurial failure was in a company that did desktop publishing around 1980. My partners and I bought two NBI 3000’s, very early, very expensive word processors. Businesses in and around Boulder, CO, some students and professors came to us with hand written drafts which we turned into beautiful printed documents. The machines were complicated, temperamental, and difficult to use, though they defined the state-of-the art at the time. Only trained operators could manage them. Word Processing was a task for pros.

Of course the company failed. Things went well for a year or so, but then the first practical PCs and word processing software came out. People began to do their own word processing, even on crude, small, expensive machines. When the IBM PC came out and legitimized PCs, everyone started writing on computers and doing their own desktop publishing. The stream of customers dried up and we closed the doors.

My first thought about Document Control (the company) was that our technology was simply made obsolete — that we were selling slide rules in the age of calculators. I think though, that we were really swept aside by a more fundamental imperative – the human urge to do things themselves. In the Pharaohs days literacy was regarded as something for specialists, and the leading classes hired scribes to perform that difficult task. When the telephone was invented we needed operators; when cars were invented they were often driven by mechanics. Over time in each case the difficult became simple and the rare became commonplace. For the things that count, people would rather do something themselves than have it done for them if it is within their ability and comfort zone.

This principle pertains as much in IT as in other arenas. IT was once entirely the province of the professionals operating in glass houses, who accepted data on cards from the acolytes and returned them manna in the form of green bar. It was inconceivable in those days that computing would become the province of the everyman but, of course, it has.

I am not referring to people using personal computers to access the Internet, using email, and writing newsletters for the PTA. That is really too obvious for comment. What I am referring to is the continuing trend in all sorts of organizations to empower the individual. Individuals prefer simple hosted applications like Saleforce.com to complex CRM from central IT and they use desktop tools like the Microsoft Office Suite to build very complex applications. The things they build are not tightly integrated like the applications built by professionals. Processes may still involve many manual steps that a pro could program in a few hours (after a week of committee and budgeting meetings, another week of design review, and two weeks or so of testing). We pros can do it better – complete automation, all sorts of bells and whistles the rubes would never think of, audit trails, better security, and all that good stuff, but the users prefer the stuff they build (or discover) themselves. It does what they want and they understand it. More than that, it empowers them. They feel in control. In the end, DIY always wins.

Going into word processing was not a mistake. The machines were great and they did things that simply weren’t previously possible. The mistake was in persisting even after the first personal computer showed up. The was on the wall, and it read that in the end, DIY always wins.

In building our enterprise applications we must be cognizant of this same imperative towards DIY. There will always be central IT applications for things like basic accounting – accounts payable, accounts receivable, etc., but organizations are dynamic – buying businesses and being bought in turn, reorganizing, opening and closing business lines, launching new products and dropping others, doing studies and projects. The central IT department is always running behind but the DIY community filling the gap with their jury-rigged lash ups. Giving the pros (i.e. us) a break, though, real IT is hard.

I know that this informal IT – the IT that takes place outside the purview of the IT organization – is already and important part of every business. I suspect that in many organizations these home grown applications may actually be as or more important than the official stuff. My wife who works in the accounting business, for example, is tracking the company’s backlog and progress in an Excel spreadsheet as the tax deadline approaches even though her company uses the best accounting software in the business.

As IT tools have improved, everyone has become a practitioner to some degree, just as our ancestors learned to drive cars and make calls and our ancient ancestors learned the arcane art of reading. A challenge for us as professionals is to give the non-professionals the tools they want and need so that they can define how they do their work, and then work with them, not against them, to improve these informal processes and bring them up to “professional grade.” DIY is a powerful imperative and much of the IT that we now regard as the realm of the professional will inevitably move into the hands of users. We should not resist this, but enable it. I would love to see what users could do if they could have a real-time access, with Excel as a front end, to a company’s core data in real time. What would they build? I know that they would build better tools for their personal work, but they might just go beyond that to provide new insights into the way the company operates and models for how the company’s processes can be improved.

Technorati Tags: diy, it