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

My previous post sparked comments from Mike Rothman, Alex, Christofer Hoff, Arthur, and perhaps others I haven’t seen. I sincerely appreciate everyone’s considered feedback. In this case, the feedback was to tell me I’m off-base on terminology, and that’s all good. I’m happy to take lumps when I mess something up.

I really meant it when I said, perhaps unclearly, that I was talking about the meaning of information security “risk management” as the activity occurs in most organizations today, not any textbook definition of risk management and certainly not any definition that uses words like “exact” or “right.”

Is that better definition and more precise activity a good North Star? Absolutely. Do you tell an organization that is just learning and applying a subjective skill that if they don’t do it perfectly, they’re doing it wrong? Do you tell an organization that is doing something that works for them that they’re doing it wrong because it doesn’t match the textbook? Not if you actually want to be helpful.

The crux of the following screed is that purist “risk management” and the information security “risk management” that is (not could or should be, but is) practiced in the day-to-day business world are currently distant cousins that may meet in the future. I also feel this is the perfect time to trot out the old Yogiism that, “In theory, theory and practice are the same. In practice, they’re not.”

Many of the fundamental information sources that organizations are turning to today give no prescriptive guidance at all on risk management. The information security drivers don’t help much either. By way of example, the PCI audit procedures recommend that reviewers “Verify that the information security policy includes an annual risk assessment process that identifies threats, vulnerabilities, and results in a formal risk assessment.” FFIEC guidance for financial institutions desires a “multidisciplinary and knowledge-based approach” that identifies “all reasonably foreseeable threats.” This gives organizations no guidance at all and, after they have caused problems, all threats are reasonably foreseeable.

In my opinion, the common definition of information security risk management in the world today is the set of activities that is preventing me from failing compliance and examiner audits, that is streamlining my security operations (for better or worse; I don’t know because I don’t know how to measure it), and that appears to be reason I am not suffering even more security breaches. Again, there are always enlightened organizations that are doing more and better, but they are the minority. There is no common yardstick, no well of enlightenment. If FFIEC, Basel II, SOX, PCI, and assorted other examiners and auditors see a recognizable security program that is producing good results, then by definition whatever these organizations are doing is good “risk management.” Likewise, if I’m not suffering breaches, then I have good “risk management” in the eyes of those whose opinion I really care about (e.g., people who buy my stuff, can fine me, or can put me in jail). Call that “information security” if you want (and so it is), but saying it’s not risk management is just po-tay-to, po-tah-to.

I have my understanding of the textbook and “perfect world” definitions of risk management. I usually cast risk management as the process that starts with risk assessment. This, of course, is a catch-all term for analyses of business goals, threats, assets, event frequencies, downsides, and so on. We also need information on vulnerability, risk appetite, internal and external mandates, and so on. Some good risk models applicable to the target environment help, too. Risk management as a process then works through decision-making and continues with activities directed at risk avoidance, risk reduction (whether through reduction of loss frequency or loss severity), risk transfer, and explicit risk retention. Lather, rinse, and repeat in an ongoing “it’s a journey, not a destination” sort of way.

“Proper risk analysis,” as Alex put it, “can’t mean unnecessary controls.” I interpret this the same as I would interpret that “proper” medical care can’t produce incorrect diagnoses and “proper” maintenance can’t ever damage a vehicle. In other words, there’s no such thing in any practical sense. Smart people trying to do the right thing with the best of intentions and the best of education mess these things up all the time. Even at Harvard, someone graduates last in each and every class.

“Proper” rarely happens in the field. Proper risk management costs too much and requires to many propeller-heads to make it go. Anyone doing “proper” (full, complete, accurate, perfect) risk management would know enough not to spend the money it takes to do “proper” risk management. While accurate conclusions are crucial, very few, if any, information security decisions require that much effort or that much precision. With all due respect, I’ll wait while that sinks in.

Yes, I suppose I am dealing with some aspect of “issue management,” to throw yet another term at those activities organizations engage in to ensure their networks and applications are appropriately secure. The “issue” is “I don’t want to overspend, but I also don’t want to be the last one to do some security thing because I don’t want to explain to a jury why I’m the only organization not doing something that might have prevented a breach.” Further, the “risk tolerance of the data owner” is often of little consequence since data aggregation that increases sensitivity, public perception, and a variety of other business problems often take “risk” decisions out of the data owner’s hands.

With respect to “If your definition of risk is correct, and if your analysis is good, then all that is left is for the decision maker to figure out how willing they are to lose money,” this doesn’t happen. Even with terabytes of actuarial data, insurance companies can’t make perfect longevity predictions and odds-makers can’t reliably predict the Super Bowl winner in October. And these are really smart people, with really cool technology, with millions of dollars in backing, and the opportunity to make billions off a good decision. In other words, they’re *really* motivated. Does anyone really believe the average CIO and CISO stand a chance of having a “correct” risk definition and “good” analysis?

As to the idea that you can’t overspend because “the data owner expends only the amount of resources they are willing to allocate to reduce possibilities to their acceptable level,” well, again, I’m stymied. There’s no response for such Pollyanna thinking. It’s like a having a doctor from a world-class hospital telling a M*A*S*H surgeon to just “do it clean, quiet environment and it’ll be okay.” For example, what if the data owner postulated above is willing to spend $1B on a $1M problem? Exactly.

Activities correlating to “done correctly” and “can’t overspend” and “perfect data” and so on only happen in textbooks and fabricated business school case studies.

Information security risk management in the field is an ugly business. It’s not a matter of “when done properly” — it isn’t. It uses gut instinct for fuel and eats academics for lunch. Sometimes the process is too ethereal and we get bad decisions and too few controls. Sometimes the process is too grounded in activity and we get bad decisions and too many controls instead of more thoughtful analysis. Sometimes, bad things like public data breaches never happen even to the goofiest organizations and, sometimes, bad things seem to happen over and over even to organizations with thoughtful, resourced, and active risk management processes. It happens.

To address Hoff’s contention, I’m not “making excuses” for it; I’m documenting it. Clearly information security and risk management are not the same thing. And, to a geologist, sculptor, or someone refinishing a kitchen, marble and granite are also very different things. To the average person needing to prop up a wobbly business process, however, they’re both just rocks.

“Risk aware” organizations do spend better, but they still end up buying the same basic information security technologies as everyone else because that’s all there is. Where I see them spending more pragmatically (the perfect word here) is in training and in configuration and use of technology, which is truly a good thing. These are everyday blocking and tackling activities at most organizations. Where risk awareness truly benefits an organization is in creative areas such as software development. Thoughtfully applied security in the SDLC of an application-driven organization (think ISV or large brokerage) will result in much more overall net goodness than another internal firewall or blocking ZIP files at the Internet boundary.

“True risk management” is indeed a wonderful tool and I will always push organizations in that direction. The progression from raw art to even a glimmer of science is still a long road for information security risk management.

As to a “proper” definition of “risk management,” I spent years bemoaning the change in the definition of “hacker.” It was once a really useful word that described a true artist with code and equipment. Now, it describes any many manner of computer-based criminal activity. I wish you better luck preserving a classic definition of “risk management.”

Technorati Tags: risk management

IT controls. Corporate governance. Decision support. Right-sized spending (another phrase I thought I coined, but I see it gets three hits in Google). These are all part of the all-too-nebulous activity often referred to as data security risk management.

Let’s put a stake in the ground on what risk management means. I’m not referring to how it’s defined so much as what it actually means to business. Risk management means there is a thought process that includes ensuring the right people with adequate skills are given useful information and actually decide whether to do this or that to more effectively achieve security goals. Something like, “The available data indicate that path A at price B mitigates problems C, D, and E, but causes problem F, while path Z at price Y, mitigates problems C, E, and X, but causes problem W. What’s your decision?” Or, as happens much, much too often: “Hackers, phishers, and insiders…oh my, what are we going to do?”

Everyone makes dozens, hundreds, or perhaps thousands of risk management decisions every day. These are parents, doctors, lawyers, truck drivers, and everyone else, including CEOs, CIOs, IT security personnel, software architects, developers, and so on. Some people have good gut instincts, shoot from the hip, and end up with decisions that only occasionally burst into flames. For my risk appetite, that’s too little risk management. Others wait for every possible scrap of data, agonize over the possibilities, and end up with decisions that only occasionally aren’t completely overcome by events. That’s too much risk management.

The impact of too little risk management is usually too few security controls and, therefore, too much unpredicted expense in a variety of areas: incident response, litigation, and recovery, to name a few. These are often the result of public things that can have lasting effects on brand. This is easy to understand.

The impact of too much risk management is usually too many security controls and, therefore, too much predicted expense in a variety of areas: hardware, software, tools, people, processes, and so on. These are all internal things that can setiously impair agility, efficiency, and overhead, and this is usually much harder to understand.

Which is worse?

Let me clarify that I’m being a little fast and loose with “too much risk management” above. In my experience, the problem is almost never too much “risk management,” it’s almost always too much security fabric resulting from a fixation on or over-thinking of each and every security issue, whether applicable or not, combined with a natural tendency to equate activity with progress. As a consultant, I’ve heard some form of the following dialog hundreds of times: “What are we doing about the security problem I’ve heard about?” followed by a confident “We have people choosing A as we speak.” More security controls, especially generic plug-n-play things, does not automatically mean less risk, but it sure is highly demonstrable activity (to managers, to auditors, to examiners).

I think we’ve seen the impact of too few controls all too vividly recently. Just type “data breaches” into your favorite search engine and you’ll be inundated with examples. And that’s just one example of one kind of bad outcome associated with too few security controls.

But, too many controls can also have a direct impact on the very core of an organization. To illustrate, let’s turn to the great triad of operational excellence, product leadership, and customer intimacy.

A company whose success is based on operational excellence requires quality goods at reasonable prices. This requires very efficient operations, excellent supply chain management, and practically flawless execution. Superfluous security controls, whether in people, process, technology or embedded in software, may not prevent flawless execution, but it certainly seems like a good way to slow down a just-in-time supply chain (e.g., we quarantine all email attachments for 12 hours) and disrupt operations (e.g., by implementing ultra-fine-grained entitlements where it just isn’t necessary).

When your success is based on product leadership, you are probably innovating constantly and spending like mad to build brand. Staying ahead of everyone else requires great design and development, a fantastic knowledge of your customers, and quick time to market. Security controls that have no material relationship to any practical attack can easily derail any product process that relies on agility (e.g., SDLC security tools and processes that check for things that have no matching threat slowing down product cycles).

If customer intimacy is your key to success, then you are likely to be extraordinarily focused on customer service, with lots of choices that can be tailored to customer desires. Here you will have to excel in customer management, have product and service delivery that exceeds expectations, and engender client trust. Too few security controls (”Hey, I’m this person you’ve never met, please reset my password.” “Sure thing!”) can certainly end a client relationship, but so can unnecessary security controls (e.g., three personal questions, identify an image, and last four of your SSN just to activate the Forgot My Password page) as it also clearly indicates that you just don’t know what you’re doing. Where it’s obvious that you don’t understand the appropriate intersection between your risk management, your customer’s risk appetite, and the actual risk, a trusted partnership is pretty much out of the question.

All in all, too few security controls is probably the greater of the two evils. On the other hand, it’s probably the easiest to remedy. Even if you do no risk management at all, if you have the money to purchase and correctly install most of the major security technologies out there, the shotgun approach will in fact reduce security risk. You’ll never know if you’ve done enough or if you’ve overspent, but you’ll have a story to tell to the masses. On the other hand, a thoughtful security approach based on sound risk management will give you a story to tell to savvy customers and increasingly well-educated auditors and examiners.

Technorati Tags: risk management

In a recent article iPhone shell code hits the web HD Moore, creator of the Metasploit Framework describes how combining members of a set of implementation bugs in applications on Apple’s iPhone with a design flaw results in a ripe opportunity for landing shell code or otherwise controlling the phone’s various hardware goodies (camera, mic, speaker, etc.) remotely.

As you read the above article, note the classic vulnerability-types mentioned. The iPhone suffers from a design flaw: all apps running as root. Moore also mentions some of the simplest kinds of buffer problems (such as the stack-based buffer overflow).

These bugs, this flaw represent a low-level of organizational maturity in security. It almost seems a throw-back to any 90’s era code assessment I’d done. We’ve understood the stack-based buffer overflow well for years-upon-years and even rudimentary static analysis tools catch it. Threat modeling or simple architectural analysis should have dissuaded architects from moving forward design intact, bearing so fundamentally “risk amplifying” a flaw as “run as root”.

Make no mistake: Apple represents a company leveraging security by obscurity. I cringed when Apple used its then largely untarnished record as a marketing ploy, (from what I understand) without listening to what’s been said about the actual resistance of his products to attack.

While aspects of their desktop OS were truly “designed with security in mind” and represent solidly secure OS technology, it’s clear to me that Apple does not address software security programmatically to what I consider an acceptable level.

When Apple created an asset of reasonable enough value and appeal, threats easily broke a shoddy system by retraining their attention on the protective mechanisms shielding that asset.

While a lot of our customers have adopted software security early, and have committed to addressing it in all phases of their software’s lifecycle, in all appropriate organizations touching software, others have not. If, reading this, you look at the well-covered transition from Microsoft to Apple as the vulnerability target and think by analog, “this stuff is happening to my competitor, but can’t happen to me”, or perhaps feel invulnerable because, “No one would figure these vulns. out.” or, “We’re not on people’s radar.” BEWARE. One ostrich is having to pull its head out of the sand and peck at crow… and this is sad because, with the exception of my Crackberry, I largely believe in and purchase from Apple.

A final thought: Regardless of the actual security in OS X, what chance does Apple have of touting Leopard’s security over Vista in the market place after these events?

As I get back into the risk management arena after a sojourn in knowledge management (mainly designing knowledge-driven offerings and monetizing the associated intellectual property), I find yet another example of “the more things change, the more they stay the same.” I think the executive view of information security risk management techniques as viable decision support tools has come a long way, but the complaint I hear from most executives is that even the simplest risk modeling appears to take a very long time.

I find that information security risk management still has the unfortunate combination of being a lightning rod for snake oil in the marketplace, being a real polarizing and dogmatic topic that often defies reasoned discourse, and being something that the average person handles by gut and not by numbers. Practitioners, academics, and managers alike bemoan the scarcity of actuarial data on which to base decisions. And, just to round out the issues list, any given group of people will quickly fall into its own set of terms and meanings, making it very difficult for any two groups to have short, interesting arguments that actually advance the knowledge base.

In my recent reviews of what’s going on in the world, risk modeling exercises related to application security seem to stretch on for two primary reasons:

1. An obsession with knowing every “threat”
2. Not having a good rule for deciding when a threat-vulnerability-control coupling deserves no more scrutiny

What I’ve evolved over the past couple of decades to reduce this work is something I’ve called “Looking for zeros” and “Looking for ones.”

In my experience, knowing the exact threat (i.e., combination of attacker, attack, attack path, resources, and some intangible things such as motive) is often irrelevant. I call this “Looking for ones.” For example, if a particular attack always works (e.g., cross-site scripting in a particular web form), then it likely matters not whether the attacker is a national government, a terrorist, a criminal, a script kiddie, or someone who accidentally pastes HTML into the field — the “success value” for this attack-vulnerability tuple will always be ‘1′. Knowledge of the attacker might give us a bit more information about what he or she might be ultimately trying to accomplish, but the decision to fix the problem should already have been made.

Similarly, this is why we decompose threat, vulnerability, assets, and other things into constituent components. I call this part “Looking for zeros” and it works really well. As soon we find a ‘0′ for a material aspect of attacker, attack, attack path, resources, motivation, threat frequency, feasibility, accessibility, susceptibility, vulnerability prevalence, asset value, event cost, downside, caring, and so on for the various dimensions of “bad stuff happens,” then that scenario is over and we can move on. Again, even given a national government with lots of resources and a zero-day electronic attack that really works, we just don’t care if the attack works only on WebServerA and we’ve deployed WebServerB, or if the attack path required (e.g., site must be using JSessionID), or whatever else, simply doesn’t apply to us.

When we bring into the mix controls (for which we reason about preventive, detective, corrective, and deterrent values), then we try to kill off entire attacks (e.g., timeouts that prevents script kiddies doing half-open TCP stuff), attack paths (e.g., Internet routers that allow incoming packets with RFC 1918 addresses), motivations (e.g., dye packs that render stolen cash unspendable), and so on all at once; seldom should the IT or software development world try to work off “threats,” and specifically threat agents (attackers), one at a time. That just takes too long.

A comprehensive and holistic view of what makes “risk” happen will always make risk management much more efficient and make the results of risk management much more usable in day-to-day decision support.

Technorati Tags: risk management, threat modeling

In the past few weeks I have started work on a major software development effort. It is a very complex bit of software for capturing images from high-performance cameras and reducing them mathematically to functions used in high-end digital rendering. The process is very complicated mathematically and computationally intense, in some cases requiring as much as eight hours of processing.

One of the first questions I wrestled with was which language to use for the development. I was surprised at the answer.

I started my career in IT more than 30 years ago developing mathematical code for scientific applications, and as I sat down to make the decision I felt like I was in a time warp. When I was growing up, savings accounts were common. You made small deposits which were recorded in ink in a small paper book about the size of passport. Over time the pass book took on a comfortable worn look that was a source of pride, reminding you of your thrift, as my worn passport reminds me fondly of my travels. Once a quarter the bank totaled your balance and added a bit of interest. The rates were terrible, — 2 or 3 percent at best, but were made worse because of the infrequent compounding. One reason banks didn’t compound interest often was that the market didn’t demand it, but another reason was that it wasn’t easy to do. The rudimentary computing equipment and software of the time meant the interest was literally added to an account with an “interest” program that took hours to run for all of the bank’s many accounts.

The biggest bank in town was innovative and moved quickly to automate with Burroughs banking equipment, and with their added computing power began to offer some impressive new services. The early investment in high-end computers paid off, and the bank eventually grew into a major service provider to other banks, and provided me with my first professional IT job. The immediate application of the technology, though, was to provide current (daily) account information to multiple branches in the form of huge, green-bar reports, to print deposits in the bank books rather than writing by hand (wow, did that look high-tech) and, my favorite part, to compound interest every month.

They advertised this widely, with a cheesy jingle typical of the era. My father was good friends with the executives of the competing bank (which was literally across the street) and they took the escalation seriously. They responded by buying the latest and greatest from IBM (a 1620) and after a few intense months, proudly announced weekly compounding. The war escalated, and Burroughs crowd announced daily compounding. The IBM camp then launched the nuclear option – continuous compounding. The executives from the Burroughs bank stepped up and said “Oh, yeah, we can do that too”.

Oops – there’s a problem. Continuous compounding is done in a completely different way from periodic compounding. In the old days you ran an interest program – once a quarter, month, or whatever. As the interest rate war progressed the banks just bought newer, bigger, faster computers so that they could run the program more quickly. With continuous compounding, however, you only calculated the interest when there was an event – a deposit, withdrawal or statement, and then you had to do exponentiation. Unfortunately, the Burroughs COBOL of the day did not have a built-in function for exponentiation.

That omission got me my first professional gig. The bank came to the local college and asked for someone who could write code to implement this one function. I got the task and dispatched it in short order. I wrote it in Burroughs Algorithmic Language (which hasn’t been seen in the wild since 1977 and is presumed extinct).

So how have things changed? My recent experience suggests that things might not have changed as much as I thought. First, in recruiting for coders, I found that there were a huge number of people who were skilled at building web and data applications, but the folks who know how to make machines do math fast are rare birds, indeed, just as it was 35 years ago.

This didn’t surprise me too much, as the market for business applications is vastly larger than the market for scientific applications. What did surprise me, was the way the old languages are still competitive. The test I devised was to write an equation solver (using the Newton Raphson method) in several languages and trying several different compilers. I constructed a problem where the root was exactly pi, so I could check the answer against published values to very high precision.

I tested Fortran, C, C#, and J# . The results were completely clear – the object oriented languages were crushed. The simple old procedural languages really are faster for the mathematical heavy lifting. It was close between the two C compliers I tried and the three Fortran’s, but the Intel Fortran compiler seems to be king of the hill. It was fast, and the results were spot on to 32 decimal places.

It may not be sexy or look very modern, but if you have to do serious math on 16 mega pixel images, plain old Fortran is still the way to go. Certainly the vast bulk of the new company’s code is going to be written in something more current – their web site, e-commerce site, and internal system, for example, but the hard core, the nut that will make or break the company is going to be in Fortran. Now I’m back where my bank employers were in 1970 – looking for some math stud at the local college.

Technorati Tags: software security, banking, Fortran

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

The insider threat has always been invoked and then ignored by computer security types. That kind of treatment may have worked (accidentally) during the network security days, but such old-fashioned thinking is quickly becoming a problem as distributed software becomes more complex. The problem is really one of trust, and the new insider is built right into modern software.

Put on your software architect hat for a moment. Most architects think in terms of boxes and arrows. The boxes roughly correspond to software components, with the arrows being connections between components. In a standard view like this, there is little or no notion of trust. That is, all components are equal in the eyes of the designer.

The problem is that in new massively distributed software architectures (think Google Desktop or World of Warcraft clients) have components that run entirely on untrusted machines. If part of your software architecture runs on a potential attacker’s box you really need to think hard about what happens when it is manipulated. If you don’t, you quickly become subject to insider attacks of a new sort. Your own software will attack itself.

When building a boxes and arrows architecture for modern software (especially SOA software), make sure that you explicitly consider the trust model and take into account the new twist on insider attacks. Be especially mindful of time and state problems. Make sure that trusted servers think carefully about any state that they consume from untrusted clients.

For a couple of examples of this and a slightly more formal treatment, see my Darkreading column from 8/14/07.

Technorati Tags: software security, world of warcraft, WoW, software