Saturday, 9 January 2010

Software Program Maintenance

Software maintenance introduces more bugs. Through an analysis of the debugging progresses and the program fixes, it was clear that systems deteriorate over time. As a part of an ongoing research and analysis of software risk metrics, I have been analysing bugs and vulnerabilities as a function of coding practices for a number of companies.
clip_image002
What we see is that the first iteration of bug fixes leads to a second and subsequent series of fixes. In each set of fixes, there is a 20-50% (mean of 34% clip_image0048%[1]) of the fix creating another round of bugs. This drops on the second round of fixes, but starts to rise on the 3rd and subsequent rounds. In a smaller set of code, the low overall volume of bugs limits the number of iterations, but the larger code samples led to up to 6 iterations. This would be expected to be even larger on extremely large programs (such as an Operating System).
image
What we see is a slow deterioration of the code. As fixes occur, these introduce more and more bugs. On top of this, as new bugs are being introduced, old ones are still being uncovered.


[1] 95% Confidence Interval or clip_image006

Friday, 8 January 2010

RSA 768 has bitten the dust

I see that RSA 768 has bitten the dust. What is interesting is the relationship to bits and compromise of the algorithm.

See http://eprint.iacr.org/2010/006.pdf  for the paper and how it was done.

The previous record NFS factorization with respect to RSA a 663-bit RSA-200 key on May 9, 2005.

Based on the factorisation rates from the 512 bit key, this makes a 1.7 bit per month result (+/- 0.12). This is not similar to the growth of computational power at 1.039 per month (or a 2.0 factor each 18 months).

1024 bit keys have not been factored as yet, but an estimate based on the results in factoring RSA from 2001 to the present, one could expect (if the current extrapolation holds) that 1024 bit RSA keys will be factored between August and Sept 2021 (+/- 5 months).

However, based on a number of details of the sieving process, if I had to put money on this, I would place my bet at Jan 2018.

Thursday, 7 January 2010

Software Security as a Stag Hunt

George Akerlof’s model, “A Market for Lemons[1] as was designed for modelling quality uncertainty has been proposed as a model for the software industry[2]. This model is based on information asymmetry and the presumption that the vendor has more knowledge of the product than the user. This is a fallacy in that the software vendor is incentivised to correct bugs as early in the process as is possible (the later a bug is discovered in the development process, the more it costs to fix). Hence, the vendor does not have more of an idea of the expectations of flaws than a knowledgeable user. Further, the user knows how they plan to deploy the software; the vendor does not have this information and may have little insight into what other interactions may occur.

The software game is also sequential with multiple iterations. The vendor wants to maintain a relationship with the user and as the software is used, it can be assessed against the assertions of the vendor. Further, the user can generally compare the past performance of the vendor.

A better model for the software industry is the “Stag Hunt”. This was based on Jean Jacques Rousseau’s postulations of a co-operation strategy between two hunters. These individuals can either jointly hunt a stag or individually hunt a rabbit. The largest payoff is assigned against the capture of a stag which provides a larger return than the hare. The hunting of a stag is more demanding and requires mutual cooperation. If either player hunts a stag alone, the chance of success is negligible and sub-optimal. Hunting stags is most beneficial for society in that this activity creates the optimal returns. The problem with this game is that it requires a lot of trust among the players.

This game has two pure strategy equilibria in which both of the players prefer the lower risk equilibrium to the higher payoff equilibrium. The game is both Pareto optimal and Hicks optimal, but the sub-optimal and hence inefficient equilibrium poses a lower risk to either player. As the payoff variance over the other player's strategies is less than that of the optimal solution, it is more likely that this option will be selected. Another way of stating this is that the equilibrium is payoff-dominant while the other strategy is risk-dominant.
image
Figure 1. Software Markets as a “Stag Hunt”

The strategy between the vendor and the Software User is displayed in Figure 1. In this, the numerical representations represent the payoff figures for the specific case (the software market) and the generalised relations take the form:
clip_image002clip_image004 ... (1.1)

The outcomes are not definitive statements of what will be produced. In this game, the “Stag” is a desire to “Create Secure Software” and the “Hare” the fallback to adding more features. A desire is not a case of creating fewer bugs by itself, but rather a combination of adding controls and testing to software. Such an example would be the addition of the XP to Windows XP SP2 by Microsoft. Additional testing is effective to a point and more can be done than is occurring at present[3].

The payoffs for creating more secure software are great for both the vendor and the user, but the risk of a misaligned strategy leads to the sub-optimal equilibria. What is needed is a signalling process. A signal will allow the players to align to the more optimal strategy. It is not only in the user’s interest to have more secure software, but also is in the interest of the vendor. Patching is expensive and the vendor can reasonably charge more for secure software.

A problem with a sub-optimal equilibrium is that “talk is cheap”. A player's strategy is not only whether to hunt stag or hare, but also what signal to send, and how to respond to signals he receives. In order to switch from the hare hunting equilibrium (more Features) to the other, over three quarters of the population must simultaneously switch strategy to require secure software. This is a simple situation when there are only 2 players, but becomes more complex in an n-player game.

As the ratio between the payoff for stag hunting and the payoff for hare hunting is reduced, the incentives to move towards stag hunting decreases. As a result, it becomes less likely that software security will be made into a primary goal of either party. As such, where the introduction of features and the “new killer app” occur more frequently, software security lags and it becomes more likely that a change from a stag hunting equilibrium to a hare hunting equilibrium will occur. It is hence less probable that an alteration of the players strategy from hare to stag.

This is where the development of a software risk derivative would be of service.
One possible solution to the limited and sub-optimal markets that currently exist would be the creation of Hedge funds for software security. Sales in software security based derivatives could be created on forward contracts. One such solution is the issuing of paired contracts (such as exist in short sales of stocks). The first contract would be taken by a user and would pay a fixed amount if the software has suffered from any vulnerabilities on the (forward) date specified in the contract. The paired contract would cover the vendor. If the vendor creates software without flaws (or at least mitigates all easily determinable flaws prior to the inception of the contract) the contract pays them the same amount as the first contract.


[1] Akerlof, George A. (1970). "The Market for 'Lemons': Quality Uncertainty and the Market Mechanism". Quarterly Journal of Economics 84 (3): 488–500. doi:10.2307/1879431
[2] See, Bruce Schneier (http://www.schneier.com/blog/archives/2007/04/a_security_mark.html); &
Ross Anderson. 2001. “Why Information Security is Hard – an Economics Perspective.” 17th Annual Computer Security Applications Conference. New Orleans, LA, USA.
[3] Esp. With vendors such as Adobe who seem to not thin k of bugs as a problem.

Wednesday, 6 January 2010

Software Vendor Reputation

The introduction of an exculpatory rule in contracts allows for the negation of a legal ruling (the default rule) where both parties have (through the contract) expressly consented to the contrary. A car maker is not liable for the life of an engine exceeding 60,000km unless there is an express warranty stating this. Similarly, there is not expresses exculpatory rule for software unless the vendor offers this in a warranty clause[1].

Legislation can make many superficial exculpatory clauses either invalid or redundant. Such an exclusion would include negligence. In some cases, the exculpatory clause merely states that law as it is understood. Where an exculpatory clause is permissible, the final assignment of liability does not depend on the preliminary distribution of liability. If the default rule is that a software vendor is liable for software vulnerabilities, but the vendors profitability is greater where it does not suffer liability, then the vendor will print a label (in the case of software this could be a click wrap agreement[2]) stating that is it not liable.

Where the profit made by the vendor is greatest if the vendor is liable, there will be no need to include a warranty or click wrap agreement with the software. The only effect of allowing exculpatory clauses for software is that a transactional cost is introduced[3].

There are reasons for the software vendor to assume liability[4]. The vendor could create a couple versions of software[5]. One of the versions could be targeted at a high security installation and the other towards a lower end user base with a lower security requirement[6]. The high security version could be hedged with a contract covering the risk.

If the vendor creates the low feature version for $200 and the full featured secure version for $800, the user can choose the level of protection. Taking a survival model of Windows 98 and one for Windows XP[7], the client can calculate the expected difference from each product. If Windows 98 has an expected compromise rate (without other compensating controls) of once per 6.2 days and Windows XP has an expected rate of 52.5 days when the firewall is enabled[8] we can calculate the cost per incident. If the user has a mean cost per incident of $320[9], we see that the Windows 98 option has an expected annual cost to the organisation of $19,040 ($18,840 damage plus $200) whereas Windows XP has an expected cost of $3,825 ($3,025 damage plus $800).

Hence, most companies[10] with a need to secure systems selected the more secure option and installed Windows XP over Windows 98. The initial costs did not reflect the overall costs to the organisation. Likewise, home users (who rarely calculate the costs of compromise) where more likely to install the cheaper option.

To extend the analogy, the us assume that a software vendor can create a perfect version of software for a mean cost of $20,000[11] and the flawed version at the standard costs, we see that it remains in the user's interests to select the lower security option as the expected losses are lower.

The vendor could offer liability-free and full-liability versions of their product, the later sold at a reduced price. The vendor could then control their risk using a hedging instrument[12]. A market evaluation of the risk being traded would provide better information than that which the vendor has alone[13]. With this in mind, the user could also purchase the same derivative as the vendor. The cost to the user to purchase the software plus risk insurance would be less than purchasing the "more secure" version from the vendor as the vendor would hedge the risk it faces and add a transactional cost as well as a return (at the firms IRR).

Here we can easily see that both parties are better off where the vendor produces the optimised but less secure version of their product and where the vendor does not assume liability for bugs. What we need instead is a market mechanism to equalise risk.

Simply put, the vendor will provide a warranty (which acts as an insurance policy for the user) in cases where it can charge more for the provision of the warranty than it costs to provide the warranty. This cost could be either from a hedging instrument or through an investment in more testing. However, it must be noted that no increasing testing will make software invulnerable to all attacks and remove the ability for flaws to be discovered. As such, the cost of the hedged derivative will decrease, but will not go to zero.

The argument against this form of market is imperfect information. Many people argue that the software vendor has more knowledge than the user. As noted above, this is untrue for several reasons. As noted above, the vendor has no incentive to hide vulnerabilities as these cost the vendor through a decrease in capital. Next, the vendor would be competing on the same derivative markets as the users. The vendors knowledge would be quickly and efficiently transferred through the market mechanism.

The end result is that a derivatives based strategy does not allow for information asymmetry and would disprove entirely the assertion that software vendors operate a "market for lemons". Rather, we have a completely different game in the software industry. This does not mean that it is optimal, just that we have a different sub-optimal game to model.

From this we can see that the lack of liability does not require that the software vendor does not have the appropriate incentive to provide the optimal amount of testing and hence security (as well as to add the optimal levels of external controls) to the user. If more testing is cost effective in economically providing more secure software, that is if the additional testing is cost effective, the software vendor will conduct this testing whether it is liable for security flaws or not.

The incentive to provide security is no different than the incentive to provide other characteristics and features. A vendor will add software extensions that can reduce the overall security of a system if the user values these to a greater extent than their costs.

Safety (and security in general) is a tie-in good.
Amenities cost something. Vendors provide amenities if consumers (users) are willing to pay the cost of obtaining these.

"Cars come with batteries and tires, but not always with stereo equipment or antitheft devices and rarely with driving gloves and sunglasses"[14]
What is demonstrated by those organisation with a defensive (and hence secure) coding regime is a lower variability in output. The mean coding time will remain similar, but the test time can be expected to be distributed differently for the organisation that codes with a defensive posture than that of the organisation who leaves too little time for testing. This increase in the standard deviation of produced results (or variability) increases the risk to the to all parties (vendor and user).
See Optimal Derivatives Design under Dynamic Risk Measures[15]
The game theoretic approach to this is can be modelled looking at the incentives of the business and programming functions in the organisation. Programmers are optimists[16]. As Brooks (1995) notes, "the first assumption that underlies the scheduling of systems programming is that all will go well". Testing is rarely considered by the normal programmer as this would imply failure. However, the human inability to create perfection leads to the introductions of flaws at each stage of development.
(See Dorothy Sayers, "The Mind of the Maker")
In the model presented by Brooks (1995), as a program moves to a "Programming Product" and then to "a Programming Systems Product"[17], there are incremental additions that extend the estimates of the programming team. At each phase these can be expressed as a function of effort expressed in the lines of code, clip_image002. We can express the mean effort clip_image004required to code a number of lines and the variability[18], clip_image006in achieving this outcome. This allows us to represent the coding effort as a representation of the stages of development:
clip_image008 x.4
In x.4, clip_image010is the function of systematising[19] the code. The expressionclip_image012is the productization[20] of the code.
The derivative would require the firm to publish their productivity figures;
1. Lines of code per programmer (and standard Deviation); clip_image002[1], clip_image004[1]and clip_image006[1]
2. Bug-incidence figures; clip_image014and clip_image016
3. Estimating and project rules/methodology
4. Software design methodology
5. Secure Programmer measures (e.g. SANS Coding Methodology); clip_image018and clip_image020
Many see this as proprietary data and would be loathe to share, but as more in the market take-up the use of such a derivative in managing their own risk, the incentives for others to follow increase. We can also demonstrate that as clip_image022and clip_image024that the volatility in coding clip_image006[2] and clip_image016[1] decrease with the number of reported bug incidents clip_image026as clip_image022[1].
More metrics would be required based on the methodologies and coding practices used with different computer languages expected to exhibit different responses[21]. (again, I am still working on the plots).
clip_image028
As the skill of the programming team (clip_image022[2]&clip_image024[1]) increases through group training, secure coding practices and in-line testing, the volatility in coding clip_image030As the incremental returns onclip_image018[1]diminish as clip_image022[3]and the cost of training continue to grow linearly[22], we can see that the optimal position for any software vendor is to have a skilled team that maximises returns. At this point, additional training becomes economically unviable and does not create further returns for the organisation[23].We also see that it is in the interest of the firm to minimise the variance in skill levels between programming staff (aim to haveclip_image024[2]). This of course adds costs as junior staff would be less productive in that they would have to work with more senior staff[24] in order to both cross train and to ensure that the junior staff maintain an acceptable level of production and testing.

This exercise of joining junior and senior staff would create a return function depicted by Brookes (1995, P19) for a "Time versus number of workers - task with complex interrelationships". The output of the junior/senior staff unit would be lower than the senior staff level (initially) but would lower variability and increase the skill levels of the junior staff and hence over time clip_image024[3]. Due to staff turn-over[25] and the increasing costs of maintaining more skilled programmers, this would also have a negative feedback on the vendors production costs. This would also need to be optimised rather than maximised if the vendor is to maximise returns.

[1] Software vendors offer limited warranties (I covered this in my LLM Paper) that provide some protection for the user, but this is limited.
[2] Add Ref. See my LLM thesis - Click Wrap section
[3] This includes the cost of hiring the legal team, the cost of marketing people vetting the click-wrap agreement and the cost of printing the clause.
[4] See Hedging
[5] Such as Windows 98 and Windows NT by Microsoft
[6] Conversely, the vendor could have the stripped down version of software and one that has extra features (such as firewalls and additional logging)
[7] I shall be adding a Link to quantitative study results
[8] In each case we are presuming that the CIS (ref) standards for installing the software have been reasonably met. See quantitative results
[9][9] Based on quantitative data - ref report
[10] ref to be added
[11] Which is an extremely low estimate
[12] As discussed earlier
[13] Not only does the market pooled knowledge feed into the price of the derivative, but the vendor's knowledge of their own product does as well.
[14] "Economic Foundations of Law and Organisation " Wittman, Donald (2006), , Cambridge University Press.
[15] Pauline Barrieu and Nicole El Karoui
[16] Brooks, F.P. (1995) "The Mythical Man Month, Anniversary Ed." Re-Printed 2008, Addison Wesley Longman, USA (p14)
[17] Through the addition of a "Programming System" with the addition of Interfaces and a System Integration Phase
[18] Standard Deviation (where )
[19] Brooks p 6
[20] Brooks P6
[21] Which would be quantified through the market method
[22] That is, where there is an initial cost plus a linear increase in the costs of developing the programmer skills.
[23] This investment may still be made by the individual programmer with returns to the organisation and also for further personal gains (investment in personal capital).
[24] Also reducing the output of the senior staff.
[25] F. J Corbato' (MIT) - A long duration project needs to incorporate a turnover rate of at least 20% per annum. New hires need to be technically trained and also require time to be able to effectively integrate into the existing team.

Tuesday, 5 January 2010

Software costs

As stated, I plan to publish some of the preliminary results of the quantitative risk research I am conducting. At present, I have been analysing project costs for 277 software projects.

 

It is clear from the results that there is an optimised ideal for software testing. The costs of finding bugs go up as the cost of software is tested to remove more bugs.

image

We can demonstrate that the costs of testing relate to the Cobb-Douglass function. In the sample of 277 coding projects, I have a function of: 

clip_image002

In this example, we have found clip_image004and clip_image006where c and C are constant values.

I have not prettied up the plots and nor have I done much of the refinement that will go into the published paper, but for a few simple metrics we see that complexity adds exponentially to the costs.

image

The previous plot has an exponent of around 1.5 (this is the exponent of the equation that describes the plot is not linear). In this case, the largest program in my sample was approximately 300,000 SLOC (source lines of code).

 

So we can see that longer programs cost more (nothing new to anyone who has programmed).

image

The number of bugs found does vary greatly. This is those bugs found within a year of the code being released, so the true numbers may be higher. However, it comes to reason that if the bug has not been found in a 12 month period, it would be expensive to find.

 

What was interesting is the distribution of bugs as a percentage of code.

image

We can see that there is no correlation between the levels of bugs in code and the length of the code. I did find this surprising. There are more bugs in large code, but the number of bugs per line does not increase greatly. The clip_image002[4]value (the Pearson correlation co-efficient) is close to zero (and is actually slightly negative, but not at a statistically significant level).

 image

The axis on the histogram is the ratio and not the percent (as I stated, I have not prettied up the plots). These are the totals of the bugs in the software projects analysed and not those discovered post-release. I have not classified the stages of development where the errors occurred most frequently as yet. I also need to split some of the results by coding language.

image 

I did find that the numbers of bugs where far too high.

Many of these are functional and did not pose security threats, but the economics of repairing them remains. The mean for the tests was 5.529% (or 55 errors per 1,000 lines of source code).

 

If anyone has any data from a really large code project (such as Windows, Linux etc) I would be interested in haring about it and incorporating the data into my research.

Software is by nature a complex system and is only becoming more so.

We need to move from "Lines of Code per day" as a productivity measure to a measure that takes debugging and documentation into account. This could be something such as "Lines of clean, simple, correct, well-documented code per day". This also has problems, but it does go a long way towards creating a measure that incorporates the true costs of coding.

 

The primary issue comes from an argument to parsimony. The coder who can create a small, fast and effective code sample in 200 lines where another programmer would require 2,000 may have created a more productive function. The smaller number of lines require less upkeep and can be verified far easier than the larger counterpart.

Monday, 4 January 2010

Why charge for a personal guarantee?

From time to time, people wonder if they should assume a personal guarantee for a company they are associated with or a person they know. This is a personal decision, but I believe that to correctly and rationally make this decision, one needs to be able to quantify the cost of the decision.

The risk of a default, even from family member has a cost. This is not a zero value. It also may be a debt that follows you even after you have stopped being a director with a company. Risk has a cost. This is what the nature of interest is based on. We all like to believe that a company we are associated with will not fail, but this is not always the case. On top of this, if the company is sold, it could be sold without a transference of the guarantee. This means that you are left with the debt whilst receiving no consideration.

Next, this is a direct cost. Legally, you have to declare the guarantee on all loan applications. This both lowers your credit rating and also increases the expected interest that you will be charged if you obtain a loan. When calculating the maximum amount that you can apply for (for instance a home loan) the guarantee will be included in this amount and will hence lower your capacity to borrow money.

If you do not disclose the guarantee and fail to repay a loan, you could be charged with fraud. This will also allow the financial institution to recover on real property even on an unsecured loan.

Finally, risk is a cost. Risk is the probability of a loss being solidified. As a result, you can directly quantify the cost associated with a risk by calculating the likelihood of loss by the loss if solidified. There are more advanced (and hence accurate means to do this - such as MCMM or Monte Carlo Markov Methods) as well but the cost of the calculation also should be considered.

The end result is that if you have an expected 5% (once each 20 occurrences) likelihood of a loss (this is a low expectation) of a $250,000 guarantee, you can hence associate a direct cost of $12,500 to the guarantee.

You may decide to wear this cost or to transfer it, but it is important that you know it exists so that you can account for it correctly.