Category Archives: Agility

Mastery and Secure Coding

Brooks extended:

Each thing we are trying to push for in secure coding these days requires mastery, Cardspace, static analysis, threat modeling, web service security, and friends are very deep individual domains, and when applied to an enterprise they get wide as well. Let me underline that – to deploy any of the current cutting edge stuff in software security at scale, requires technical depth and deployment width. This automatically limits your resource pool of who can deliver this stuff.

So what I have seen work well is using a decentralized, specialist team approach with a very specific agenda and goals. Note the team can be very small, 2 or 3 people even if they are empowered.

— Go Wide and Deep, Incrementally, Gunnar Peterson, 1 Raindrop, 10 JJan 2008

Not only can’t you make a late project on time by throwing people at it, you can’t really make a project secure by throwing people at it.

-jsq

Chinese Honeynet Project: Botnets Are Sneaky and Evolving; Need Adaptive Distributed Counter

lifetime.png The subject is my interpretation of a sixteen page paper by a joint Chinese-German project to examine botnets in China.
Botnets have become the first-choice attack platform for network-based attacks during the last few years. These networks pose a severe threat to normal operations of the public Internet and affect many Internet users. With the help of a distributed and fully-automated botnet measurement system, we were able to discover and track 3,290 botnets during a period of almost twelve months.

— Characterizing the IRC-based Botnet Phenomenon, Jianwei Zhuge1 , Thorsten Holz2 , Xinhui Han1 , Jinpeng Guo1 , and Wei Zou1 Peking University Institute of Computer Science and Technology Beijing, China, University of Mannheim Laboratory for Dependable Distributed Systems Mannheim, Germany, Reihe Informatik. TR-2007-010

The paper provides many interesting statistics, such as only a small percent of botnets are detected by the usual Internet security companies. But the main point is exactly that a distributed and adaptive honeypot botnet detection network was able to detect and observe botnets in action and to get data for all those statistics. Trying to deal with an international adaptive botnet threat via static software or occasional centralized patches isn’t going to work.

Some readers conclude that this paper shows that reputation services don’t work,because they don’t show most botnets. I conclude that current reputation services don’t work because they aren’t using an adaptive distributed honeypot network to get their information, and because their published reputation information isn’t tied to economic incentives for the affected ISPs and software vendors, such as higher insurance rates.

-jsq

Silver Bullet Security Considered Harmful

Silver_Bullet.jpg In the comment discussion about Linus’s schedulers vs. security polemic, Iang mentioned a paper he’s writing:
We hypothesize that security is a good with insufficient information, and reject the assumption that security fits in the market for goods with asymmetric information. Security can be viewed as in a market where neither buyer nor seller has sufficient information to be able to make a rational buying decision. These characteristics lead to the arisal of a market in silver bullets as participants herd in search of best practices, a common set of goods that arises more to reduce the costs of externalities rather than achieve benefits in security itself.

— The Market for Silver Bullets, by Ian Grigg, Systemics, Inc. $Revision: 1.27 $ $Date: 2005/11/05 18:25:54 $

Evidently security needs to find another precious metal for its bullets, given that the Storm Botnet is still out there after months, phishing becomes more expensive all the time, spam has killed electronic mail for a whole generation of users, and the best the monoculture OS vendor can come up with is a new release that attempts to push responsibility for all its bugs and design flaws back on the user.

What to do? Continue reading →

What It Will Take to Win

gp.jpg 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

Metricon: Puzzle vs. Mystery

rct_pointing2.jpg 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