Long Term Impact of Youthful Decisions
There’s a fascinating article in the New York Times last week, “Expunged Criminal Records Live to Tell Tales” about how companies like Choicepoint which collect and sell public records don’t pick up orders to expunge those records.
I didn’t have much to add, and figured the Times doesn’t need me to pimp their articles (they get a few more readers each day than we do), so I let it alone.
Then I saw Gunnar Peterson discuss “Brian Chess on Evolving Risk Models:”
When a company starts its life it wants to take on as much risk as it possibly can, do something hard and prove it in the marketplace. If it is not too risky then a big company may take you out or there may be no market. Over time a successful company’s market risk should go down as it gains market share.
Where this becomes interesting from a security standpoint is that early in the company’s lifecycle, the business has high market risk, but little security risk, there is not much in the way of assets to target. But over time as the business gains market share its security risks grow. This puts security in a very interesting position where there have to make up for a lot of lost time even if the decisions to delay security made sense at the time, the risk profile have readjusted to the point where more mature businesses who are established in the market and have relatively little residual market risk, at the same time the business takes on more and more security risk. In general this means the code, the config, data and identity architectures all must play catch up to deal with the risk profile over time.
These design and implementation choices also live to tell tales. I expect over the next few years, a rise of highly effective testing tools will act as a force multiplier for elite researchers, making it less and less possible to expunge evidence or records of security choices made. We’re going to have to start asking questions about security activity during the procurement process. Think of it as background checks for your software.
This reminds me of the Gartner analyst’s quote in the NY Times article on contactless credit cards. It sure looks like the card issuers sacrificed encryption of data in favor of time-to-market and hoped no one would notice. One of the differences between credit cards and software, however, is that credit cards stay in place for years and typically can’t be patched short of a reissue…
(Another factor in the credit card case, of course, was that the card companies claimed repeatedly that the data would be encrypted. Too bad it didn’t get implemented that way.)
In any case, there’s probably an interesting WEIS paper that could come out of putting together a model for when it makes sense to defer security expenditure and when not. Do you know if it’s already been written?
I make a similar point in the GP story. I go a bit further and incorporate the likelihood that the security model first suggested is plain wrong, and also that any costs incurred by security feed materially into reducing the chances of survival of the company. In fact, employing security in the early days could be the reason that most security-oriented companies fail, which was the observation that got me thinking about it.
The simple hand drawn graphic in GP4.1 Mutual Funds bears a resemblance to the one above, but is only related, not equivalent.