significance of implementation vs design varies regarding on the

actual development platform.

In the case of software developed in C/C++, an implementation

error can mean “game overâ€. So, essentially, if you are

pen-testing software written in the aforementioned languages, even

when you have somewhat deducted that the design holds its own, you

have to be extra careful about the quality of the implementation

(and I am not talking strcpy() either :) ) Guys who cut their

teeth auditing software in C/C++ tend to be more focused on the

implementation side of things.

In the case of say .Net or Java, implementation errors can still

spell “game over†but if you are pen-testing your typical web

application, chances are you will have found already much more

severe (and perhaps easier?) design flaws (once again, this is

from my (limited?) personal experiences so YMMV).

First, I think it’s important to take time to understand the design, even in a coarse form. You have to understand what the system you are evaluating does, what systems it talks to, and you have to understand its security policy. Otherwise, you can’t formulate attacks against it that are meaningful. Implementation bugs in code that are of no consequence are useless.

Critiquing the design, however, is usually not the majority of my personal workload in an application review. This is primarily because I rarely have the mandate to actually change fundamental design beyond making suggestions in a deliverable that are intended for long-term product driection. The exeception is if there is such an exceptionally egregious error that I can advise a third-party client (be it VC or a corporation) that there is a *serious* problem. If I’m working with a software vendor themselves, then it’s more an issue of, you guys are in big trouble. Often times, however, they can’t easily address it barring massive re-architecture.

That said, I didn’t do a particularly excellent job at explaining my arguments, while at the same time probably mis-characterized McGraw’s position somewhat. While I do think low-level implementation flaws are very important, one of my main contentions is that “design” vs. “implementation” itself is a false dichotomy. In essence I think the word “implementation” is wrong, as it encapsulates everything from extremely low-level detail (will this allocation cause regular TLB/cache misses or branch prediction pipeline stalls), to the design of expressions (do I use arithmetic or logical shift.. short circuit logic/tertriary operator?), algorithms (doubly linked list or hash table), functions (state machine or recursion ok?), classes (how much inheritence.. do i need polymorphism?), modules(do i expose internal state.. static data or not?), interfaces (how do i signify errors?), thread and synchronization design(consumer/producer, event loops?), and data structures(FIFO/splay tree/RDBMS?).

You can make security mistakes in *all* of those things, and we aren’t talking strcpy().

Or conversely, maybe some of these things are under the domain of design and not implementation. The point is that it’s not clear and fast where to draw the line really. If you look at data flow diagrams specifically, I don’t believe you see this level of detail, but it depends on the process you use. McGraw’s process is never explicitly documented in his books beyond a single page PDF, as (I believe) it’s essentially proprietary work product of Cigital.

That said, there is wisdom in your conclusion. Performing security assessment on a large and complicated system is an incredibly difficult task, especially given the compressed time lines and resources necessitated by the value the market current places on software security. The search space is too vast for any realistic hope of a full and exhaustive search.

Time management is, in essence, the name of the game.

We have different philosophies, and even possibly different mandates, but I think we both strive to deliver the most effective result for the time invested.

I understand McGraw’s concern about myopic focus on technical attacks, and that is a real risk when time is at a premium. However, at the same time, I think relegating implementation review to the domain of automatic analysis is essentially dangerously reckless optimism. But, it largely depends on where you draw the line.

Anyone who writes or reads enough code knows that the majority of the future anguish for the coders on a new project will come from failures of design. Since design cost is a counter-value, there is a kind of tensegrity that should yield an appropriate balance of design versus implementation time. Less experienced coders will tend to screw up that balancing act worse than journeymen. Those mistakes will tend to increase the total difficult of the project which is a primary factor in determining the locii of vulnerabilities. Overdone design will tend to rush the schedule and reduce the quality of peer review, which would support a researcher spreading a wide net to find low-hanging fruit. Underdone design will instead tend to give more time to each work item, but also to fail to handle some problems which must then be tackled by the developer. This would reward a researcher who focuses on the grinding gears where they don’t quite line up.

So from a certain argument, understanding the design issues can provide a clear path for finding the implementation issues. My problem with this perspective is that it aligns the evaluation process too neatly with the development, which tended to stunt my creativity as an analyst. McGraw points at the myopia that might come from focusing too hard on the bottom-up work, but on some level I think John might avoid making some kinds of mistakes that come from sympathy with the design. Instead, he seems to me to be saying, the very strong analyst works in an information space constructed of the *artifacts* of the design and implementation and all the tools used therein.

An artist, I think, might say that one is talking about the positive space (things the code does) and the other the negative space (things the code doesn’t do). My feeling is that the former is more approachable for novices and the latter is more powerful for initiates. Neither approach can avoid the reality that fully searching the space is untenable.

ObHoglund: Me too.

First, I think we agree far more than we disagree. My argument admittedly was all over the map, but here’s what I’m getting at:

I like to work from the code up. The code is just a language, and it necessarily explains what the system does. If you work (hard) at developing the skill set for it, you can develop mental models at higher and higher levels of abstraction by working from the bottom up.

Your philosophy, as I interpret it, seems to imply that this is impossible, and that implementation review is a context-agnostic exercise in rote pattern recognition.

I disagree. My preferred approach is obviously very time consuming and it is just one tool in the arsenal of a security practitioner, but I believe it requires a fundamentally different philosophy from the way in which you conceptualize code review.

It’s more a matter of approach, as we probably would agree to some extent that the essence of both top-tier vulnerability research and application security review is “understand the system first; find vulnerabilities second.”

As far as the 50/50 thing, it doesn’t concur with my experiences reviewing software, but I’m not sure if it’s a matter of us having subtly different definitions, confirmation/selection bias, or simply that one of us is wrong. (I hope it’s you.. I hate being wrong.) Unfortunately, the data in question is probably guarded behind 50 NDAs on either side.

BTW, Exploiting Software is a great book, and I’ve read it a couple of times, so no need to re-read it. :> (Hell, Hoglund and I ran in the same circles literally a decade ago, and we’ve both been exploiting software in various capacities for a living full-time since then. The ideas contained within aren’t exactly foreign to me.)

Anyway, I sentence you to go read a few million lines of code until you start seeing the forest from inside the trees. :>

Cheers,

John

Nice rant, but what exactly are you getting at here? I like defining an admittedly slippery slope between bugs and flaws precisely because people have been OVEREMPHASIZING the importance of code review and static analysis. My purpose is to get people’s faces up out of the code trough and into the design so they can find big picture design problems as well as stupid coding mistakes. Gotta do both.

The 50/50 thing comes from real data…both mine (actually at Cigital we used to tend to find more flaws than bugs, but these days the automated code review tools help push the numbers up on the bug end of things) and Mike Howard’s (yes, the evil empire has been doing this for a while and taking names).

You and I agree that in the end an attacker only needs to find a defect (be it a bug or a flaw) to sploit your ass silly. I sentence you to go read “Exploiting Software” until you either fall asleep or come up with another angle.

gem

Also, sorry I missed you last time you were up here. I was out of town, but I’m also deathly afraid of people. :>

As for the rest of it, well, I read the words but my thick skull was able to repel the invasion.

Don’t get me wrong; often I’m all for a healthy debate on disclosure practices, static versus dynamic analysis, fuzzing versus The Way Real Men Find Bugs, or any other of the fun things security geeks like to discuss.

But I just can’t dredge up the will right now. Hopefully I can dredge up a few more brain cells and try again later. So instead I’ll just stick to my comment on the introduction and mention it was at least a very /funny/ way of equating blogging with trolling.

Oh yeah — you had a typo:

s/Visio //g

There, fixed it for you.