New Software Development Paradigms and Possible Adoption for Security

1.   Introduction ¹1 This paper reflects the personal opinions of the authors.

“Adding manpower to a late project makes it even later”, as the saying goes for projects The same holds true for security when the responsible team does not do its job properly. The situation gets even worse, because the real security level does not keep up with the security feeling. In this paper, we define security as follows:

Therefore security has a lot to do with risk analysis, prevention and impact reduction. The definition on eGovernment is the following:

This paper will illustrate several critical issues in eGovernment and address approaches to handle them. For the purposes of this paper it is not necessary to distinguish G2G (government-to-government) and G2C (government-to-citizen). Both front-office and back-office have software development ongoing. The specific security issues will vary, but can be addressed the same way. However, it focuses on the participating eGovernment part of the definition above. Many current projects - whether in eGovernment or eBusiness - have faced the following situation:

• The governmental body has already been using IT for a long time.
• There is an installed base of hosts around which the architecture was designed.
• The host security is rather high, but it was based on the assumption that the hosts would be isolated from public networks.
• Due to the fact that the governmental body has opened up client connections to the Internet, the internal network has grown enormously.
• The governmental body has a conservative technology strategy.
• The governmental body has installed a fire wall.
• So far the governmental body has been trying to cope with the regulations set out by the responsible administrative branches (dealing with security and other) of the government, while trying to reposition itself in new public management and to increase competitiveness. The security regulations are mainly regarded as being too tight, having nothing to do with reality, but instead they reduce the effectiveness for service provision.
• A consultant is hired to analyse the situation, and he presents a paper about the necessity to create a task force in order to draft a policy or a set of policies.
• A lot of stakeholders are ignored in the process, because there is no time or the stakeholders are thought of as being incapable of providing useful input. It is important to note that in public administrations a lot more people are involved in most activities. Therefore the range of stakeholders is wider than in the private sector.
• The result: little has been done, and because of this many people have become angry, and the widest security gaps remain open (usually internal organisation problems are of this category that is underestimated the most).

Often security is an issue that is unwillingly discussed (meaning with a too low priority), handled the wrong way or the solution possibilities are not followed to the end. A few more concepts must be briefly discussed in this paper. We will refer to security functions in different sections in this article.

Another important concept is that of stakeholders:

The next important one is the definition of a system:

An application is an information system (IS). This means that several applications may share the same information technology system (IT).

For low to medium level security there are directly implementable solutions. In Switzerland there is the directive S.02 ^[6] and in Germany the Grundschutzhandbuch ^[7].

For more advanced and complete solutions the following two standards should be considered:

• The Common Criteria for Information Technology Security Evaluation
• And ISO 17799 Information technology — Code of practice for information security management.

These two standards are made for specialists and should only be applied under the right circumstances. They can be adapted to fit the method suggested in the following sections as starting point, guidance and check list.

2.   What is special in eGovernment security? ^[8]

EGovernment is special because of the following facts:

• It is governed by different laws as compared to eBusiness.
• The big data pools of the administrations are an attractive goal for an attack and need the appropriate protection.
• The huge and distributed networks of the public administration offer a big attack region.
• Federalism and autonomy of different branches result in a heterogeneous and complex environment.
• It will be difficult enough to offer competitive (instead of merely paper) solutions without enforcing rigid security for citizens.
• The transactions and the processes of the administration are more closely monitored and must adhere to more regulations.

It should be made clear that one of the goals of eGovernment must be to diminish the differences between eGovernment and eBusiness so that the total cost of ownership of eGovernment solutions decreases.

The security issues can affect citizens (because it is often data about them) and on the other hand the agencies. The inability to pay or to do business has not the same importance as in normal business. However, the long-term storage of data can be affected. On a higher scale of escalation the possibility to react appropriately to external dangers (terrorism, war) must be maintained by the relevant parts of the government.

3.   Can security be built in from the start?

Security can certainly be “built” into the minds of an organisation. The difficulties to change an inadequate culture ^[9] in a company are, however, very high and need a long time to be sorted out ^[10]. It is easier to work on technology, but it is impossible to overcome a glass ceiling level of security when the organisational aspects are not taken into account ^[11]. In some cases the problem of having to add the security issue last in a particular organisation (together with quality and performance) cannot be avoided as many applications are bought from the shelf and are not of the required standards to cope with the risks present in the environment of public administration. In a high security governmental environment this is even true for commercial operating systems ^[12],[13]. Unfortunately the security architecture of most applications is neither modular nor does it offer a public, stable interface. Attempts in this direction are made, but still not satisfactory ^[14],[15]. This may be one of the side-effects of the export restrictions of cryptographic software ^[16].

4.   Integration of predefined security into an overall scheme

Most of the current systems have a security policy of their own. In a low to medium security environment it is best to integrate the use of these building blocks. When high level security is needed, there will certainly be problems:

• The security framework of the applications/systems was too narrowly defined.
• There are no usable interfaces to integrate the security architectures.

Both shortcomings are not really the result of bad design, but a design focused on something else besides the security of governmental bodies. A vendor can hardly be blamed for not having foreseen these problems.

5.   Security is an aspect of management

It has already been mentioned before that security is a 'people problem'. In each organisation the part dealing with people is the management. Therefore security is a management problem, more precisely, it is an aspect of management. It is a bad idea to separate aspects into different categories, security officers and quality officers have a low impact because the power is still and will still be exercised by the default hierarchy. It is absolutely necessary that each manager is instructed about the importance of security and has incorporated the security aspect into his management style. Also, here the gap between middle management and top management is important to keep in mind. Usually the middle management is most opposed to new security strategies as it must implement it and security is often (or is often seen) in conflict with the productivity goals. The most important security issues for the management to handle are:

• Alignment with other goals
• Homogeneity of usage
• Long lasting measures
• Feedback circles

These are primarily soft factors, but in the end soft factors have a much greater impact.

6.   Process-oriented view

One or more anchors are needed to build security into an organisation so that security becomes a core value of these organisations. One organisational view which has become very popular is a process or a workflow-based view. When the organisation is constructed by “organisation follows process follows strategy”, a process view on security comes in natural. The basic definition is:

On the other hand: A workflow is characterised by the following attributes ^[18]:

• Several persons are involved in the execution of a work flow.
• A work flow consists of several tasks.
• The tasks of a work flow have a predefined structure to process matters related to an organisation.
• The handling of errors is predefined.
• There is an instance that coordinates the different tasks.
• During the execution of a work flow data is transferred and managed.

Business processes can be seen as special cases of a workflow. Another view is to follow the life cycle of the applications as shown in figure 1^[19]. An example for an architecture centred security solution is shown in figure 2^[20]. Balancing security and usability is one of the crucial points ^[21]. Especially when the security is added late in the life cycle of products ^[22], it will almost certainly affect productivity. Generally it is assumed that a graph as represented in figure 3(a) is able to describe the connection. What is not realised is that at a certain level of annoyance the users will start to circumvent the security.

Therefore the graph should be more like the presentation in figure 3(b).

Hard facts on this correlation cannot be found ^[23]. On the other hand a lot can be done without affecting the users or even doing the opposite, e.g. single-sign on, intrusion detection systems, re-organising the network, a better password policy, physical access restrictions to servers, a good network topology.

7.   The top-down and strategy first approach

This is the method most literature proposes. However, this approach has the same drawbacks as the old waterfall model ^[24]. A lot of paper is produced which makes a good impression on the top management. Usually several months (to years) are lost, while the biggest gaps remain still open. The produced paper is in most cases neither people-focused nor technology-focused. Usually from the point of view of strategy, a fast jump to conventional good practice is made. This also happens often in eGovemment in project management as shown by Teresa A. Pardo and Jochen H. Scholl ^[25]. Security policy documents incorporating this shortcut can be recognised by the fact that the level of abstraction is incoherent, i.e. that the length of passwords is mentioned on the same page as the need for security training for the staff. A first jump does not need to be bad with regard to security, but it affects the confidence in the process to some extent and for others creates a negative feeling to have followed a systematic approach (which they in fact have not).

Figure 1:Figure 1:

Figure 2:Figure 2:

Figure 3:Figure 3:

8.   Integration into a bigger framework

Inter-organisational trust always causes problems, as the non-existence of a world wide certification authority framework shows. Many organisations seem to believe in the value of medieval castles, because in that very same way, they organise their defence for the information infrastructure. More advanced companies already use the fortress engineering of the $18^{{\rm th}}$ century by building whole fortifications. State of the art systems should not trust their peers (trust is good, control is better). While some trust in the form of loyalty can be assumed within an organisation that has at least a physical location, a culture and one management; nevertheless a small amount of paranoia between organisations can be healthy. All data traversing the borders should be controlled again and the outside world should be mistrusted. In general this creates an extra amount of work, but it helps at the same time to reduce trouble with other problems like corrupt data and manipulation errors. It is strongly advised that in the case of an economically unbalanced situation the stronger partner does not force the smaller ones to conform, because in many cases the attack will come through the network of the bigger one (with more staff being responsible for 80% of the attacks) and the enforced security will not be incorporated. Security must be a group effort as was mentioned above. It needs only one grumpy stakeholder (person or organisation) to be weakened completely.

9.   Extreme programming core practices and security

In this section we will discuss the connections with one well known exponent of the new paradigms: extreme programming is one of the various iterative methods for the development of software ^[26].

The advantages of modern forms of software development have been shown in business. They are still quite uncommon in the governmental area. The paper wants to show, that - in the area of problems suitable for XP - XP can be used to create adequate software with adequate security levels. The XP process and metaphors can even be used/adapted for fast implementation of security (either technical or organisational) in an already installed environment. The rationale behind such a process is to incorporate security in the core development process and to get the benefits that XP and other adaptive/iterative strategies brought to software development also for the security area.

Extreme programming uses four variables: time, cost, quality, functionality. For Extreme programming time is a constant. Security consists mainly of quality and functionality. Therefore it is a reasonable assumption to examine XP principles for security projects. In table 1 we will discuss what happens if XP core practices are applied to security. Core practices are behaviour patterns that must be implemented to get XP going.

Table 1 uses the following notations: CO (comment), SE (security effects of applied XP), IM (used an XP analogue for security implementation), EGOV (special eGovernment issue).

10.   Drawbacks

Barry Boehm ^[32] made a comparison between traditional project management and extreme programming, showing when to use which methodology. In general the conclusions of the article can be applied to security as well. However, usually the team responsible for creating the security is rather small and therefore more on the XP side. Another drawback is that XP does not focus on the interaction of the customer with his/her coworkers in detail. In most cases therefore, “less extreme programming” will be the path to follow.

Figure 4:Figure 4:

11.   Conclusions

There are lessons to be learnt from iterative development that can be used in security development. Security engineers like to base their work on mathematical foundations. It should be mentioned that not even the best cryptographic algorithms used today are proven mathematically safe (In quantum computation this will become true ^[33]). The IT systems used in public administrations are complex ^[34] and for this reason a complete analysis in advance without implementation and evolution is not possible. The adherence to standards is a good idea, but it should be used not as first aid, but as a long term project. The process as shown in figure 4 is adopted more frequently in order to obtain early results.

The main goals of this process must be:

• Build security into the core and hearts in the end
• Improve the software development cycle
• Change procurement to include security
• Change project management priorities to include security (and quality)

Security becomes more and more important, a fast reliable path to security is worth adding some new principles.