Perilocity

Better Products Bootstrap

Gunnnar notes the formation of a software vendor security best practices consortium and asks:

Why not bootstrap a Fortune 500 Secure Coding Initiative to drive better products, services and share best practices in the software security space?

— Secure Coding Advocacy Group, Gunnar Peterson, 1 Raindrop, 23 October 2007

Yes, if the customers demanded it, that might make some difference, and the vendors do pay the most attention to the biggest customers. Of course the biggest customer is the U.S. government, and they seem more interested in CYA than in actual security. And I'm a bit jaded on "best practices" due to reading Black Swans. But regardless of the specific form of better such a group demanded, demanding better security might make some difference.

Maybe they could also demand risk management, which would including having watchers watching ipsos custodes. Not just in the circular never-ending hamster wheel of death style, but for actual improvemment.

-jsq

What It Will Take to Win

IT and Internet security people and companies act mostly as an aftermarket. Meanwhile, the black hats are a well-integrated economy of coders, bot herders, and entrepeneurs. This is what it will take for the white hats to win:

It can seem overwhelming for security people who are typically housed in a separate organization, to begin to engage with software developers and architects to implement secure coding practices in an enterprise. While the security team may know that there are security vulnerabilities in the systems, they have to be able to articulate the specific issues and communicate some ideas on resolutions. This can be a daunting task especially if the security team does not have a prior workign relationship with the development staff, and understand their environment.

...

The task seems daunting also because there are so many developers compared to security people. I am here to tell you though that you don't have to win over every last developer to make some major improvements. In my experience a small percentage of developers write the majority of code that actually goes live. The lead developers (who may be buried deep in the org charts) are the ones you need to engage, in many cases they really don't want to write insecure code, they just lack the knowledge of how to build better. Once you have a relationship (i.e. that you are not just there to audit and report on them, but are there to help *build* more secure code) it is surprisingly easy to get security improvements into a system, especially if the design is well thought and clearly articulated. You don't have get the proverbial stardotstar, each and every developer on board to make positive improvements, it can be incremental. See some more specific ideas on phasing security in the SD! LC here. In meantime, with security budgets increasing 20% a year, use some of that money to take your top developers out to lunch.

— Secure Coding - Getting Buy In, Gunnar Peterson, 1Raindrop, 17 Sep 2007

The start of what it will take.

-jsq

Quantitative >= Qualitative

See Pete Lindstrom's Spire Security Viewpoint for empirical evidence that mechanical quantitative diagnosis is almost always at least as good as clinical qualitative diagnosis.

There is still plenty of room for qualitative decision-making in arenas where there aren't enough facts or the facts haven't been quantified or there's no baseline or there's no mechanical method yet. But where those things are available, it's better to use them. You'll still need qualitative judgement for cases where the algorithm is right but it didn't take into effect unfortunate side effects, for instance. Even then, you've got a better chance of knowing what you're doing.

-jsq

Metricon: Puzzle vs. Mystery

Here at Metricon 2.0, many interesting talks, as expected.

For example, Russell Cameron Thomas of Meritology mentioned the difference between puzzle thinking (looking only under the light you know) and mystery thinking (shining a light into unknown areas to see what else is out there). Seems to me most of traditional security is puzzle thinking. Other speakers and questioners said things in other talks like "that's a business question that we can't control" (literally throwing up hands); we can only measure where "we can intervene"; "we don't have enough information" to form an opinion, etc. That's all puzzle thinking.

Which is unfortunate, given that measuring only what you know makes measurements hard to relate to business needs, hard to apply to new, previously unknown problems, and very hard to use to deal with problems you cannot fix.

Let me hasten to add that Thomas's talk, entitled "Security Meta Metrics—Measuring Agility, Learning, and Unintended Consequence", went beyond these puzzle difficulties and into mysteries such as uncertainty and mitigation.

Not only that, but his approach of an inner operational loop (puzzle) tuned by an outer research loop (mystery) is strongly reminiscent of John R. Boyd's OODA loop. Thomas does not appear to have been aware of Boyd, which maybe is evidence that by reinventing much the same process description Thomas has validated that Boyd was onto something.

-jsq

Wildfire Myopia

It looks like technological security isn't the only kind disorganized in government. The latest GAO report about wildfires seems like more smoke than fire:

This testimony summarizes several key actions that federal agencies need to complete or take to strengthen their management of the wildland fire program, including the need to (1) develop a long-term, cohesive strategy to reduce fuels and address wildland fire problems and (2) improve the management of their efforts to contain the costs of preparing for and responding to wildland fires.

...

For cost-containment efforts to be effective, the agencies need to integrate cost-containment goals with the other goals of the wildland fire program--such as protecting life, resources, and property--and to recognize that trade-offs will be needed to meet desired goals within the context of fiscal constraints.

— Wildland Fire Management: A Cohesive Strategy and Clear Cost-Containment Goals Are Needed for Federal Agencies to Manage Wildland Fire Activities Effectively, GAO-07-1017T, U.S. General Accounting Office, June 19, 2007

How about a strategy for integrating wildfire planning into subdivision planning, or cost allocations from homeowner wildfire insurance?

FISMA Failing

Shades of SOX complaints: the U.S. GAO reports that the Federal Information Security Management Act (FISMA) is failing:

When we go out and conduct our security control reviews at federal agencies, we often find serious and significant vulnerabilities in systems that have been certified and accredited. Part of it, I think, is just that agencies may be focusing on just trying to get the systems certified and accredited but not effectively implementing the processes that the certification and accreditation is supposed to reflect.

— Q&A: Federal info security isn't just about FISMA compliance, auditor says, Most agencies still have security gaps, according to Gregory Wilshusen, by Jaikumar Vijayan Computerworld, June 14, 2007

Sounds like they haven't implemented numerous simple security measures that were known before FISMA, they don't have processes to do so, and they don't adequately report what they're doing, even with FISMA. What to do?