The Twelve XP Practices Applied to Cyber Network Security and Fighting Cyber Crime

Transcription

1 The Twelve XP Practices Applied to Cyber Network Security and Fighting Cyber Crime Martin Dudziak Fellow, Center for Advances Defense Studies Washington, DC July 17, 2009 The XP ( extreme Programming ) model was first developed and matured in the software engineering community by Kent Beck and Ron Jeffries, both pioneers, respectively in software engineering and object-oriented programming, and in computer science, artificial intelligence, and man-machine interfaces. As a discipline within software system and code design, programming and maintenance, XP is well-known and popular. Outside of the traditional IT field, XP is comparatively unknown, and rarely considered for its utility as a model for technical teamwork, organizational management and communications, and problem-solving in other disciplines. This methodology has a great deal to offer those who are working on the challenges of cyber network security, crime and attacks. The remarks here are not about the applicability and utility of XP for teams that are explicitly working on software development, conversion, maintenance, and other tasks that lend themselves to small groups of programmers and software engineers working closely on technical blocks of work. Rather, the point being made here is that XP can be very useful for building and conducting a combined defensive + offensive strategy in protecting cyber network infrastructures. Such a strategy is one that aims to uncover motives and intentions among attackers and the planners of cyber warfare and aggression, to defeat them proactively, ahead of their game plan, to fend off attacks that are successfully launched, and finally to remove the attractors, incentives, and payoffs that come to the attackers from their results. This is a strategy that must be constantly changing, adapting, evolving, and with a great deal of flexibility and thinking outside the box, not only with respect to algorithms, software code, systems integration, and public communication including alerts and quarantines. A successful approach to our modern-day cyber wars is one that can be based upon what XP offers in conventional software engineering. This is a shift from the paradigm that has been employed, generally speaking, up until the present. It is a shift that even highly successful cyber crime organizations and their leaders will be hard-pressed to counter by virtue of the ways in which cyber crime organizers are inherently forced to coordinate and manage themselves, as criminal and/or terrorist organizations, in other cases as solo operators, and in any case, with many constraints as far as openness of communication and ability to organize in an open corporate type of working environment. XP thrives upon and breed openness, communication, sharing, and innovation that is spread among closely-coupled and openly communicating teams. This is not the way most criminals think or can think. Herein lies one of the keys for defeating their methods and their model. While some of the twelve principles re-examined here may seem to be a stretch of the imagination with respect to cyber defense that is distinct from the purely software aspects of such defense, the fact is that there are some fundamental work practices and disciplines that simply work very well in any kind of environment. Furthermore, there is no question about the link between quick changes in software that may be part of an IT department s upgrade project and the quick-thinking and changing that comes as part of a response to a cyber attack in progress Jul-09 10:16 PM

2 The Planning Process, sometimes called the Planning Game. The aim of the XP planning process is to define the outcomes value of desired features that may be known or expected to be in a particular kind of attack, or else originating from a type of aggressor (state, non-state, organization, cell, individual). Cost estimates are developed for the alternative outcomes of different types of attack. Choices are made regarding what type of features including anomalies need to be sought, tracked, examined and some of this work is not unlike a costs benefit analysis trade-offs are examined because there is no possibility to cover all angles and parallel tracks simultaneously. Small Releases. XP strike force teams put a simple response system into production early, and update it frequently on a very short cycle, following on the heels of the first alerts and heads-up notifications of changed cyber attack modus operandi and technical features. These are not necessarily releases of code but of action-items as well the what to do next which are often procedural and as much involving the business/social process as anything on the computer itself. Metaphor. In software XP, teams use a common "system of names" and a common system description, the purpose and benefit of which guides development and communication. The same common language approach expedites cooperation and collaboration among different and seemingly unrelated groups working often around the world and around the clock to tackle a cyber attack. Less time and energy are spent among cyber warriors to decipher what the other team is saying and trying to do. Simple Design. A cyber defense or countermeasure built with XP should be the simplest that meets the current requirements. The aim is to freeze the advance of the attack and to undo damages already done. There is not much building for the future" even though ultimately somebody needs to be addressing those more long-term needs. Instead, the focus is on providing something that will stop the damage and reinforce the network. As in software-dev XP, techniques such as "refactoring" can be used to eliminate duplication and redundancy. Testing. In software XP, teams are constantly in QA/QC mode, aiming to validate at all times, whenever change is introduced. This is even more essential as an instinctive practice in developing and trying out new responses, software or otherwise, to the forensic, countermeasure, enforcement and recovery processes in cyber security, because the nature of the aggression and intervention is generally full of unknowns, at least during the initial defensive stage. One does not know exactly what one is up against, and every unknown detail could be something that reacts and even takes advantage of minor changes in the defender s tactics, software included. Good programmers develop good software by first writing tests to cover all the use cases, then when they are sure they have addressed all of the possibilities, they go about creating the software that fulfills the requirements which have been reflected in those comprehensive tests. Writing software first and then thinking about the tests is a backwards approach almost certainly doomed to at least temporary failures and a lot of rewriting. In combating cyber attacks, the same holds true. The different possible outcomes need to be identified, lined up, and measures made for what would be a satisfactory act of remediation or correction to the identified problem. Then it becomes possible to step back and design what will satisfy the different needs that have so been identified Jul-09 10:16 PM

3 Refactoring. The concept of refactoring refers to making non-functional changes to a process such as software code in a manner that improves internal consistence, clarity, and understandability but without changing the actions, the algorithms. Sometimes this is referred to as cleaning things up. Examples can include the removal of duplication, and an increase in communication including documentation. Within the cyber defense lifecycle, there is a benefit for any type of refactoring that can be mustered and maintained. Tomorrow s warriors need to understand what was tried, what worked, what did not work, and also how changes of yesterday have led to and perhaps has a causal role in forming modifications ( mutations ) in bots and other malware. The very nature of fighting the unknown, malleable and constantly mutating opponent is such that things can become very complicated and top-heavy very quickly, as far as one s own defensive tools are concerned. Subtleties can be missed, and in combating a cyber attacker, one of the most important arsenals is the ability to noticed anomalies that amount to being something like a mutation, almost imperceptible, in the behavior of some malware. If code and process complexity is not addressed and the complexities and difficulties of using the tools, no matter how good they are, begin to bog down the defenders, then there must be some refactoring taking place to offset those complexities and get back to the basics as far as concern ways to use computers and networks to overcome assailants. Pair Programming. In XP software development practice, programmers work in pairs, two programmers working together at one machine, writing all production code as a team unit. The concept of pair programming is based upon the notion, borne out by many experiments, that better quality software (more efficient, fewer errors, fewer rewrites and fixes, etc.) results with similar or lower cost in the end - than when programmers have been working alone. How does this translate to the tasks in cyber warfare? Certainly there is a very basic psychological fact that two heads can be better than one, especially when operating under the kind of elevated stress of firefighting and emergency response, as is the case when any attack is underway this is not a situation of simply building a new system. There is another value to the pairing concept, and it does not necessarily have to do with two people physically working together. This is more about two groups or teams working in parallel, deliberately taking different approaches, different angles. Why? To examine the alternatives that may be in the mind of the attacker, the perpetrator. To look for ideas that are really outside the box. Recall that the issue in a cyber attack is not only about the actual events going on inside computers and across networks, but the operations and people that have generated the attack, what they are trying to accomplish, what is their gain, and how can this gain be reduced, taken away, reducing the incentive for continuing further attacks. Collective Ownership. In software XP, there is the expression that All the code belongs to all the programmers. The idea behind this is to enable everyone working on the project to go full speed ahead, because, having access to everything in the software repertoire, then changes can be made without delay. In cyber defense, the idea is a little different. It should be more like, All the tools and resources can be virtually open source so that everyone on the team can grab the tool they need, when they need it, in order to try out an idea without delay. It s a matter of coordination, not classification and restriction. The more everyone has access to what others are thinking about and trying, the more likely it is that someone will do a faster job of connecting some dots or trying some kind of conceptual interpolation that results in an answer that works better against the threat Jul-09 10:16 PM

4 Continuous Integration. In software XP, there is constant integration and build-rebuild iteration. It s the nature of the work process, not the exception. The result is that programmers are more aware of what everyone else is doing. It s about being on the same page. Generally, XP advocates find that integration problems are fewer than among teams who integrate less often. The more there is exchange and communication, the more people can notice what needs to be modified before they get so far along that it becomes a headache and a requirement for roll-back to some point that may be long forgotten. In cyber warfare, this is also a powerful benefit. Ultimately, the solutions being considered are going to involve business processes, and software, and human interfaces, that have to talk to one another. The parts cannot be built in isolation. 40-hour Week. This is a simple fact of life for any field of work, especially one where there is a constant high-demand for sharp attention and acute, critical thinking. People need breaks, fresh air, healthy food, and exercise away from the work pit. On-site Customer. An XP project is best led, mentored and championed dedicated individual who is the customer and who is also empowered in that role for determining and/or validating requirements, setting and changing priorities, providing clarifications, answering questions, and resolving ambiguities. This translates in the cyber defense world to having a clear channel to decision makers in those organizations that are most effected by an attack and who may very well be the primary targets by the attacker for whatever is the latter s goal. Coding Standard. The importance of having common models, terminologies, and rules of engagement apply across disciplinary borders and certainly for teams that need to be in a lot of person-to-person and group-to-group communications. Standards are not only for business as usual but are especially important for special strike-force operations as are all facets of an effective cyber network defense strategy. References Ken Auer and Roy Miller (2001), Extreme Programming Applied: Playing To Win, Addison-Wesley. Kent Beck(1999), Extreme Programming Explained: Embrace Change, Addison-Wesley. Kent Beck and Martin Fowler (2000), Planning Extreme Programming, Addison-Wesley. Kent Beck and Cynthia Andres (2004), Extreme Programming Explained: Embrace Change, Second Edition, Addison-Wesley. Alistair Cockburn (2001), Agile Software Development, Addison-Wesley. Mike Cohn (2005), Agile Esstimating and Planning, Prentice-Hall 4 17-Jul-09 10:16 PM

5 Martin Fowler (1999), Refactoring: Improving the Design of Existing Code, Addison-Wesley. Harvey Herela (2005). Case Study: The Chrysler Comprehensive Compensation System. Galen Lab, U.C. Irvine. Jim Highsmith (2001). Agile Software Development Ecosystems, Addison-Wesley. Ron Jeffries, Ann Anderson and Chet Hendrickson (2000), Extreme Programming Installed, Addison- Wesley. Robert Martin and James Newkirk (2001), Extreme Programming in Practice, Addison-Wesley. Giancarlo Suchi and Michele Marchesi (2001), Extreme Programmed Examined, Pearson. Special Note The Twelve Principles and some of the phrases used throughout this memo originate in a concise summary of XP as a software methodology. The absence of an author s name on that original document renders it impossible to give credit and acknowledgement here and now for a very concise and useful summary of the software dimension of XP Jul-09 10:16 PM