There are three new books (recently released) that are worth a look. Once is an absolute necessity for any security practitioner. The others may be interesting for some readers of the blog.

The book that you MUST READ RIGHT NOW is the second edition of Ross Anderson’s Security Engineering book. Ross did a complete pass on his classic tome and somehow made it even better. It also comes in handy as a weapon as it is so heavy. Books like Ross’s are a refreshing reality check from the usual pablum published in computer security.

Simply put, this is a must read book for every security professional. I don’t have my real copy yet from the publisher (but they say one is on the way), but I did take a close look through the manuscript. Ross retains his number one slot on my list of top 5 things every software security person should read.

Incidentally, I interviewed Ross for Silver Bullet last year (in April). Ross’s episode is the most popular of all 24 episodes released to date with over 18,000 downloads. You might want to give that a listen as well.

The other two books that are worth a look are Crimeware and The New School of Information Security. Lets cover them in reverse.

The New School of Information Security is a book worth buying for the cover alone. I know of no other computer security book with a Kandinski on the front. Even though I know Adam Shostack from way back (and never could have predicted that he would become a Microsoft guy), I saw his book at RSA, bought it for the cover, and only then discovered that he was the author! My plan was to give the book to a good friend who I know is a huge Kandinski fan. On the way to complete that errand, I had a chance to look though the book and now I need a copy of my own! If you’re a follower of the economics of security school (which Ross and Bruce Schneier have helped spearhead), you’ll like this book.

Crimeware is an academic tome written by my friend Markus Jakobsson. I contributed a chapter on software security bug taxonomy. My copy showed up last night, and I have earmarked more time to read it thoroughly. The enemy has changed over the last decade, and criminals are bringing the game to a new level.

Spring may not be the best reading time, but it does appear to be the best time for a crop of interesting new security books!

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

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 my April darkreading column, “Want Turns to Need,” I describe the state of the market for software security. I am very much optimistic about the software security space. In a few short years, we have created a space with a small ($250-275 million) but growing market niche. Last year, the tools market doubled in size, with services also showing very strong growth. Weighing in at about a quarter billion dollars, software security is a field that can no longer be ignored. As a field, we’ve successfully moved past philosophy and well into action. It’s a good time to make sure your firm is on board.

Back when I helped to invent software security in 1997 (after writing Java Security with Ed Felten from Princeton), there were zero books and only a few papers. That’s one of the reasons John Viega and I wrote Building Secure Software–we wanted to write something for software developers and architects interested in building security in. In the eight years since then, the field has blossomed. Today, an entire shelf full of books exists. Here’s a chronological list of eleven good ones (including three that I wrote):

• Building Secure Software (Viega and McGraw, 2001)
• Security Engineering (Anderson, 2001)
• Writing Secure Code (Howard and LeBlanc, 2002)
• How to Break Software Security (Whittaker and Thompson, 2003)
• Exploiting Software (Hoglund and McGraw, 2004)
• 19 Deadly Sins of Software Security (Howard, LeBlanc, and Viega, 2005)
• Software Security (McGraw, 2006)
• The Security Development Lifecycle (Howard and Lipner, 2006)
• The Art of Software Security Testing (Wysopl, et al., 2006)
• The Art of Software Security Assessment (Dowd, et al., 2006)
• Foundations of Security (Daswani, 2007)

Even with all of this progress, many people remain pessimistic about the space. Though the Yankee Group estimates that the entire market is between $250-275 million dollars, they state the case in pessimistic terms. I am much more optimistic about the growth of the field than Andrew Jaquith appears to be from the title of his report (though check out his excellent new book on security metrics!).

In my darkreading article, I describe why software security is transforming from a nice-to-have into a necessity. Many companies are trying to determine how to get started. The article goes on to describe software security tools (including badness-ometers and source code analysis tools. The combined market for these tools was between $90 and $100 million in 2006. I believe that the black box testing tools are driving demand for solutions that do more than identify the problem. Source code analysis tools are selling into this demand. This is great news for companies like Fortify and Ounce Labs.

Software security services are equal in tools to revenue, with numbers between $80 and $120 million in 2006. These services ran a large gamut, from simple minded penetration testing (usually wielding a black box testing tool) at one end, all the way through sophisticated enterprise initiatives at the other. In 2006, services surrounding more complete software security initiatives at the enterprise level came into vogue. These large scale initiatives include training for thousands of developers, the creation of enterprise-specific knowledge and guidance, and the integration of software security best practices (which I call the touchpoints) into the software development lifecycle. Cigital specializes in the strategic delivery of enterprise software security initiatives.

Check out the darkreading column for a list of ways to get started in software security. I briefly touch on:

• Using badness-ometers to make the problem apparent
• Hiring outside help to carry out deeper analysis of critical programs
• Introducing code review to the dev team
• Basic software security training

But by far, the most efficient way to approach software security is through a well planned enterprise software security initiative. We have several such initiatives underway at a number of our most important customers. This is no trivial undertaking, but it has always resulted in marked improvement for Cigital customers.

Software security is quickly becoming a business necessity. SOX and PCI compliance activities serve to help corporations better understand their software risk. Because the impact of software failure (maliciously caused or otherwise) is great, many corporations are already working dilligently on software security. The time has come for everyone to get started.

Technorati Tags: software security, essf, tools, services

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

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

The PCAOB is introducing new guidance to help lower the overall cost and, presumably, increase the effectiveness of SOX 404 audits. It needs to use this opportunity to help fix some root causes, not just tell us how to find more symptoms.

This past December, the PCAOB announced that it would propose for public comment a “new standard on auditing internal control…designed to focus the auditor on the most important matters, increasing the likelihood that material weaknesses will be found…” The proposal itself can be found at http://www.pcaobus.org/Rules/Docket_021/2006-12-19_Release_No._2006-007.pdf.

Starting on page 93 of the document, there is a section on “Benchmarking of Automated Controls.” It includes guidance like “Entirely automated application controls are generally not subject to breakdowns due to human failure,” which is clearly not true since bad input makes functional application security controls fail all the time. Telling auditors that automated application controls automatically get a gold star is not a step in the right direction.

It does go on to suggest that the benchmarking strategy take into account the importance of the effect of related files, tables, data, and parameters on the consistent and effective functioning of the automated application. That’s a good thing.

The document then suggests that “If general controls over program changes, access to programs, and computer operations are effective and continue to be tested, and if the auditor verifies that the automated application control has not changed since the auditor established a baseline (i.e., last tested the application control), the auditor may conclude that the automated application control continues to be effective without repeating the prior year’s specific tests of the operation of the automated application control.”

So, never mind that new attacks are discovered with unnerving frequency and that perfectly good code can suddenly become not so great (think crypto algorithms), the apparent recommendation is that if you didn’t or couldn’t poke hard enough to break it over some time period, then it’s okay to skip it later. Approaches like this where we’re considering only functional changes and not testing skill and depth can’t be effective.

How many times has someone walked up and spotted a problem you failed to notice time and time again. As organizations periodically change auditing firms, expect huge increases in reported problems.

The proposed guidance gives the following factors to use when deciding to use benchmarking:

• The extent to which the application control can be matched to a defined program within an application;
• The extent to which the application is stable (i.e., there are few changes from period to period); and
• The availability and reliability of a report of the compilation dates of the programs placed in production. (This information may be used as evidence that controls within the program have not changed.)

This wording is still neglecting changes on the threat side of the equation. Just as many castles were considered impregnable until about five seconds before the first cannonball hit, many lines of code were considered secure right up to the point where the breach story appeared in the newspaper.

The guidance gives the following factors to use when deciding whether to reestablish the benchmarking baseline:

• The effectiveness of the IT control environment, including controls over application and system software acquisition and maintenance, access controls and computer operations;
• The auditor’s understanding of the nature of changes, if any, on the specific programs that contain the controls;
• The nature and timing of other related tests;
• The consequences of errors associated with the application control that was benchmarked; and
• Whether the control is sensitive to other business factors that may have changed. For example, an automated control may have been designed with the assumption that only positive amounts will exist in a file. Such a control would no longer be effective if negative amounts (credits) begin to be posted to the account.

Okay, so if I know that most auditors and organizations use COSO as a governance model, and COBIT 4 to interpret COSO to arrive some IT control objectives, and I consider AI2, Acquire and maintain application software, important to my environment, then I might understand what “controls over application and system software acquisition and maintenance” means above. And, I might even read COBIT and see AI2.4, Application Security and Availability, which states “Address application security and availability requirements in response to identified risks, in line with data classification, the organization’s information security architecture and risk profile. Issues to consider include access rights and privilege management, protection of sensitive information at all stages, authentication and transaction integrity, and automatic recovery.” Oh wait, I only need security software, not software security. Sigh. Another opportunity missed.

There is a need here for any words that introduce something like the following:

The customer may have written their own software that is directly used in the financial reporting process and you, the auditor, should be aware not only of the software’s functional controls (e.g., I&A, encryption, entitlements), but you must also accrue confidence that their internal development practices and testing are sufficient to produce quality software that has at least some capability to protect itself from attack even in the event of catastrophic failures other general and IT security controls being considered as part of this SOX audit. While security software may comprise the majority of IT security controls, software security is the property that gives us confidence in their continued successful operation even in the certainty of ongoing attack. You must use a risk-based approach to accruing confidence, focusing on relevant factors that have a material effect on the software’s ability to meet business objectives even in an overtly hostile environment.

Now we’re thinking more about the problem and less about the symptoms.

Technorati Tags: software security