[This a guest post by Cigital’s Troy Jones, written in reference to episode 25 of The Silver Bullet Security Podcast, an interview with Jon Swartz.]

Gary,

Listening to your podcast with Jon Swartz today, you briefly mentioned Ralph Nader a couple of times. You said almost in jest, that “… we need a Ralph Nader for Security.” This got me thinking about a recent brownbag you gave on Software Security, where you mentioned that clients have implied needs for security but may not explicitly state their needs. I think the concept of implied need for software security and what Nader did to impact auto safety are entirely related.

Back in the 60’s people expected that the cars they bought were “safe”. Safety was not a marketing angle used by the car companies, and people did not shop around for the safest cars, but no one would buy an “unsafe” car. They just trusted and expected that the big auto makers had already thought about safety and “built it in” because no reputable car manufacturer would sell an “unsafe” car, would they?

It was not until Ralph Nader wrote “Unsafe at any Speed” that people began to question the safety of the cars they bought. When it became apparent that Detroit was selling them unsafe cars, the public outcry (not the book itself) prompted congress to act to enable novel new safety standards like seatbelts, bumpers that actually worked, and eventually crumple zones and air bags. So, people had an implied need for auto safety, but did not express that need until they became educated to the fact that they were not safe. Then they expressed their newfound need for safety to the politicians and also voted with their pocket books, buying safer cars. When consumers were provided with valid safety evaluations, from Consumer Reports and the National Highway Traffic Safety Commission, they changed their buying habits. Auto manufacturers (eventually) changed their approach in response. After years of fighting increasingly stringent safety regulations, they now compete to be able to advertise that their minivan has the highest safety rating.

So, what does all this have to do with software security? One point is that “safe” is relative term. You are safe if you feel safe. It is hard or impossible to know if you are actually safe but it is easy to have your illusion of safety shattered by hard facts. Your average consumer today may be oblivious or vaguely concerned about software security, but they don’t have the information necessary to make discriminating choices about what software to use or buy and to stay away from. There is no Internet Highway Safety Commission and no ratings to refer to. Without this information, people are unable to express their implicit needs. They are driving metaphorical Corvairs and they don’t even know it.

Another point is that safety and security are both relative. The worst Yugoslavian POS manufactured today is probably much safer than any car rolling off the Detroit auto lines in 1965. It is conceivable that 50 years from now people will look back and wonder how we survived without collision avoiding auto-pilots in our cars! People’s expectations for “safety” evolve over time and hopefully their actual safety improves as cars are better engineered, but there is no endpoint- no “safety finish line”. I think this analogy applies to “Software Security”. Software should get more secure over time if security is considered an important goal, but software will never be 100% secure. Good for job security but bad for everyone who depends on software to work securely.

A third point is that the initial reaction to unsafe autos was to build safer highways. Wide-open, straight, and fast highways seemed to be more cost effective than engineering better automobiles. It was not until highway traffic deaths began to skyrocket that everyone realized how effective automobiles are at killing the occupants involved in an accident at 75 MPH with no seat belts. The same approach has been taken on the internet. Bigger pipes and better firewalls should take care of the problem. No need to design and build more secure software! But the common folk will eventually realize that building a super information highway to their most confidential data has lots of unintended negative consequences, especially when it is so easy for the crooks to get past the vigilant but not-too-bright night watchman.

The last point I would make is that it took a fairly long time and a number of contributing factors for something to be done about auto safety. While Nader’s book was certainly a catalyst, it was not the “Auto Safety Pearl Harbor”. He merely recognized and assembled the information in a concise format that allowed people to understand and take action against a problem that had been growing worse for a long time. My guess is that the same will be true for software security. There will not be a “Software Security Pearl Harbor”. But through your continued evangelizing, through books like Jon Swartz’s “Zero Day Threat” and by their own negative experiences, people will eventually realize that something has to change and will demand action from software vendors, perhaps increased regulation from Congress, and maybe even a rating system to identify the worst offenders and the most secure software available so that they can make better choices. I am convinced that attitudes will begin to change soon, as the current rate of increase in cyber-crime has us on a trajectory to reach 1% of total GDP with 4 years. If that happens, it will definitely get the attention of quite a few people and may drive the expression of latent needs for software security.

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!

Some people start “Security Testing” by buying and using a pen-test tool on project. Such tools uncover security vulnerabilities (though they seldom help with root cause analysis or even obtaining double-digit code coverage).

These tools are degenerate, at best, in facilitating a security testing strategy. Why? Because, these tools are “black box” tools. What are black box tools?

The term “black box” stems from old testing literature and means “without internal knowledge”. An external perspective has always excluded “code” but sometimes goes as far as (in my opinion appropriately) software design. Obviously, you need to know something about the application’s architecture and design to test it though and the slope gets slippery.

In the realm of penetration testing, the term “black box” often has meaning beyond the tester’s knowledge of the product. OSSTM defines “black box” to mean that neither attacker nor defender are given knowledge of each other. They mean for this test procedure to accurately represent the kinds of opportunities, need for stealth, accessibility, and exploit that a real attacker would have, and also to evaluate the defender’s abilities to identify and prevent or recover from attack.

Because black box tools to a large extent run canned tests they will not satisfy my security testing goal (see previous entry) of having run tests that one traces back to requirements. ‘Requirements that one created as a result of doing risk analysis that determines exactly what behaviors (and their impacts) should be avoided were the software attacked.

Arguably, security folk have “cached” this risk analysis and these implicit requirements in the pen testing tool. Fine, this is that small benefit that I mentioned pen tests do provide. And, they DO find bugs. Again, this is at best a degenerate case of security testing in the same way running a fuzz testing tool is a degenerate way of conducting functional testing.

For QA folk wary of accepting the previous statement, it will suffice to say that you wouldn’t defend your job based on achieving less than fifty percent coverage would you?

Vendors have begun using hybrid approaches (this will only become more common). Do these approaches solve our coverage problem and allay our concerns?

I demo’d Compuware’s DevPartner, which has a poorly advertised (and perhaps now nacent) security scanning capability, a few years back and was pretty impressed with the start they had made in hybrid .NET analysis. I’m not sure where it’s gone since then. Fortify’s PTA also combines static and dynamic analyses to help prioritize static findings and provide root cause analysis for dynamic ones.

These hybrid tools don’t get our security testers off the hook either though, as they’re still not addressing the project-specific risk analysis nor are they anchoring tests in requirements.

I have been writing a monthly column on computer security and software security since October 2004. In the beginning, the column appeared in Network magazine. Later, that magazine was eaten by IT Architect. Here’s a set of pointers to those early articles:

• Who Should Do Security? (October 2004)
• Application Security Testing Tools: Worth the Money? (November 2004)
• How Do Real Bad Guys Break Software? (December 2004)
• Innovative Rootkits: The Ultimate Weapon? (January 2005)
• Are We In a Computer Security Renaissance? (February 2005)
• Where Does Trust Come From? (March 2005)
• Is Your Mac Really More Secure? (April 2005)
• How Does Security Fit With Engineering? (May 2005)
• Are Cell Phones the Next Target? (June 2005)
• Is Penetration Testing a Good Idea? (July 2005)
• Is VoIP Secure Enough For Prime Time? (August 2005)
• Is Cisco Naked? (September 2005)
• How Bad Is Intrusion Detection? (October 2005)
• Is Security Really About Getting Nothing Done? (November 2005)
• When Does Security Cross the Line? (December 2005)
• Is Sony BMG Run By Malicious Hackers? (January 2006)
• Is Application Security Training Worth the Money? (February 2006)
• How Flawed Is Microsoft? (March 2006)

We all know what’s happening to magazines and newspapers, though, don’t we–they’re turning to bits. When CMP killed IT Architect magazine (along with most of the rest of their paper publications), they repurposed much of the content into websites. I started writing for darkreading.com from the very beginning. Here’s a set of pointers to the darkreading articles:

• Microsoft’s Missed Opportunity (May 3, 2006)
• New Terrorist Profile: Phone Users (June 13, 2006)
• If You Build It, They’ll Crash It (July 7, 2006)
• Google is Evil (August 4, 2006)
• Keep Your Laws Off My Security (September 7, 2006)
• Diebold Disses Democracy (October 9, 2006)
• Boarding-Pass Brouhaha (November 2, 2006)
• Foxy Vista Henhouse (December 11, 2006)
• Hurray for Hollywood!? (January 12, 2007)
• Security’s Symbiosis (February 27, 2007)
• Compliance As Kick-Starter (March 12, 2007)
• Want Turns to Need (April 20, 2007)
• Certifiable (May 9, 2007)
• JSON, Ajax & Web 2.0 (June 7, 2007)
• Consolidate This (July 12, 2007)
• The Ultimate Insider (August 14, 2007)
• Mobile Insecurity (September 14, 2007)
• Online Games & the Law (October 11, 2007)
• Beyond the PCI Band-Aid (December 10, 2007)
• Software Security Strategies (January 9, 2008)
• The Truth Behind Code Analysis (February 13, 2008)

Just recently, I decided to move my monthly column to informIT. The readership is much larger, and I like the affiliation with the company who publishes my books. As part of that move, you can also expect to see Silver Bullet syndicated through informIT as well. You can help me make the move a success by keeping up with my column through informIT. (We’re also planning an RSS feed for articles too, so watch for that as well.)

The first column for informIT is just as much about business as it is about technology. One of the issues we constantly face at Cigital is the problem of helping our customers sell the idea of software security best practices up the chain. A common (and misguided) view is that software security best practices increase development time and add cost. As you can see in my first column, that’s simply not true. Here’s a pointer:

Software [In]security: Paying for Secure Software

I’m very much interested in your feedback on my column and any suggestions you have for topics. Feel free to use the forum below to get in touch. Thanks for reading!

Gunnar Peterson wrote an excellent post lamenting the lack of market forces in the security space.

I don’t know when we’ll see such market forces affecting companies but do agree they would have a positive impact. Certainly, I get why the security space hasn’t been subject to market forces yet though:

• People haven’t historically been ready to pay for it
• Companies haven’t entered the market with something valuable enough to invest in

First: what people are willing to pay for. Simple question: if a development team has a $10M budget, how much does it, say, spend on quality? 10-40%? OK. How much does it spend on software security?

Second: The security space, at least with respect to Software or Application Security, has indeed moved beyond its purely missionary roots: people know they face a problem. People do not, however, know what to do about it.

Lack of direction hasn’t resulted from the vendors’ failed productization of a tool set or services though. No, it’s resulted from the lack of mature solutions in the space. Penetration testing companies were gobbled up last year but my experience has been that, for the most part, customers haven’t been willing to invest in these tools far beyond their initial purchases and the smallest amount of shepherding.

In fact, most organizations I’m working with have seen either a reduction in reliance on or an outright backlash towards penetration testing. Use of static analysis tools and code review, while on the rise, has not reached ubiquity in response (We’ve yet to see what will happen in a broader context, having only completed what I consider to be the early-adopter phase).

What do we do about it? Partnering more closely with customers has been something I’ve felt very strongly about. Listening more closely to them remains crucial. Even involvement at this level can be tricky to fund at all but the most interested customers.

There’s work to do as vendors too. Because, while we’re through the missionary phase, we’re not through the education phase in security. We must spend more time helping clients understand what attainable next steps look like for them. Moreover, I think we have to work with them to solve some of the problems we’ve avoided: we need to clarify salient next steps ;-)

How are we really going to get enough security knowledge in the hands of developers to change their behavior in a sustainable way? How are we going to scale code analysis so that it has some of depth of expertise, manually applied, but all of the consistency and speed of automation?

Technorati Tags: software security

I absolutely enjoyed the insight shown by Thomas Wailgum in his recent article “How TJX Avoided Wall Street’s Wrath“, mostly because I have long been in complete agreement with the premise.

With respect to security professionals, unfortunately, TJX now appears to be “the one that got away.” Let me explain, with tongue planted firmly in cheek.

If you’re in the business of providing discount items and the economy is a little weak, then business will be good. Apparently, it won’t matter that you’ve had a mishap or two with the data entrusted to you. It has always been my contention that only a small minority of people really understand the impact of stolen personal data and, even amongst most the people who do “get it,” the theft of nearly 100 million records of personal data is almost meaningless in its enormity. The victims are worried only about one record — theirs. Either it got stolen or it didn’t. And, if it did, it’ll get abused or it won’t. And, if it does, there is an ingrained belief the credit card company will “take care of it.”

Besides, there’s a huge sale and my niece needs galoshes — the green ones that look like frogs.

Yes, I believe that, as a rule, people care about the persona of the organizations they patronize. On the other hand, I believe we are at a point where the idea that “Stuff happens” because “Hackers did it” has seeped into the public consciousness much more deeply than “It’s the big, bad conglomerate’s fault.”

Virtually everyone can feel outrage at accounting scandals and multi-million dollar salaries and insider trading and so on, especially when you’re clipping coupons to make ends meet. On the other hand, virtually everyone had been impacted by “hackers.” Phishing, spyware, malware, malicious web sites, Internet scams, spam, MySpace worms, fake wireless hotspots, lions, tigers, bears — everyone has felt the sting of “the bad guy.” I claim that for Mr. and Mrs. Average American, it’s almost natural to feel a little sorry for TJX, to feel a camaraderie even, like “Hey, welcome to the club.”

Sure, we all believe they should have done more. On the other hand, I shouldn’t have clicked on that email attachment last year. I’m quite happy with my physical attributes, but it really sounded like a good deal. And that Nigerian gentleman sounded so sincere. And who doesn’t want a few new MySpace friends. We all make mistakes, right?

But what about those of us in the consulting business who have to convince organizations to put their trust in us. They have to believe us when we say that not spending on {data|information|application|software|IT} security can have intolerable business consequences. TJX would’ve made such a great example of just what intolerable really means — a veritable poster child for “See! I wasn’t kidding!” And now it’s ruined.

Okay, I don’t really want their stock to tank and have thousands more people affected. On the other hand, the least TJX could’ve done was fire a wing of executives so they could serve the consulting industry as an example in endless PowerPoint presentations for decades to come. (I still occasionally see technology demos that claim things such as, “And this could’ve even stopped the Morris worm.”) Now, we’ll have to go out of our way to omit TJX. We can’t bring up an example where nothing that bad really happened — for the organization, not the people affected by the thieves, of course. Now, instead of answering the question “How do we prevent this happening to us?”, consultants will have to answer the question “How do they get out of it so easily?”

Yeah, I’m sure it was rough in their executive suites for a while, but I’ll bet everyone is breathing easier now, walking around saying, “Woo-Hoo, we didn’t pull a CardSystems!” TJX has a very respectable 5-year stock climb, including three splits, and the current trade price is solid. Would they prefer to have invested a little more in IT security? Of course. Would they prefer not have unplanned millions in expenses? Of course. Do huge, unplanned expenses happen to large companies with some regularity? Of course. This one is special to us because we have some insight into how relatively easily it could have been avoided or detected, but for many, it really is business as usual.

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

Everyone agrees that user education plays an important role in security, but does it really have to be so boring? How many security basics courses droning on about password security must we suffer through before we hit on a better way? Can comics help?

Cartoons certainly have popular appeal. They can get important messages across in a concise way. They can even be funny, boosting the chances that they’ll spread far and wide (like the latest silly youtube video). Plus, animated cartoons can be used to present very complex material in an easily digestable form—especially useful when such description requires an element of time.

Before we jump into the security cartoon pond, I have a confession to make—every night I read the comics pages published by my local paper, the Washington Post. I’m not sure I learn anything, but it sure is fun. This nightly ritual may color my thinking about security cartoons.

Cartoons for the masses

Security gurus often glibly state that if it weren’t for users, we wouln’t have any security problems. Is this anything more than a good laugh line? User behavior alone clearly can’t singlehandedly solve the security problem, but some critical aspects of security do in fact hinge on user behavior. Think about malicious code propagation through attachments in popular office formats like Adobe pdf for just a moment, and you’ll see what I mean.

The problem is that security can be complicated, and to non-geeks who don’t really grok technology (and who really don’t want to) the right security decisions can sometimes be hard to make. This is particularly apparent when it comes to user-faced attacks like Phishing and Pharming. How could opening an attachment really be that big a problem? Anyone even remotely familiar with security knows the answer, but many millions of others think security people are overly paranoid and only want to ensure nobody ever gets any work done. This is a situation where comics can help.

Markus Jakobsson and Sukamol Srikwan are academics who specialize in computer security. Markus is particularly well-known among scientific researchers for his work in ecrime with a focus (and some impressively-heavy published tomes) on phishing and pharming. Markus and Sukamol believe that poor user education is an important risk that must be addressed if we want to get a handle on identity theft and botnets. To address the awareness problem, they created a website called SecurityCartoon.com.

Securitycartoon.com is devoted to describing user-related security issues in easy ways. The material published so far covers spoofing, malware, phishing, pharming, passwords, and electronic voting. The latest security cartoon can be pasted into your own website with the following Javascript:

<script src="http://www.securitycartoon.com/today.js"></script>

Here’s a copy of today’s comic:

In an academic paper, Markus and Sukamol discuss the reasons they believe cartoons are an effective education technique. You can download their paper “Using Cartoons to Teach Internet Security” from the DIMACS website. In the paper, they describe the reasons they created SecurityCartoon.com and cover a number of technical examples of what works and what doesn’t in terms of user education. Critical to their approach is a focus on what and why (and not just what) behind real user-faced attacks. Using an entertaining medium helps solve a difficult problem.

Cartoons for security people

The use of cartoons does not need to be limited to non-technical users. Even experienced security people can benefit from cartoons. As an example, consider the well-publicized but not that well-understood cross-site scripting (XSS) attack.

Here’s how Greg Hoglund and I introduce XSS in Chapter 5 of Exploiting Software (Addison-Wesley 2004):

Cross-site scripting (XSS) has become a popular subject in security, but XSS is really only yet another example of in-band signals being interpreted by client software—in this case, the Web browser. XSS is a popular attack because Web sites are both common and numerous.

To carry out an XSS attack, an attacker can place a booby trap within data using special escape codes. This is a modern form of using terminal escape codes in filenames or talk requests. The terminal, in this case, is the Web browser that includes advanced features such as the capability to run embedded Javascripts. An attack can inject some toxic Javascript or some other mobile code element into data that are later read and executed by another user of the server. The code executes on the victim’s client machine, sometimes causing havoc for the victim. Figure 5–1 shows an example of Web-based XSS in action.

Find that explanation a bit opaque? Many people do. The problem is the nature of XSS, which unfolds over time.

An animated cartoon can itself unfold over time and make understanding XSS much easier. Markus Schumacher of the German company Virtual Forge GmbH has created a number of movies describing complicated security attacks. His explanations not only describe the what and why (as user-related cartoons must do as I describe above) but also covers the how in explicit detail. These kinds of movies are extremely useful as technical training examples.

You can watch Schumacher’s XSS animation here. You will see that understanding XSS in this medium beats what can be done in the printed word any day.

My all time favorite security cartoons are those that use humor. There are numerous Web-based cartoons that cover technical issues. One, called xkcd describes itself as a “webcomic of romance, sarcasm, math, and language. xkcd sometimes covers security issues. In a strip entitled “Exploit of a Mom,” xkcd covers SQL injection (another very popular attack that is not well-understood) in a very silly fashion. This comic was so popular that I got pointers to it from 5 different people over the course of a week as it made the email rounds. Check it out yourself, I think you’ll find it pretty funny.

In the end, I think it’s clear that cartoons can help with the education problem. They are certainly a far site less boring than generic training!

Last week, I gave a talk at QCON’s inaugural US conference, as part of Gunnar Peterson’s security track. There were some pretty serious speakers giving talks and I was thrilled to be amongst a set of developers with such deep quals.

I spoke about threat modeling because I think its a reasonable first-step towards implementing “Architectural Analysis”, one of McGraw’s most important touch points. Threat models aim to illuminate the intersection of technical risks (from technical vulnerabilities) and the business assets they target. An active SDLC work product, Security Architects (conducting secure design), Security Analysts (conducting code analysis), and test managers (planning destructive tests) should consume these models. They’re not shelfware.

Slides from my talk are available from the first link above, but I wanted to distill the key steps from threat modeling I covered therein:

1. Anchor the threat model on software architecture, that’s where the majority attacks against your application will occur
2. Identify assets (critical or sensitive data, and functionality) key to the application’s business function
3. Translate use case actors into threats, use into misuse/abuse. Start with normal use cases’ error conditions and alternative flows
4. Enumerate attack vectors each attacker may use against the application by pilfering the “low-hanging fruit” from community resources on vulnerability (such as the OWASP Top-10)

Tricks emerge along the way:

1. Show privilege escalation or increased system exposure (for instance from unauthorized Internet threats to authorized system use) through simple, common attacks. Show escalation to ‘insider’ in turn through similar attacks
2. Layer or combine simple attacks to penetrate systems more deeply
3. Show selective targeting of assets (victim clients, data stores, or application functionality) through particular attack selection

Finally, annotate threat diagrams by showing mitigating or compensating controls. While this wasn’t covered by my 50 minute session, its a critical part of a larger ‘loop’ of behavior that begins to create “design for security” out of “model threats”.

Enjoy.

Technorati Tags: threat modeling

I was talking with one of my consultants the other day about a common confusion Developers sometimes have regarding a pretty mundane piece of security guidance. Specifically, “What does it mean I have to turn off logging/debug in production?”

In my mind, these two separate issues exist here, intertwined.

Almost every logging framework has an in-place configuration option for increasing/decreasing log-level; most allow you to reconfigure on a running system without restart. The point here being that an application developer, with use of such a package, get to 1) keep a single code base, 2) turn a high level of logging off by default in a production environment, and 3) ratchet up log-level in circumstances requiring it (incident response or in-place debugging).

Often, people mix the above guidance with “don’t roll debug code out to production.” Code Analysis tools, for instance, give this advice. Two things principally concern me here. First, you don’t want a bunch of “main” or other “debug-only” entry points to the code. Attackers capable of compromising host systems could shoe-horn their way into an application this way. The situation becomes worse when said debug interfaces are web-based. Second, especially for thick clients or code running in less trusted environments, debug code tends to ‘express’ things about the design (or leak critical data) in an undisciplined manner. Removing such code from deployments to untrusted zones CAN be advisable, but one must balance complete removal with the need to ‘turn on’ nascent debug code in times of need as described by the previous paragraph. Only protection of the most sensitive information, and most invasive code qualifies for the extreme guidance “remove before deploying” that this paragraph describes.

The best thing one can do is give the developer guidance as to what types of test/debug code might qualify for wholesale removal. I’ll start you a list:

1. Client ‘harness’ code allowed to connect to server interfaces w/o
   authentication
2. Client code allowed to edit/manipulate local data repositories/stores
   directly
3. Command ‘harnesses’, allowed to (re)set or manipulate server state
4. Client code that dumps secret keys, tokens, or stored-but-otherwise-protected credentials
5. Backdoors
6. Code allowing for ‘insecure failure’ or back off, say to an older protocol
7. ‘Re-implementation’ outside a sandbox (native equivalents of a managed binary)

Just a small tidbit, away from the glib towards concrete guidance.

-jOHN

Technorati Tags: logging, debugging