There has been a recent flurry of activity regarding security assurance on a hush-hush open source mailing list I lurk on. The debate recently has to do with formal methods versus code scanning… apples and oranges in my view. However, there’s a new flurry of press over Coverity’s use of their tool to analyze well-known globs of open source. (One poster suggested that passing a scan like this with flying colors means security has been attained… argh!)

Some pointers:

From Slashdot
Posted by: kdawson, on 2008-01-09 01:20:00

Stony Stevenson alerts us to a US Department of Homeland Security program in which subcontractors have been examining FOSS source code for security vulnerabilities. InformationWeek.com takes a glass-half-empty approach to reporting the story, saying that for FOSS code [1]on average 1 line in 1000 contains a security bug. From the article: ‘A total of 7,826 open source project defects have been fixed through the Homeland Security review, or one every two hours since it was launched in 2006…’ ZDNet Australia prefers to emphasize those FOSS projects that [2]fixed every reported bug, thus achieving a clean bill of health according to DHS. These include PHP, Perl, Python, Postfix, and Samba.

Firstly, I am a big fan of code scanning and believe that use of static analysis tools should always be one of the basic security steps integrated into every SDLC. However, there are huge problems with declaring security after passing a code scan with an arbitrary tool and a random set of rules. The most obvious issue is that security defects come in two flavors—bugs and flaws—each accounting for roughly 50% of defects in practice. Code scanning tools can only find bugs. Here are two stupid examples for effect: can a code scanning tool determine that no user authentication was performed? How about whether or not a playback attack will work?

The second most obvious problem is that the list of rules enforced by a static analysis engine can never be complete. Discussion about this is left as an exercise for the reader.

Architectural risk analysis (crazily called “threat modeling” by Microsofties) is, like code scanning, an essential software security best practice. Formal methods are one way to go about attacking the flaw problem. In the US we rely on flakier heuristic-based approaches such as the one we use at Cigital. But no matter the approach, we can’t ignore the architecture.

References

1. http://www.informationweek.com/story/showArticle.jhtml?articleID=205600229&cid=RSSfeed_IWK_All
2. http://www.zdnet.com.au/news/security/soa/11-open-source-projects-pass-security-health-check/0,130061744,339284949,00.htm

We’re pleased to have a guest blogger for this Justice League entry. Michael Cohen is a Senior Security Consultant at Cigital where he is responsible for leading, assessing, architecting and implementing secure software for Fortune 500 companies. Michael also works with Cigital teams on enterprise-wide security solutions intended to improve an organization’s security posture and help them meet audit and regulatory requirements. Michael just gave a talk to the Washington, DC IASA chapter that was well received, and is now the subject of this entry:

When I hear software architects talk about the architecture they’ve crafted to depict the various structures and behaviors of a system, they point out interesting techniques they’ve applied that best convey how the system should work and be put together. An architect’s enthusiasm for the little details reveals a great sense of accomplishment and creativity, but most of all good architecture conveys sorely needed information in order to help those who develop, test and maintain the system. Sharing the tips and tricks gathered from the field is what helps our community move forward to building better software. A classic example of this is the Design Patterns book written by the Gang of Four.

Not too long ago I was also sharing my ideas on architecture and security at a local IASA chapter here in Washington, DC. The group was a crowd of like-minded architects who work for large Fortune 500 companies, government agencies, and promising local startups. My topic was pragmatic secure architecture. The basic idea was to look at some real ways to incorporate security into architecture using Cigital’s risk management and threat modeling practices. You can find the slides for my presentation here.

For the uninitiated, threat modeling is a way of depicting where threats (think malicious people, attackers, and so on) can touch a software architecture and how they may be able to exploit critical assets using various attack patterns. Threat modeling is valuable for determining an architecture’s security posture. In addition, identifying risks in user requirements and business goals, and tying those risks to a threat model results in a map of how design flaws impact the system, its users and the overall business. Threat models coupled with identified high-level risks are a great way to get other stakeholders involved with security decisions. And mind you, these are stakeholders who would otherwise be unable to contribute and supply critical feedback.

The attendees at the chapter meeting were glad they attended the presentation and heard something worthwhile that they could use in their daily architectural activities. Many people brought up interesting points about how to best protect critical assets, what a real risk to a system is, and what is considered a good enough mitigation. What I found particularly interesting was how threat modeling provided a way for everyone to contribute interesting ideas about where security vulnerabilities may exist and how they could be mitigated (which, if you think about it, is the entire point of threat models).

I encourage any architect to share their ideas on building a better architecture with their peers, whether it be at a local organization or at a conference. As a senior security consultant at Cigital, I like to take shared ideas and mold them into my own unique way of thinking about the world. The best results come when I can apply new ideas to my daily activities as I help our customers assess and create more secure software.

… On an entirely separate note, McGraw still owes me money. I’m watching you, Gary.

Technorati Tags: software architecture, software quality, software security, touchpoints

This is the foreword that I wrote for Brian Chess and Jacob West’s excellent new book Secure Programming with Static Analysis. I recommend this book for all software security practitioners. Developers, in particular, will find the book extremely helpful. For more on other books in the software security series, see http://www.buildingsecurityin.com.

On the first day of class, mechanical engineers learn a critical lesson—pay attention and learn this stuff or the bridge you build could fall down. This lesson is most powerfully illustrated by a video of the Tacoma Narrows Bridge shaking itself to death. Figure 0-1 shows a 600-foot section of the bridge falling into the water in 1940. By contrast, on the first day of software engineering class, budding developers are taught that they can build anything that they can dream of. They usually start with “hello world.”

Figure 0-1: A 600-foot section of the Tacoma Narrows bridge crashes into Puget Sound as the bridge twists and torques itself to death. Mechanical engineers are warned early on that this can happen if they don’t practice good engineering.

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.

Much of today’s software is so fragile that it barely functions properly when its environment is pristine and predictable. If the environment that our fragile software runs in turns out to be pugnacious and pernicious (as much of the Internet environment turns out to be) software fails spectacularly, splashing into the metaphorical Puget Sound.

The biggest problem in computer security today is that most systems aren’t constructed with security in mind. Reactive network technologies such as firewalls can help alleviate obvious script kiddie attacks on servers, but they do nothing to address the real security problem—bad software. If we want to solve the computer security problem, we need to do more to build secure software.

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—code review with a static analysis tool.

As practitioners become aware of software security’s importance, they are increasingly adopting and evolving a set of best practices to address the problem. Microsoft has carried out a noteworthy effort under its Trustworthy Computing Initiative. Many Cigital customers are in the midst of enterprise scale software security initiatives. Most approaches in practice today encompass training for developers, testers, and architects; analysis and auditing of software artifacts; and security engineering. There’s no substitute for working software security as deeply into the development process as possible and taking advantage of the engineering lessons software practitioners have learned over the years.

In my book Software Security, I introduce a set of seven best practices called touchpoints. Putting software security into practice requires making some changes to the way most organizations build software. The good news is that these changes don’t need to be fundamental, earth shattering, or cost prohibitive. In fact, adopting a straightforward set of engineering best practices, designed in such a way that security can be interleaved into existing development processes, is often all it takes.

Figure 0-2 specifies the software security touchpoints and shows how software practitioners can apply them to the various software artifacts produced during software development. This means understanding how to work security engineering into requirements, architecture, design, coding, testing, validation, measurement, and maintenance.

Figure 0-2: The software security touchpoints as introduced and fleshed out in Software Security: Building Security In.

Some touchpoints are by their very nature more powerful than others. Adopting the most powerful ones first is only prudent. The top two touchpoints are Code review with a static analysis tool, and Architectural risk analysis. This book is all about the first.

All software projects produce at least one artifact—code. This fact moves code review to the number one slot on our list. At the code level, the focus is on implementation bugs, especially those that static analysis tools that scan source code for common vulnerabilities can discover. Several tools vendors now address this space, including Fortify Software the company that Brian and Jacob work for.

Implementation bugs are both numerous and common (just like real bugs in the Virginia countryside) and include nasty creatures like the notorious buffer overflow, which owes its existence to the use (or misuse) of vulnerable APIs (e.g., gets(), strcpy(), and so on in C). Code review processes, both manual and (even more important) automated with a static analysis tool, attempt to identify security bugs prior to the software’s release.

Of course, no single technique is a silver bullet. Code review is a necessary but not sufficient practice for achieving secure software. Security bugs (especially in C and C++) are a real problem, but architectural flaws are just as big a problem. Doing code review alone is an extremely useful activity, but given that this kind of review can only identify bugs, the best a code review can uncover is around 50% of the security problems. Architectural problems are very difficult (and mostly impossible) to find by staring at code. This is especially true for modern systems made of hundreds of thousands of lines of code. A comprehensive approach to software security involves holistically combining both code review and architectural analysis.

By its very nature, code review requires knowledge of code. An infosec practitioner with little experience writing and compiling software is going to be of little use during a code review. The code review step is best left in the hands of the members of the development organization, especially if they are armed with a modern source code analysis tool. With the exception of information security people who are highly experienced in programming languages and code-level vulnerability resolution, there is no natural fit for network security expertise during the code review phase. This may come as a great surprise to those organizations currently attempting to impose software security on their enterprises through the infosec division. Even though the idea of security enforcement is solid, making enforcement at the code level successful when it comes to code review requires real hands-on experience with code.

The problem is that most developers have little idea what bugs to look for, or what to do about bugs if they do happen find them. That’s where this book, Secure Programming with Static Analysis, comes in. The book that you have in your hands is the most advanced work on static analysis and code review for security ever released. It teaches you not only what the bugs are (what I sometimes call the “bug parade” approach to software security), but how to find them with modern static analysis tools, and more importantly what to do to correct them. By putting the lessons in this book into practice, you can go a long way toward helping to solve the software security problem.

You can purchase a copy of Secure Programming with Static Analysis from Amazon.

Technorati Tags: touchpoints, software security, static anlaysis, Brian Chess, Jacob West

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

Recently, someone at Cigital asked me to characterize the difference between our approach to software security and Microsoft’s. Before I get to comparing things I want to note that we’re big fans of Microsoft when it comes to software security. Under the leadership of Michael Howard and Steve Lipner, Microsoft has made great progress in software security over the last few years. There are many lessons that we can all learn from what they’re doing.

That said, Microsoft’s approach to software security does differ from ours in a few fundamental ways that are worth discussing.

The biggest difference to highlight is that their approach has a static threat model that is great for operating system vendors. People in other sectors such as finance or hospitality will not have the same kind of threats that Microsoft does. In this case, what I mean by threat is an actor or agent who causes risk. That is, your possible attacker(s). Building a threat model that is tailored for a customer is a key aspect of our approach at Cigital. Microsoft has already done this for their business, but chances are you are not an operating system vendor.

At the heart of Cigital’s approach to software security are a number of best practices that we call the touchpoints. You can read about the touchpoints in my book Software Security. The top two touchpoints are “Architectural Risk Analysis” which helps uncover and mitigate flaws at the design and architecture level, and “Code Review with a Static Analysis Tool” which helps ferret out bugs in code at the implementation level.

Our approach to Architectural Risk Analysis is much better suited to finding new risks not yet ever seen before than Microsoft’s list-based approach. Undiscovered new risks are the kinds of things that lead to 0days and help you to wind up on the front page of the Wall Street Journal. Our three-phase analysis goes way past Microsoft’s STRIDE model with regard to dependencies and ambiguities. Our approach to risk is much more sophisticated and grounded in business as well. The reasons for this probably have to do with having to demonstrate to our customers the importance of the things we’re finding. By contrast, Microsoft doesn’t need to be convinced to fix security problems, Bill Gates already said that they have to.

When it comes to code review, Microsoft and Cigital approaches are similar, but Microsoft leverages proprietary unreleased tools that are not available outside of Microsoft. (Many of you will have heard of Prefix…Prefast, now available with some Microsoft compilers, is not the same thing.) The Cigital approach leverages customizable commercial tools and a best of breed approach. We often use Fortify’s supremely good static analysis tool, but we have been known to wield Coverity’s tool and Klokwork’s tool as well, depending on the situation. In both cases, however, the use of a static analysis tool to find bugs is absolutely critical.

Our approach to security testing is much more white box than Microsoft’s is, and involves using the risks uncovered during Architectural Risk Analysis to drive inside-out test planning. Microsoft’s approach is grammar driven and focused on APIs. The fact that James Whittaker now works for Microsoft is likely to help to evolve Microsoft’s approach to security testing, but James has a tendency to start with API fault injection as well (see his great book How to Break Software Security).

As far as I know, Microsoft does next to nothing at the requirements level. At Cigital, we have a decent approach to security requirements that covers both functional security mechanisms and abuse cases.

There are many other differences between our approaches, but those are the highlights. The most interesting thing is just how closely aligned the two approaches are.

Technorati Tags: software security, microsoft, stride, sdl

If I were to say penetration testing, what would you expect? After conversations with lots of colleagues and friends it’s become fairly clear to me that the term is massively overloaded. It actually got me thinking about the evolution of pen-testing over the last several years. And I’m not going to preach from the you-need-design-and-code-review-too pulpit. I’m just gonna talk about the innards of the pen-test itself (breaking a running system).

The old-school notion of a pen-test was one where you’d hire a bunch of l33+ h4×0r5 and turn them loose on a system to see what they are able to bust. The general idea here was to simulate a real-world attack scenario (black-box pen-test). Given adequate time, Cheetos^® and Red Bull^® you’ll probably be left with some findings that are interesting. But take a closer look at the breakdown of how those testers spent their time. Those guys likely spent a ton of their time trying to figure out how the app works, trolling for non-obvious interfaces and partially reverse-engineering the logic of the app. When you’re paying by the hour, this is bad news since they didn’t spend as much time as they could have in actually trying to break the app (they spent a bunch in just getting their arms around it.)

Evolving from these obvious limitations in the completely black-box approach the notion of the “pen-test with code” was born. This was a similar scene, but instead of poking at the running app as much, the testers would go and read code. While the testers are still at arm’s length from the dev team, it’s still better since access to the code gives a truer picture of what’s actually happening under the hood without time spent on reverse engineering. Sometimes, there would even be design docs available which really helped move things along. In the end, this is close to the modern-day version of what many expect when they buy a “pen-test.”

The major weakness of this style of pen-test is that there’s often no business context to ground the direction of the testing (on which aspects of the system you concentrate) or to baseline the value of the findings (to the company using the app, what do the discovered exploits really mean?) Some pen-testers are starting to bridge the technical-to-business gap, but they’re definitely in the minority. This step in the advancement of the pen-test is definitely a step in the right direction since it focuses the testers on generating and prioritizing findings that show demonstrable impact to your core business (as opposed to sheets of meaningless XSS vulns that are all prioritized “high” since XSS is bad.) The pen-tester gets to concentrate on breaking business logic in your application and scheming about combinations of technical vulns that lead to an interesting business problem. You’ll still get all the technical vulns, they’ll just be low priority if they can’t directly contribute to a bigger problem. Since this all plays into making risk management decisions, I call this style of white-box pen-testing the “risk-based pen-test.”

If you’re using pen-test today, you really want as close to a risk-based pen-test as you can get. Although I have heard a few reasons why you might not:

• “I don’t have access to code or design docs.” I hear this reason all the time as justification for why a black-box approach is used. In the end, even if you don’t have code, someone has gotta know something about how the application actually works. Even if it’s only from a user or sysadmin perspective, it goes miles to setting the testers off in the right direction. Find those people and link them up with the pen-testers! And business risk mapping is still possible even without code (but you’ll probably need at least ad hoc design info).
• “I use black-box pen-test nowadays as a way to simulate real-world attacks.” This notion is just off-base due, perhaps, to the lack of understanding about real-world attacks. Yes, the people “in the wild” that might attack you will have a similar skill-set to your pen-testers. The kicker is that the time available to an outside attacker is virtually infinite compared to that of a for-hire pen-tester. When it comes down to exploiting software often it’s just a matter of how much time you spend bashing your head against the problem. Outsiders can spend 2 hours a day for 6 months working on getting a single exploit working. Your pen-testers have 8 hours a day for a week to find lots of impressive results. Thus, cheat the problem by giving the pen-testers all the info you have.

In any case, let’s get back to talking about that notion of the risk-based pen-test. When I think about the requisite skills to complete that job I see many similarities to what QA folks do on a routine basis. Foremost, the QA testers will already know the application components and UIs. They should know the business value of the app and in many cases they’ll also know how the business logic of the app is supposed to work. And also, they are routinely asked to assess the specific business impact of problems in the application (they do it every time they open a bug and assign a priority.) That’s a huge advantage over someone from the “outside” coming into a pen-test engagement. Now what about differences? The biggest red-flag is that the QA people aren’t trained to attack applications to find security flaws. That’s a big disadvantage since you need those skills in order to be even remotely effective at a pen-test. But do keep in mind, QA folks are very much trained to break applications in general (it is, in fact, their job.)

So where are we going with this? Simple: let’s give the pen-testing responsibility to the QA team. They’ve already got a leg-up since they know the application. To counter the point about them not being trained in security attacks employ two simple techniques: tools and training. Some of the automated pen-testing tools out there are really great now. They’re basically extremely potent packages of electronic subject-matter expertise. Now, I would never advocate just buying a tool and hitting the “go” button and calling the job done (you don’t get very good results at all this way.) Enter the training. The automated pen-testing tools, in many ways, are very similar to other types of tools in a QA tester’s belt. They run a series of attack test-cases and report vulnerabilities when a test fails (this is a massive oversimplification of what they’re doing under the hood, but in terms of usability, the analogy holds.) So, train the QA testers on effectively using those tools. Teach them about how to feed application-specific details to the tools to make sure your coverage is high and ensure the results are more accurate.

Further, teach them about the classic notion of security testing (starting with requirements and deriving test-cases to ensure that functional requirements are implemented securely) and show them how to automate it with the tooling. In fact, that’s where this is all ending up: a risk-based security test with a wide blast-radius for getting the bulk of the benefit of a pen-test. It’s cheaper in the long-run (front-loaded cost for buying tools and building the internal skill vs. repeated, indefinite fixed-price cost.) In terms of effectiveness vs. an external pen-test, it’s definitely on the positive side of the 80%-20% rule (and all the things you might miss in that 20% will likely be caught by code review or architecture analysis.) It’s even “faster” in the sense that an organization could move through each assessment more quickly, thus enabling more assessments within a given timeframe.

In summary, I see the future of pen-testing as a push toward QA environments. Since the notion of a code review and architecture review are becoming more mainstream, this makes sense. Why continue to spend a lot on a service that ultimately should be used as a sanity-check of the running system?

Red Bull^® and Cheetos^® are trademarks of their respective companies.

Technorati Tags: penetration testing, software security