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 the course of my career I have been involved in a fair number of startups. I’ve had pretty good luck, and most of them have been successful. One, however, was a complete failure. I refer to that experience as my DIY MBA. You can learn more from failure than you can from success. It is very difficult to determine what made something succeed (apart of course from our genius, hard work, and moral virtue), but if we look at something long enough and with whatever objectivity we can muster, we can usually find a root cause for failure. If we’re smart, we won’t that make that particular mistake again.

One of my favorite books is Engineers of Dreams: Great Bridge Builders and the Spanning of America by Henry Petroski, the wonderful writer on engineering. It is a book about extraordinary success – the construction of the great bridges of America, but it is as much about failure as success. Bridges fall down throughout the book, but each failure shines light on another aspect of bridge design and the limits of the materials. The heroes (the great engineers) learn from their experience and continually build better and longer bridges. What I took from this book, beyond an appreciation of the bridge builder’s art, science, and mastery of the political (all big projects involve politics) is that that failure is something to be treasured once you get past the pain.

My one entrepreneurial failure was in a company that did desktop publishing around 1980. My partners and I bought two NBI 3000’s, very early, very expensive word processors. Businesses in and around Boulder, CO, some students and professors came to us with hand written drafts which we turned into beautiful printed documents. The machines were complicated, temperamental, and difficult to use, though they defined the state-of-the art at the time. Only trained operators could manage them. Word Processing was a task for pros.

Of course the company failed. Things went well for a year or so, but then the first practical PCs and word processing software came out. People began to do their own word processing, even on crude, small, expensive machines. When the IBM PC came out and legitimized PCs, everyone started writing on computers and doing their own desktop publishing. The stream of customers dried up and we closed the doors.

My first thought about Document Control (the company) was that our technology was simply made obsolete — that we were selling slide rules in the age of calculators. I think though, that we were really swept aside by a more fundamental imperative – the human urge to do things themselves. In the Pharaohs days literacy was regarded as something for specialists, and the leading classes hired scribes to perform that difficult task. When the telephone was invented we needed operators; when cars were invented they were often driven by mechanics. Over time in each case the difficult became simple and the rare became commonplace. For the things that count, people would rather do something themselves than have it done for them if it is within their ability and comfort zone.

This principle pertains as much in IT as in other arenas. IT was once entirely the province of the professionals operating in glass houses, who accepted data on cards from the acolytes and returned them manna in the form of green bar. It was inconceivable in those days that computing would become the province of the everyman but, of course, it has.

I am not referring to people using personal computers to access the Internet, using email, and writing newsletters for the PTA. That is really too obvious for comment. What I am referring to is the continuing trend in all sorts of organizations to empower the individual. Individuals prefer simple hosted applications like Saleforce.com to complex CRM from central IT and they use desktop tools like the Microsoft Office Suite to build very complex applications. The things they build are not tightly integrated like the applications built by professionals. Processes may still involve many manual steps that a pro could program in a few hours (after a week of committee and budgeting meetings, another week of design review, and two weeks or so of testing). We pros can do it better – complete automation, all sorts of bells and whistles the rubes would never think of, audit trails, better security, and all that good stuff, but the users prefer the stuff they build (or discover) themselves. It does what they want and they understand it. More than that, it empowers them. They feel in control. In the end, DIY always wins.

Going into word processing was not a mistake. The machines were great and they did things that simply weren’t previously possible. The mistake was in persisting even after the first personal computer showed up. The was on the wall, and it read that in the end, DIY always wins.

In building our enterprise applications we must be cognizant of this same imperative towards DIY. There will always be central IT applications for things like basic accounting – accounts payable, accounts receivable, etc., but organizations are dynamic – buying businesses and being bought in turn, reorganizing, opening and closing business lines, launching new products and dropping others, doing studies and projects. The central IT department is always running behind but the DIY community filling the gap with their jury-rigged lash ups. Giving the pros (i.e. us) a break, though, real IT is hard.

I know that this informal IT – the IT that takes place outside the purview of the IT organization – is already and important part of every business. I suspect that in many organizations these home grown applications may actually be as or more important than the official stuff. My wife who works in the accounting business, for example, is tracking the company’s backlog and progress in an Excel spreadsheet as the tax deadline approaches even though her company uses the best accounting software in the business.

As IT tools have improved, everyone has become a practitioner to some degree, just as our ancestors learned to drive cars and make calls and our ancient ancestors learned the arcane art of reading. A challenge for us as professionals is to give the non-professionals the tools they want and need so that they can define how they do their work, and then work with them, not against them, to improve these informal processes and bring them up to “professional grade.” DIY is a powerful imperative and much of the IT that we now regard as the realm of the professional will inevitably move into the hands of users. We should not resist this, but enable it. I would love to see what users could do if they could have a real-time access, with Excel as a front end, to a company’s core data in real time. What would they build? I know that they would build better tools for their personal work, but they might just go beyond that to provide new insights into the way the company operates and models for how the company’s processes can be improved.

Technorati Tags: diy, it

My wife recently made the comment about how it seems as though bad things come in threes. I thought it was an odd thought to see random events as coming in sets, but then again she also thinks that there are a finite number of good weather days in New England. But then I realized that there have been three occurrences that have set a course for part of my intellectual pursuits here at Cigital. These three events are completely un-related, but all evolve around the issue of security testing and how it seems like security testing should be the next technical pursuit for software test engineers.

The first event was at SD West. I went to hear Herbert (Hugh) Thompson talk about fuzzing. Hugh is a great speaker by the way and you should definitely hear his presentation about his escapades as a young teen fuzzing his high school’s soda (”pop” for all us midwesterners) machine. But, I digress… In any case, the question that came up at Hugh’s talk was whether security testing was the domain of developers or testers.

I’ve been doing some work with one of our clients about moving security testing into their testing organization. That’s the second of the three coincidences. Our client has realized that in order to implement the Software Security Touchpoints throughout their SDLC, that they need to train and empower their testing organization and not assume that the developers to write secure code. Good assumption.

The third is that Joe Jarzombek, Bob Martin and I were asked to give a talk on Software Security at the Boston Software Process Improvement Network (SPIN) and Software Quality Group for New England (SQGNE) meeting. The talk is on May 9th for anyone in the Boston area. My talk is titled “Software Security Testing - The Next Frontier”.

Does this mean security testing is a bad thing because it “comes in threes”?

I was starting to worry that it was after my wife told me about the “bad things come in threes” thing. Then, the other day one of my co-workers, Paco Hope, and I were talking. Turns out that he’d already started blogging about security testing and some of the challenges. He’s started with a couple of book reviews which provide some insight into the challenges. He and I started talking about and the relationship of Cigital’s Risk-based Security Testing methodology and other negative testing methodologies like equivalence classes. Paco’s definitely got some great ideas about how Software Security and Software testing relate.

So, there aren’t three incidents - there are actually four. Phew - because I really do believe that testing organizations are going to need to provide the security training, tools and resources to empower their test engineers. It also creates a natural, technical growth path for those engineers. Engineers progress from manual testing of features to being able to write test automation. Security testing requires even deeper technical knowledge than automation, so it’s a natural evolution to start getting underneath the constrained environment of traditional automation tools and start working on testing the security related aspects of the software.

So, Security Testing is definitely not a bad thing, since it doesn’t come in threes. Now, if I gotta start working on the weather in New England.

Technorati Tags: security testing, fuzzing

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

Sammy aimed two recent entries at those attempting to govern security and expenditure in an organization. I’m using his posts as license to wax more philosophically. Specifically, I’m going to use Digital Rights Management (DRM) as a lightning rod for conversation about protecting data end-to-end in one’s system (the topic of my next–far more focused–post). I’ve been thinking about this ever since McGraw’s Dark Reading column: on Vista, and it’s driven me mad.

In posting this message, I’ll skirt more topics than I cover; I apologize. In return, I’ve included a lot of links worth reading. I don’t presume to answer the question, “Is DRM ever a good idea?” I believe most computer security folk simply answer “no,” bemused because in the end they know consumers MUST use protected data and algorithms in their full quality, to be satisfied. Some gifted albeit misguided security folk attempt to trade data quality for what they perceive to be security. Peter Gutmann’s working paper covers Microsoft’s attempts through Vista.

When I replied to Gary’s Dark Reading article, defending Apple’s DRM, I had purchased about $350 worth of music from iTunes. The standard caveats applied:

1. Apple could change their DRM scheme out from under consumers at any time
2. DRM still provides no value from the consumer’s perspective
3. DRM imposes limitations, potentially limiting competition between vendors

but I still found myself unable to come to any other conclusion but the mighty unpopular: Apple’s DRM seems a reasonable compromise between affording protection and remaining flexible to consumers. Remember, I said ‘unpopular’, so feel free to argue with me.

Now, $450 into the fray, something very interesting has happened: Apple and EMI have decided to sell some music electronically but DRM-free (see:
http://news.bbc.co.uk/2/hi/technology/6516189.stm ). Unprotected music will be encoded at 256KBps (twice the bit rate of Apple’s protected files) and will cost $1.29, rather than $0.99.

Now, consumers have an interesting choice to make: “Do I want to pay an extra $0.30 for the ability to copy the music I purchased freely?” Some may be willing to pay extra for the quality–but that’s not what we’re interested in right now.

In asking local “kids,” I’ve gotten consistent reply: “I’d only pay more if I liked the band.” Questioning them further immediately reveals they perceive the music to be free (and rightly so–it’s just too easy to pirate). They make their purchase/steal decision based on their feeling of loyalty towards the band. Can your business rely on such good will? I used to pay for single pieces of bulk candy at the grocery store–but I wouldn’t bet my business on others doing so. At the same age (prior to driving) I’d hack games’ copy protection, give copies to my friends and say, “Ok, but call me before you play it… to make sure only one of us is using it at a time.” Why am I only now explicitly aware they never called? Guess they never played it ;)

More fundamentally, will consumers perceive your product or service as being free? Think back to Windows ‘95… did anyone you know have a problem copying it?

An interesting question to ask one’s self is this: At what increase of price can I afford to protect my data less for the sake of other business drivers? Presumably, EMI has come to the conclusion that the answer, in their case, is $0.30. Interesting. If protected music accounts for only 2% of sales (dubious estimation by extrapolation of iPod size + sales compared to iTunes sales), how much does EMI expect that number to jump if the price has moved to $1.29? If physical sales still occur at $1.99 per single, how much less piracy does EMI expect from electronic sources as compared to physical ones? What does this even mean–given that pirated physical wares will almost immediately take the electronic form for ease of distribution?

Finally, what numbers could Apple put on the cost of developing and maintaining their DRM scheme? What affect does that price have on their profits (if any) in the case of EMI’s unprotected content versus that which is protected?

Part of me wonders if any of this will have even the slightest effect; given the ubiquity of the protected content, unlocked and freely available from peer-to-peer sites. If all’s for naught, is EMI making a good decision, or a mistake? God, I hope there’s no analog for that in your data.

I have no idea how successful Apple’s iTunes model will be, or whether or not consumers will accept Vista’s DRM, but with EMI’s decision to distribute unprotected music along side protected songs, those of us in security-land potentially gained data to look at. What will it tell us? And, while it’s very unlikely that you’re distributing electronic music, dear reader, or even passing content directly to end-consumers, EMI’s move should raise questions about how you’ve calculated the value of data, the protective mechanisms you’ve placed around it, and the impact on usability those protections imposed.

Technorati Tags: drm, apple, data security

I’d like to give a slightly different perspective on a topic John Steven talked about a few weeks ago (“Keeping up with the Jones’ Security Initiatives”).

Be a goose; don’t spend “10%” just because it’s a popular number.

I spent the first four years of my career, in the early 1980s, in the Air Force. I worked as a systems programmer in the Pentagon and had direct responsibility for system security (Go Multics!). This was a timesharing mainframe with directly connected VT100 terminals in secure locations, so threat was fairly well understood. It was all about availability then, even though security was paramount. If the system was down, heads rolled. On the other hand, if some MLS control prevented the general from doing something he thought would be cool, well that was just tough. No one ever asked me, “Do we have the right level of security?”; it was always some question about specific vulnerabilities and how to remediate each one on a case-by-case basis. These were ducks.

As a defense contractor employee, I worked with dozens of classified and unclassified systems, some on the burgeoning Internet and some not. I performed virtually every kind of security review, pen test, IV&V, and tiger team you can imagine. No one ever asked me, “Do we have the right level of security?”; it was always some question about specific vulnerabilities and how to remediate each one on a case-by-case basis. These were ducks, too.

After 12 years in the commercial world, I’ve seen or worked with virtually every information security technology. And, although I gave up software development a long time ago and pen testing more recently, I still try to keep current. I’ve worked with hundred of organizations on thousands of security issues. In my experience, only in the last few years have some organizations begun to look past the individual assessment results and ask about their level of security and its overall appropriateness (first in financial services and later in other public companies). At last, a goose or two.

However, the vast majority are asking about it solely in relation to their peers. These organizations are not asking, “Do we have the right level of security?”, they’re asking “Do we have about the same amount of security as everyone else, good or bad?”

This is wrong thinking and here are two reasons why it bothers me.

The first is the large number of organizations that are insulted at the mere insinuation that I can “know them” even if I have years of experience and I’ve worked with other firms in their vertical, or even with other business units in the same company!

The second is that they’re right. You can’t really know a given organization just because you’ve worked with its competitors. I can understand implicitly the risk associated with their transaction processing systems, with their SOA framework, with their Internet-facing systems, with their overall approach to security, and so on. On the other hand, I really have to work with them to understand what drives them, what is the tone at the top, what decision will they make when push comes to shove, their risk appetite, where they will cut IT dollars first, whether they really are trying to act strategically as opposed to simply having a 3-year plan of tactical initiatives, and so on.

So, why would these organizations think that I can’t know them by working with their competitors, think they can know something about themselves by comparing furlongs per fortnight of security spending with their competitors?

Here’s are two admittedly loosely related stories:

I did my taxes a few weeks ago and was told by the application the percentage of tax-paying Americans who were “like me” in income and tax burden, with no real additional information. Were these families or single filers? Did we have similar kinds of deductions? Did we have the same cost of living? What did these comparisons mean? Duck or goose?

I went to my doctor recently and was told the percentage of Americans whose weight, cholesterol, and related items were similar to mine. Here, however, I was also told how each of these items factored into overall health. In gruesome detail, I was told about various mortality rates, stroke rates, heart attack rates, cancer rates, and so on until I simply wanted to nibble lettuce for lunch and stay out of the sun forever. But, still, did these other people have my heritage, my work and exercise habits, my eating habits, or anything else that made them like me? Again, duck or goose?

In the information security space, we’ve had (mostly by the analysts and the press) huge discussions about whether 10% of the total IT budget was the right amount to be spending on security. According to Forrester, that number has hovered in the 7.5%-9% range for the past few years. That’s good to know because it gives us a general guideline (which is all we can have in the absence of any real actuarial security failure data, but that’s a rant for another time). However, in multi-billion dollar corporations where a 1% difference in IT security spending could equal the annual revenue of many of small security firms, what does this percentage really mean? If one organization consistently spends significantly more than it’s competitors on hardware, data centers, and related IT items, should it necessarily also be spending more on IT security?

I realize these percentages are just guidelines, but they’re the kind of guideline a sharp litigator will latch on to. Remember that no one wants to be the odd man out. No organization wants to have to explain to some regulatory or law enforcement organization the possibly coincidental facts that it suffered a security breach and was also spending somewhat less on IT security than the average for their industry, or country, or whatever.

So, much like I am, I’m sure you’re wondering whether I have a point or whether I’m simply writing this at 4am because my allergies are kicking Claritin’s butt. My long-winded point is simple: We’re all the goose. Every single organization has its idiosyncrasies that make the 10% rule of thumb somewhat less than useful for anything other than selling research reports.

Organizations should spend as required to adjust risk to acceptable levels and realize that not all of that spending will be in IT security dollars. By and large, IT security doesn’t pay for governance, it doesn’t pay for attitude, it doesn’t pay for commitment for excellence. With these things being paid for elsewhere, the IT security budget may be lower and likely result in lower risk (i.e., improved “security”).

We shouldn’t dwell on the size of this ratio; we should worry about the environment in which it exists. A spend of 10% in an immature, ad hoc, no-vision company, probably means they’ve spent the entire 10% on point security solutions ranging from desktop AV to firewalls to IDS and so on. Which means they spent little or nothing on policy, training, proper tools for developers and testers, and so on. Which means they are an accident waiting to happen - 10% not withstanding.

On the other hand, a lower percentage spent within a mature organization that also spends to foster and reward good thinking will almost certainly produce lower risk. Sure, mistakes will still make it into production and there will be problems, but there will be much fewer of them, they will likely be of reduced consequence because the organization knew to look for the big problems and also had effective response capabilities, and the organization will learn and not make those mistakes again. They will make new mistakes, but everyone does.

Be a proud goose. Organizations must not be afraid to use good governance, good training, and good process to their corporate and competitive advantage. If you do good strategic things, you will achieve better security with a smaller capital outlay that doesn’t all come from IT security. Organizations must be comfortable with their risk management story, and their efficient spending, and be able to tell it to the market, to customers, to regulators, and, if necessary, to juries.

Technorati Tags: governance

Did you ever catch a box turtle when you were a kid? They are beautify, affable and interesting little fellows. If you see one, catching them is no problem. You just walk over and pick it up. Even though it has a razor sharp jaw, its instinct is not to bite, but to pull in it head and legs and hope for the best. In a little while, after it realized you are not some bad actor, it comes out of its shell and begins the slow, deliberate process of escape. By my experience, turtles are pretty patient. If there is a tasty bit of lettuce along the route, they are content to stop and eat if, even if you sitting a foot away. Still, when the lettuce is done, they will continue their escape AND THEY WILL SUCCEED.

Their astounding rate of success has always amazed me. Without fail, I as a child, and each of my children in their day would put a turtle down somewhere in the yard and then go about some game or chore. We would glance back at the turtle every few minutes noting its slow progress to the fence or bushes. When the turtle got close, we would haul it back to the center. Then, patiently, it would resume its long walk. We would catch them a few times, repeating the cycle, but finally we would turn around the turtle was gone.

There are two possible explanations for this. The one I would like to believe is that turtles are wonderfully canny creatures and fleet afoot, who consciously lull us into a false sense of security before they dash to the perimeter with lightning quickness. I would like to believe that because I rather like turtles and would quite enjoy the thought that they are clever as well a cute. The more likely explanation is that it is simply impossible for us to pay sufficient attention to events that unfold so slowly. Turtles almost live in an alternate universe, with a wholly different time constant.

I like writing about turtles, but this is an IT blog, so let me extend the parable to something related to computing. My discourse goes through San Francisco. San Francisco has a great rail system – Bay Area Rapid Transit or BART which is highly automated. Back in the later 1970s they had an interesting accident. BART trains are largely computer controlled, with human operators monitoring for safety. Trip after trip, day after day, year after year, the computers would sense that the train was reaching the end of the route, slow the train to a stop, and start off on the return trip. The operator would walk to the opposite end of the train to once again be at the front. The system worked very reliably, so the operator grew comfortable relying on the computer, and would start his trek through the train before it had actually come to stop. You can see where this is going – one day the train missed the end of line single and didn’t stop, and the operator, who could have saved the day, was not at the controls.

There is a common lesson in the cases of the turtle and the BART train. Human beings cannot catch rare events. We simply cannot maintain the concentration. It is bad design to build a system where the human backs up the computer. The human WILL be day dreaming when things go wrong. It is better design to keep the human active and in the loop, literally running things or at least sharing responsibility, even when the computer can probably do it better. When the human fails (and he will) the computer will be there to back him up. A human and computer together can provide system redundancy, but only if the human is at the forefront and the computer as the backup.

Clearly we shouldn’t get carried away with this principle. We don’t want an accounting system where the math is done by hand with the computer checking the addition. In design of real time systems, though, this is a very important principle. It surfaced last week in a trading system I was reviewing. The system is used for large block trading (BIG deals). In my tests I found that you can enter an asking price that makes no sense (transposed digits or a shifted decimal point, for example). As I said, these are big deals, so you have to confirm the price before the deal closes, but you confirm not by entering the price twice, but by simply clicking “confirm.” In the heat of an active trading day, the traders who are very confident individuals will certainly hit confirm automatically, without actually reading the data. Ninety-nine percent of the time, this is not a problem.

Lest you think this sort of design problem is rare, you can trace the wreck of the Exxon Valdez and the navigational error that led to the shooting down of Korean Air Lines Flight 007 over the Kamchatka Peninsula to precisely the same human factors problem – using people to back up computers, not the other way around. The key message here is that when we design and test a system, we must focus on the whole system performs people included, not just the software.

When jOHN first accused me of being Captain Technology Curmudgeon, I was a little peeved because I’ve been of the opinion that its more how to make Ajax secure and not if it can be made to be secure. How can THAT stance be curmudgeonly? It was Gary that took the stance that Ajax is to be avoided.

So, I set about writing a talk for SD West about how to write Ajax applications that aren’t insecure (I do hate double negatives, but with security one can never really state that something IS secure). I based my talk on work I’d done with our client, research from the Web and my own experience writing Ajax.

At first, things seemed pretty encouraging. Ajax seemed to heighten the existing problems on the web. For example, there was the problem of good, API design for all of the additional services and the associated need for solid input validation and output encoding (albeit encoding for XML and JSON instead of XML). This all seemed pretty tractable because there are known solutions even if those solutions may not be wide practiced yet.

I should have sensed that the party was starting to end when I ran across “dynamic script tags”. I’m not sure why they are called “dynamic script tags” and why they aren’t called “subverting the JavaScript sandbox”. Here’s the deal. Say, I want to “mashup” content from two sites. Tres Web2.0. But the XMLHTTPRequest object limits me to downloading content from a site other than the one that supplied the calling JavaScript. So, instead of doing something more secure like doing the mashup on the server, why not just use an HTML tag that isn’t restricted by the same JavaScript sandbox rules.

In my younger days, I would have said “Nice hack”. Now, I just shudder because this subversion of the JavaScript sandbox is being promulgated on the Web as a feature instead of the rude flaw that it exploits. Okay, so this is slightly curmudgeonly…

I then found a paper by Stefano Di Paola and Georgio Fedon that described an attack called Prototype Hijacking. Now, “Prototype” isn’t in reference to the popular JavaScript framework - it’s in reference to the fact that JavaScript uses prototype-based inheritance rather than class-based inheritance. Due to the dynamic nature of JavaScript, I can change the prototype for any JavaScript object. Most excellent. Let’s change the prototype of, say XMLHTTPRequest. Maybe the “Send” method?

So, securing Ajax applications is going to be harder than I thought. I’m not sure how to prevent Prototype Hijacking - well not yet at least. So, jOHN, how can THAT be curmudgeonly?

Technorati Tags: AJAX, AJAJ

(with apologies for complete lack of artistic merit)

feng shui governance
plan, influence, and conduct
policy for all

from boardroom to bits
everyone get on board
a single train forward

a balanced approach
harmonious existence
with stakeholders all

set tone at the top
the key of transparency
all must understand

solving all problems
a terrible goal to bear
just cut barriers

how to change things now
like escape from klein bottle
reverse of trip in

business objectives
publicly painted for all
now all can align

our key resources
named, owned, prioritized, staffed
requirements sketched

cooperation
embrace management’s vision
collaboration

internal control
believable proof for all
this is a good thing

need innovation
old way causes much sadness
delightful change now

who must get what done
true responsibility
good authority

what must get done when
relate business to people
and goal them quite well

when must it get done
everything can’t be first
true order defined

where does it happen
are all things prepared for it
measure twice, cut once

how to accomplish
training, coaching, mentoring
lead by example

why is it crucial
all must recite the drivers
to you and to me

it’s about people
enable them to succeed
show you care about them

expect and inspect
balanced scorecard works for most
dashboards are fun, too

you are not there yet
a continuous journey
goals ever-changing

quite learned you are
required knowledge deep inside
express yourself now

P.S. Although I though I was the first to use “feng shui governance” as a term, I noticed that there was a single hit in Google (a three-word GoogleWhack!) used by a Mr. Foldvary back in 1999 in a somewhat different context.

Technorati Tags: governance, doggerel