To validate or not to validate... that is the question!

Secure development guidance preaches that all input should be validated for length, format, type, and value as appropriate. Typically, guidance stretches along the lines of validate all input that your code takes and validate accordingly. A few years ago there was a similar belief that input validation can stop cross-site scripting. Although this is partially true, full remediation of cross-site scripting is achieved by properly encoding the input data according to the context in which it is later outputted.

So here comes my question, in order to validate input properly, isn't it better to have the validation to be performed by the code that will act on it as opposed to having the validation at the trust boundary of the overall app? Example: Component1 uses Component2 for backend logic. If Component1 only passes the data straight through to Component2, my belief is that Component1 should leave the input validation to Component2. Thoughts?

SDL courses in the public

A while ago I was pointing out some interesting stats about the secure development lifecycle (SDL). Last week, Microsoft made its four core SDL training classes available to the public. The titles are:
- Basics of Secure Design Development Test
- Introduction to the Microsoft Security Development Lifecycle (SDL)
- Introduction to Threat Modeling
- Privacy in Software Development


I would encourage everyone with a bit of spare time to take a look at these courses.

The 7 plagues of testing

James Whittaker was running the series of the 7 plagues of software testing on the Google Testing Blog. Since the series are at their last stretch, here is the list of plagues:
1. The Plague of Aimlessness
2. The Plague of Repetitiveness
3. The Plague of Amnesia
4. The Plague of Boredom
5. The Plague of Homelessness
6. The Plague of Blindness
7. The Plague of Entropy

There are also some additional plagues that were suggested by various readers (myself included):
- The Plague of Metrics
- The Plague of Semantics/Assumptions
- The Plague of Infinity/Endlessness/Exhaustion
- The Plague of Miscommunication/Language
- The Plague of Rigidness/Complacency

Out of the suggested bunch, I really like Roussi's notion that complacency can be the result of a product's success.

Recycling security test cases

Test cases are precious. In my day to day work, a lot of what we do is built around the notion that a test case either passes or fails. Think about the time when you withdraw money out of your favorite ATM or when your favorite application may have compromised your privacy... it's always the case of a passed or failed test case. Is there a flaw in the system? Can the system under test be put to its knees because of it?

A while ago James Whittaker talked about building repositories with reusable test cases. The whole discussion is available at the MSDN blogs. I definitely recommend reading it. As applications often have common flaws, it is beneficial to have such a repository. Tweaking the test cases to the application under test is definitely a "must-do". However, once those tweaks are done for the particular software under test, the job gets much easier.

Reflecting at the security industry, it's hard to not notice the need for James's idea to be adopted. In fact, a typical problem report from a security vendor will include the following bits:

1. What is the problem?


2. How can the problem be reproduced?


3. How can the problem be fixed?

Maybe we should start swapping the second bit with the actual executable test case? I know it's hard to do this for any type of application, but for the most common type -- Web apps -- it's certainly doable. Just look at tools like Selenium and you'll get the idea.

New Version of Guidance Explorer is Out

Last week I got news from Jason that a new version of Guidance Explorer is available. For those who don't know, Guidance Explorer is an authoring tool for knowledge base articles of any kind and on any topic. Having used the tool for over a year, I'm quite happy to see that it's making progress. I strongly recommend this tool for anybody organizing articles, creating software, or being simply curious.

Dual Monitor vs Productivity

Alis just sent me this awesome comic strip. Why do I see myself in it sometimes? :)

The original comic strip can be found on PHD Comics.

Threat modeling in the business world

For a while now I've been trying to figure out the best fit of threat modeling in a microeconomic, business, non-security related setting. For those not familiar with the process, the SDL blog provides a nice article that explains it from a software point of view. Although threat modeling may seem like a self explanatory task, there are some specifics that need to be handled carefully for the model to be helpful. For instance, the classic STRIDE and CIA models are applicable when trying to protect company assets, information, and resources; but how does it fit from a pure business perspective where business development and operations management is the primary focus? Would there be a ranking according to which business risk can be identified? If so, how would that model look? Can there be standard approaches to mitigating certain types of business risk?

Virtualization and the business aspects behind it

It seems like software virtualization has been gaining more popularity recently. With companies like VMWare going public with their stock a push for virtualization is imminent.

From a technical perspective and project execution virtualization is great. It provides the mechanism for shorter turnarounds on project setup, deployment, and removal. This allows project managers to incorporate more slack time into a project's schedule, which in the end results into more time spent on the actual project and more value for the customer. As a step further, the open source community has released a set of pre-built virtual machines that are available to the general public. At the other hand, virtualization at the engineering level provides easy ways to re-configure an environment (including hardware), restore a system to a given state, or simply back-up or clone a system. The ability to do so helps engineers spend less time on maintenance and focus more on the actual problems that are faced throughout the project, which is an incentive for better quality of work. But is virtualization really all that great?

Most commercial software products and services today are distributed under a license in the form of a product key or as a subscription. Both business models are fairly simple. While subscription forces end customers to renew their access to the product or service via a short term license, the product key scenario usually asks end customers for a one time product activation that enables unlimited use of the product. How does virtualization applies to both models?

Among all of its nice uses, virtualization provides a mechanism for backing up or copying virtual machines. Unfortunately for software vendors, replicating virtual machines also replicates any installed software. As such, it is possible to use a single activated copy to suit the needs of multiple users simultaneously. In this scenario the impact of virtualization on the subscription based model is fairly limited. Businesses that have adopted such model should still see a constant stream of revenues with an occasional increase at the time of subscription renewals. This, however, doesn't seem to be the fate of single activation licensing.

Self development

Jason posted recently a few great articles on how to improve the personal skills in the work environment. I find the material very useful and I'd encourage everyone to read them.

Here are the articles:
Don't Focus on the Rocks
How To Be an Effective Leader