Handbook for ICT professionals - Fundamental skills for

Handbook for ICT Professionals

Fundamental skills for

government

-

Handbook for ICT Professionals in the Ministries and other State Administrative Bodies in the Republic of Macedonia

fundamental skills for

e-government

ICT Handbook for ICT Professionals in the Ministries and other State Administrative Bodies in the Republic of Macedonia


ContentsIntroduction 5

1 ICT Strategy and Planning 6

1.1 Standardisation.....................................................................................61.2 Linking ICT Strategy with the overall Strategy of the organisation....71.3 Action plan...........................................................................................81.4 Relationship between strategy, action plan and budget.......................9

2 ICT budgeting 10

2.1 Budgeting principles..........................................................................102.2 The items that should be on the budget..............................................10

2.2.1 Administrative costs...................................................................102.2.2 Investments.................................................................................112.2.3 Hardware....................................................................................112.2.4 Communication equipment........................................................112.2.5 Software licences........................................................................112.2.6 ICT services................................................................................122.2.7 Data communication costs.........................................................122.2.8 Projects.......................................................................................12

2.3 Budget and procurement....................................................................132.4 Budget and contract obligations.........................................................13

3 ICT Service Management 14

3.1 Organization of the ICT Unit.............................................................143.1.1 User support...............................................................................153.1.2 Infrastructure maintenance.........................................................163.1.3 Daily controlling activities of the infrastructure........................183.1.4 Planning and development.........................................................19

3.2 The ITIL processes.............................................................................193.2.1 The Service Support processes...................................................193.2.2 The Service Delivery processes.................................................22

3.3 How could you start to implement ITIL?...........................................24

4 ICT Procurement 29

4.1 ICT procurement characteristics........................................................294.2 Procurement planning........................................................................30

4.2.1 Organisation of Public Procurement..........................................304.2.2 Link to the Strategic planning....................................................31

4.3 Plan the Procurement as a Project......................................................314.3.1 Assess the Market.......................................................................314.3.2 Develop a Procurement Strategy................................................324.3.3 Assess the risks in the procurement process..............................32


4.3.3.1 Identification of risks.............................................................33

4.3.3.2 Assessment of risks................................................................33

4.3.3.3 Treating and monitoring risks................................................34

4.4 Requirements Specification................................................................344.4.1 Evaluation Criteria.....................................................................35

4.5 Choose procurement procedure..........................................................354.6 Tender documentation........................................................................36

4.6.1 Evaluation sheet.........................................................................374.7 Invitation for submission of bids or applications...............................374.8 Public Opening...................................................................................384.9 Evaluation of bids...............................................................................38

4.9.1 Conflict of interest......................................................................394.10 Contract Negotiation..........................................................................39

4.10.1 Contract negotiation for software systems.................................404.11 Contract Management........................................................................40

4.11.1 Participation in the procurement project....................................41

5 Project Management 42

5.1 Characteristics of a project.................................................................425.2 The Project Organisation....................................................................43

5.2.1 The Project Board.......................................................................435.2.2 The Project Manager..................................................................445.2.3 Project group..............................................................................445.2.4 Project Advisory Committee......................................................445.2.5 Relationship between project and the line organisation.............44

5.3 The PRINCE2 Project Management Processes..................................455.3.1 Directing.....................................................................................455.3.2 Starting-up..................................................................................455.3.3 Initiating.....................................................................................455.3.4 Controlling Stages......................................................................455.3.5 Managing Product Delivery.......................................................455.3.6 Managing Stage Boundaries.......................................................455.3.7 Closing.......................................................................................465.3.8 Planning......................................................................................46

5.4 Project Management...........................................................................465.4.1 Project implementation..............................................................485.4.2 Project Management...................................................................48

5.4.2.1 Progress..................................................................................49

5.4.2.2 Quality....................................................................................49

5.4.2.3 Financial management............................................................49

5.4.2.4 Procurement management......................................................49

5.5 Risk Management...............................................................................495.5.1 Risk Assessment Document.......................................................515.5.2 Risk Management Plan...............................................................51


5.6 Finishing the project...........................................................................525.6.1 Transfer of results and knowledge to the line organisation.......525.6.2 Evaluation...................................................................................52

5.7 Documentation...................................................................................52

6 eGovernment54

6.1 What is eGovernment?.......................................................................546.2 EU and eGovernment.........................................................................546.3 Requirements and preconditions for eGovernment............................56

6.3.1 Legal aspects..............................................................................576.3.2 Electronic signature....................................................................57

6.3.2.1 Creating an electronic signature.............................................58

6.3.2.2 Validating an electronic signature..........................................58

6.3.3 Technical infrastructure..............................................................596.3.4 Reliable ICT systems.................................................................606.3.5 Acceptance of eGovernment solutions in the entire society......60

6.4 Examples of eGovernment solutions..................................................606.4.1 Macedonian eGovernment services...........................................61

7 Information Security 64

7.1 Definition of security.........................................................................647.2 Security guidelines.............................................................................65

7.2.1 Validate input.............................................................................657.2.2 Fail securely...............................................................................667.2.3 Keep it simple.............................................................................667.2.5 Defence in depth.........................................................................677.2.6 Secure the weakest link..............................................................677.2.7 Practice the principle of least privilege......................................677.2.8 Practice compartmentalization...................................................687.2.9 Awareness..................................................................................68

Appendix:

1. Performing Procurement (checklist)

2. Management of Risks (checklist)

3. Risk Assessment Document (template)

4. Procurement procedures

5. Project Management (checklist)

6. Information Security


IntroductionThe Republic of Macedonia aspires to implement eGovernment. eGovernment is the use of information and communication technology (ICT) to transform government by making it more accessible, effective and accountable. To achieve this, the state administration needs reliable ICT systems with sufficient capacity. The topics covered in this handbook are fundamental in the preparation for and implementation of eGovernment.

The handbook consists of seven chapters, and is intended for the ICT professionals in the ministries and other bodies in the state administration like e.g. the General Secretariat and the Legal Secretariat.

Chapter 1 describes how to develop ICT strategies and do planning. Linking ICT strategic planning with the overall strategy of the organisation is essential to ensure that ICT is used to support its main objectives

Chapter 2 covers ICT budgeting and the way ICT budgeting differs from other budgeting due to obligations that lie in software licences, maintenance agreements etc. and the fast depreciation of ICT equipment.

Chapter 3 provides guidance in service management and presents ITIL, which is a part of the ISO 20000 standard for ICT system management. Focussing on ICT system management is essential for delivering reliable ICT services.

Chapter 4 covers the mail issues related to undertaking ICT procurement. For more detailed information about the Macedonian public procurement process itself, we refer to the manual published by the Macedonian Public Procurement Bureau.

Chapter 5 describes project management in general, and goes further into one specific method, PRINCE2. Developing or purchasing new ICT systems or implementing changes to the infrastructure are examples of tasks that should be organised as projects.

Chapter 6 is a brief introduction to eGovernment, between others; what is going on in the EU, what are the important topics. Surveys shows that information security is vital for getting acceptance for eGovernment solutions

Chapter 7 covers information security.

In the end of each chapter, there are links to interesting sites on the Internet for further readings to find out more on the topics and issues covered in the handbook. The appendices cover checklists, a template, but also more in-depth information on some of the topics.

The handbook has been financed by Norwegian Ministry of Foreign Affairs though the NORMAK project. It has been developed by Statskonsult in close collaboration with Secretariat for European Affairs. We have also received feedback from ICT professionals working in the ministries and other state administrative bodies both through a preliminary hearing and through a workshop that took place on the 19th October 2006 in Skopje. We like to thank everyone that has been involved for his/her valuable contribution.

5


1 ICT Strategy and PlanningAn ICT strategy is a plan, which in general terms describes how an organisational body (e.g. a ministry) is going to use ICT to support their overall strategy and aims. The ICT strategy should cover the same period as the overall strategy.

1.1 Standardisation

There are many ICT strategic issues that have to be addressed in an organisation. One of the most important is standardisation of ICT equipment, software and data formats. Standardisation can cover one organisation or e.g. all Ministries, a certain sector like e.g. the transport sector etc.

It is important to consider the impact on the market if e.g. a government standardises on one specific kind of software from one specific supplier brand for all Ministries. This might lead to a monopoly situation, which in turn can lead to high prices, and an unbalanced market situation. To base on open source is a good alternative to avoid supplier dependency.

Standardisation makes ICT management easier and within a single organisation where unbalancing the market is not so much to worry about, although also smaller organisations should carry in mind that they should avoid to get too dependent on one supplier. The organisation should as a minimum standardise operating systems and basic programs used across the organisation to reduce system management and maintenance costs. Standardisation is also important to enable collaboration and data exchange between different institutions. In this case standardisation on formats is most important. Open standards should be preferred, especially when communicating outside the state administration.

According to an EU definition, "open" should mean the standard fulfils the following requirements:

The costs for the use of the standard are low

The standard has been published

The standard is adopted on the basis of an open decision-making procedure

The intellectual property rights to the standard are vested in a not-for-profit organisation, which operates a completely free access policy

There are no constraints on the re-use of the standard.

Source: http://ec.europa.eu/idabc/servlets/Doc?id=1674

Standardisation should be a part of the ICT strategy process when the standards are established. Afterwards should be maintained by other mechanisms, e.g. a special board that makes decisions on a regular basis. This should be described in the ICT strategy when the standardisation regime is established.

6

http://ec.europa.eu/idabc/servlets/Doc?id=1674


1.2 Linking ICT Strategy with the overall Strategy of the organisation

The ICT strategy could be either a part of the strategic plan of the organisation or, if this plan already exists, linked to it and supporting the goals of the strategic plan.

If the ICT strategy is a part of the strategic plan, the process of developing the ICT strategy should be incorporated in the overall process and follow the same guidelines.

The linking of the ICT strategy with an existing strategic plan should start with analysing how ICT can contribute to the achievement of the goals in the strategic plan. Introducing new ICT solutions, better equipment and/or improved ways of working might be beneficial or even in some circumstances a prerequisite to reach the goals in the strategic plan.

The output of the analysis should be a list containing those goals in the strategic plan to which there are related ICT strategic goals. These goals will form the backbone of the ministries’ ICT strategy, which the organisation will have to fulfil in order to be able to reach the goals strategic plan.

Figure 1 - Relation between strategic plan and ICT strategy

The next step is doing an analysis of the present situation in the ICT areas. Doing a functional analysis will cover the user side. In addition it will be necessary to do a survey of the technical status. What kind of equipment does the ministry have, is there any apparent need of replacing some of the equipment? Some of the ITIL system delivery processes, e.g. availability planning and capacity planning can be used as templates.

Figure 2 - The ingredients for making an ICT-strategy

Strategic Plan

- Goal 1

- Goal 2

- Goal 3

- …

Analysis of ICT

contribution

ICT Goals

- ICT goal 1

- ICT goal 2

- ICT goal 3

- …

Status report

Survey of present situation in the ICT area

Vision

Where do you want to be in 3 years?GAP

analysis

- action 1

- action 2

- action 3

7


When both the present situation is described and the vision of where the organisation wants to be in e.g. 3 years regarding ICT, the foundation is laid for making a gap analysis. A gap analysis is a business assessment tool to enable an organisation to compare its actual performance with its potential or wanted performance. This provides the organisation with insight to areas, which have room for improvement. The gap analysis points out what will be the necessary actions to get from the present situation to the position you want to achieve at the end of the strategy period.

Figure 3 - From the Gap analysis results to action plan

These actions should be roughly estimated in means of cost and need of human resources and then prioritized according to their business value. They then form the basis of the action plan

1.3 Action plan

An action plan is mainly a prioritized list of concrete actions that needs to be taken in order to achieve the goals in the strategy. The relation between each action and the goal(s) it supports should be described.

Each action needs to be planned, preferably as a project, before it is started. This includes detailed budgeting.

Figure 4 - Action plan

The action plan should be either annual, biannual or cover the whole period. The advantage of an action plan that covers more than one year is that it is easier to fit in longer projects or projects that are interrelated. If the plan is biannual it should be rolling.

Budget

……..

………

……..

- action 1

- action 2

- action 3

- …

Rough estimate of costs and resources

Action plan

- 1. Plan for action, supporting goal x

- 2. Plan for action, supporting goal x,y

- 3. Plan for action, supporting goal z

- …

Prioritize

according to

business value decide

Action plan

- 1. Plan for action, supporting goal x

- 2. Plan for action, supporting goal x,y

- 3. Plan for action, supporting goal z

- …

Project plan for action1




..costscosts

8


An annual action plan is in accordance with the budget period and the linking between the two is hereby easier.

1.4 Relationship between strategy, action plan and budget

The ICT strategy covers a period of three years, while the budget is annual. The action plan lies somewhere in the middle. It is a good idea to make this plan a rolling one or two-year plan. This means that you on regular basis adjust the plan to catch up with changes in priorities, framework or technology. To ensure that the action plan is reflected in the budget it has to be updated every year before the start of the budgeting process. Because the State budget is annual there is however no guarantee when a strategy is approved, that there will be enough money to finance it.

To implement as much as possible, the projects and activities in the action plan must be prioritized in the budgeting process. When the strategy period is over, the Strategy should be evaluated to see to what extend it has been implemented.

Useful/interesting links:

http://ec.europa.eu/idabc/en/document/2627/5894

http://europa.eu.int/idabc/en/document/3132/333

9

http://europa.eu.int/idabc/en/document/3132/333

http://ec.europa.eu/idabc/en/document/2627/5894


2 ICT budgeting ICT budgeting differs in certain ways from other budgeting. One reason is the obligations that lie in licenses, maintenance agreements, etc. Another is related to the relatively fast depreciation of ICT equipment.

2.1 Budgeting principles

The budget comprises investment budget and operational budget.

The operational budget is used for running expenses such as accessories, annual licences, telephone costs, stamps, paper, pencils, training and workshops, smaller equipment etc.

Items on the investment budget are larger, “one-time” expenses and as a rule depreciable asset. This means that they “loose value” over a period of time, due to wear and tear, or which is often the case with ICT equipment, it gets old-fashioned. In private sector depreciation is a part of the budget. It is, however not a part of the government budgeting system. In any case the depreciation has to be taken into account in some way or the other.

2.2 The items that should be on the budget

The get an overview of what should be on the budget, the items can be grouped under different posts.

2.2.1 Administrative costs

By administrative costs is meant costs related to running the business.

Expenses related to the staff Salary for existing personnel and new people that you plan to hire, training of the staff, travels, participation fees for conferences, magazines, books, membership fees, car allowance etc.

Expenses related to the office Office supplies like paper, pens, stamps, telephone expenses, printing expenses etc. Maybe you will also have to budget other office expenses, e.g. for premises, office equipment etc.

Expenses related to ICT Data requisites or accessories like cables, CD’s, back up media, toner, smaller equipment and tools, spare parts etc. Licences that have to be renewed every year can also be regarded as administrative costs

10


2.2.2 Investments

By investment is meant larger “one-time” expenses, like servers, local area network, PC’s etc. Projects can also be investments. Then all expenses connected to a project (e.g. consultant services, training, work-shops etc) are included in the project budget together with the expenses related to purchase of new equipment, software licences etc). Projects financed by others that have not included ICT costs, or maintenance costs, or calculated future needs for developing them further.

2.2.3 Hardware

Since the decrease in value of your investments is not covered by the budgeting system, you have to make a system for it on your own.

Servers, printers, PC’s firewalls etc usually have a depreciation period of 3 years, which coincides with the average guarantee period. To compensate for the reduction in value, you should make a provision in your budget for 1/3 of the value each year. In that way you have saved up money to replace that piece of equipment in 3 years.

If you choose to do this over a longer period, e.g. 5 years, the costs related to your savings will be distributed over a longer period and consequently lower each year. There is however a risk after the guarantee period has expired; if the equipment crashes the repair is not covered by the guarantee and will have to be paid by the organisation itself.

2.2.4 Communication equipment

If you invest in a completely new network with routers, switches etc. the depreciation time should be 5 years. It is not necessary to make provision for the more inexpensive components. They last for many years and could be replaced on the administrative budget. But you should make provisions for the more expensive parts.

Costs related to upgrade and extension of the network should also be budgeted here.

2.2.5 Software licences

Software licenses are usually purchased together with the equipment or with the software system. If you have standardised your software it is a good idea to have one licence contract for each product instead (e.g. Microsoft office licences, Oracle licences etc). Then you can optimise the number you need and also negotiate better prices.

If you follow strictly the upgrading advices from Microsoft, you will have a major upgrade every second year. Then you will have to make provisions for half of the costs for the licence on your budget the first year, and the other half on the second. If you e.g. drop every second licence and have your major upgrade every 4th year, you can wait one year and distribute the costs over 3 years and set off 1/3 of the value each year.

11


2.2.6 ICT services

The reason for purchasing ICT services is that you need additional competence or capacity, or both, to undertake your system management responsibilities properly. If you have systems developed specially for you by an external software company you will probably need to have a maintenance agreement to be sure that errors are dealt with as swiftly as possible and that you have someone who knows the system who can implement necessary changes to the system when you need it. You may also need to enter support contracts on other systems or equipment that you do not have enough knowledge about yourself.

Examples of service contracts are:

Support contracts on critical equipment and software systems

Support contracts on certain programs that you do not have sufficient knowledge about yourself (e.g. spam filters, virus filters, etc)

Internet provision

Maintenance of tailor made software systems (business applications)

Maintenance of standard software systems (usually licence upgrades)

e-mail services, Web services and other kinds of outsourcing contracts

Maintenance contracts and outsourcing contracts often contain a so-called Service level agreement (SLA). A service level agreement is not a contract by itself. There are many issues in an ordinary contract that is not covered by a SLA, e.g. ownership to equipment. The SLA regulates the level of service, how fast should the supplier respond if you report en error, what kind of response time has he committed himself to deliver, how often can the system crash? If the supplier does not deliver according to what has been agreed on, the supplier has to give you a reimbursement. How to calculate the reimbursement is a part of the SLA. Often is also included a product catalogue with additional services that you can order at the price that is listed.

2.2.7 Data communication costs

You have to budget all your communication expenses, weather they are related to Internet connection, renting of telephone lines etc or, which is often the case with governmental organisations, that you own your own lines, but need to do investments from time to time to make the lines more reliable, increase capacity etc.

2.2.8 Projects

Projects are often budgeted as investments. However when equipment is bought on a project, the maintenance cost is usually not covered once the project is over. If there are many ICT related projects in your organisation, this can be a real challenge. Donors supported projects often create special challenges. Donors usually prefer to support time-limited projects and are not very found of supporting running costs. Many of them have special preferences when it comes to equipment or software. Therefore, there is a danger that you end up with a mix of many different types of hardware and software and this is not very cost

12


effective to maintain. It is important that you are able to catch up information about ICT related projects going on in your organisation as early as possible. Then you can calculates the economic consequences of the projects for ICT maintenance and make evidence that shows that you will have to get an increase in your budget to be able to support it.

2.3 Budget and procurement

The investment budget is closely related to the annual procurement plan (see chapter 4) because investments usually imply procurement.

A substantial part of the running expenses also has to be acquired from external providers, and must therefore be included in this plan.

The budget and the procurement plan should therefore be developed in parallel.

2.4 Budget and contract obligations

All ICT equipment and all ICT services are regulated by contracts. These contracts imply budget obligations and it is important to remember to put them into the budget. There are mainly two types of contracts, for purchases and for services. A purchase is usually one event, but especially if the purchase includes development of software systems, there might be delays in the project that means that the project is extended to a new budget year. If it is not possible to transfer the money to the next year, you will actually “loose” the money and get problems fulfilling the obligations in the contract.

A service contract is a long-term contract, which covers delivery of specified services at regular basis over a certain period. A service contract usually covers many years and gives you multiple year’s obligations. Especially if the equipment or system is not a standard one, the service provider may have considerable initial costs in connection with establishing the services. This he will try to distribute over many years, if the contract is for two or three years or more. If it is not possible for you to accept this kind of long-term contracts, the services you need to purchase will probably be more expensive.

Maintenance contract and outsourcing contracts often contain Service level agreement (SLA). SLAs might also be included if you buy e-mail services or web services. If you have SLA the service provider has to give you reimbursement if he does not perform according to the standards described in the contract. This means that you get money back. It is however difficult to put in the budget expectations of reimbursement.

13


3 ICT Service ManagementThe responsibility of the ICT professionals in the state administration is to deliver and support well fitted, reliable and user friendly ICT solutions that increase the efficiency of the users.

To succeed in this, ICT units need to work towards being more service oriented and continuously updated on what are the main priorities of their users. A recognized tool world wide for improving ICT service management capabilities is ITIL (Information Technology Infrastructure Library ™). ITIL is the result of the work of the CCTA (Central Computer and Telecommunications Agency, now Office of Government Commerce, OGC), which in the early 1980’s was asked by British public sector organisations to develop an approach for efficient and cost-effective use of ICT resources. ITIL has recently become a part of the ISO 20000 standard for ICT System Management.

3.1 Organization of the ICT Unit

Figure 5 shows a simple organisational chart for a smaller ICT Department.

Figure 5 - Organisation of an ICT department

The two units User Support and Infrastructure maintenance are mainly occupied with day-to-day support to the users, called Service Support within the ITIL framework. These activities usually amount to 70-80% of the overall time and costs in the life cycle of an ICT product. The rest is spent on product development or procurement. These activities would typically be among the responsibilities of the third unit: Planning and development. Within ITIL this area is called Service Delivery.

The ICT department should have a written plan for handling user support and written plans for infrastructure and maintenance. The different tasks must be clearly defined and prioritised before handing them out to staff members. Many

User Support Infrastructure maintenance

Planning and development

Head of ICT Department

14


ICT departments choose to purchase planning and development skills from external suppliers when they need them. In that case they need to have skills in purchasing procedures and processes (see chapter 5).

3.1.1 User support

The aim of the user support is to improve the efficiency of the users. Deadlines in the state administration may be short and the result may be an object for political attention. Therefore user support can be very challenging. The challenges are likely to increase as more high-level managers and politicians get more focussed on ICT.

Well functioning user support gives you an excellent opportunity to establish good relations to the users.

User support can be implemented in straight forward or more sophisticated ways. It can be ad hoc or more bureaucratic. There are also many tools available to support user support. The staircase below illustrates three main “development stages” of user support.

Figure 6 - Organising user support

Ad hoc User Support ICT personnel are available on phone or e-mail, but have other tasks to perform as well (often no structured support mechanism in place).

Help Desk There are dedicated ICT personnel to take care of user support. They usually have a tool for registering user problems. This might be a standard help desk application, a system developed internally, a spread sheet i.e.

Service Desk All contact between the users and the ICT department goes through a single point of contact. The Service desk handles simple questions and incidents themselves and routes more difficult problems to specialists within the ICT organisation or to external service providers.

Internally in the ICT department it should be defined who handles 1st line support, 2nd line support and 3rd line support for all the systems the ICT department supports. On all the three steps in the staircase, 1 st line support is

Ad hoc User Support

Help Desk

Service Desk

Step 3

Step 2

Step 1

15


handled by the person who receives the call/e-mail from the user. If the 1st line support needs technical assistance, the procedure differs on the different steps of the staircase. On step 2, (help desk), and 3 (service desk), the 1st line support has a system to help him keeping track with what happens to the problem and when it is solved. This is usually a challenge with the ad hoc user support on step 1.

A critical success factor for getting satisfied user is that they know where to turn to when they need help. Remember always to communicate with users in a common language, non-technical form. This will help you understand each other. Further it might be a good idea to make a service catalogue describing what kind of services the user can expect to get from the ICT department. The service catalogue can be integrated with a service level agreements describing which level of service the user can expect to get, e.g. how fast the ICT department will change a password, register a new user or solve a problem in an application.

3.1.2 Infrastructure maintenance

The ICT department is responsible for the ICT infrastructure to be available and reliable. Therefore it is necessary to have plans for maintenance. On a general level, system and network management is about how to organise the work related to keeping the data systems up and running.

Figure 7 shows some typical basic elements that should be managed in the infrastructure. The different elements are described more in detail in the bullet list below.

Figure 7 - Basic management elements

Resources to be managed

Systems ServicesNetwork ContentApplications ProcessesDatabases Staff

Asset and configuration management

Topology and relationship mapping Availability

Management.

Recoverabilityand continuity

Asset and configuration management

Security and risk management

Capacity management

Management Basics

16


Topology and relationship mapping is a drawing of the network that shows both physical and virtual components in the network and how they are interrelated. The drawing could be made on paper, using a drawing tool or features in network supervising systems. It is important to update the drawing when changing components.

Availability management means supervising the performance of the infrastructure and systems to see if it fulfils the needs of the users. Does some parts of the infrastructure or some systems fail often? If yes, this should be handled in the ICT strategy process because then you will probably have to purchase some new parts or do other changes to your infrastructure or systems.

Change management is planning how to handle changes quickly and with the lowest possible impact on service quality. Change is an important ITIL-process. See chapter 4.2.1.

Capacity management is about providing the required ICT resources at the right time. Do you have problems with response time, disks that are full etc? Then you also probably will need to do some upgrading of the infrastructure. This implies purchasing, and purchasing has to be planned well in advance in order to get into the annual procurement plan.

Security and risk management is about analyzing threats and making plans on how to handle them.

Recoverability and continuity is about making routines describing how to handle system failures and disasters, and how to get the system up and running again as soon as possible.

Asset and configuration management is about keeping an updated list of equipment and how the equipment is configured.

17


3.1.3 Daily controlling activities of the infrastructure

There should be a written plan for the daily activities. The following table contains examples of activities that could be included in such a plan:

Control the refrigerating unit Always keep an eye on the temperature in the server room

Monitor network Monitor your dynamic network environment and quickly pinpoint the source of availability and performance problems

Monitor the network and networks equipment (firewall, switch, switch panel i.e.)

Monitoring servers Make a list of what is running on your servers and how often it should be controlleda. Applicationsb. Databasesc. Disks d. ….

Backup and restore Describe the backup routine (define what kind of backup, where to store the backup in-house and/or in another building)

Describe the restore routine (define what kind of restores that are possible from the different software, one file or do you have to restore a whole catalogue)

Make procedures for testing your backup before the emergency occurs and you actually need it

Antivirus program Describe routines for updating the antivirus program both on servers and computers

Set up automated updating on both servers and computers

Go through the log regularlySpam filter Monitor and optimize your spam filter

Go through the log every morning and forward mails that have been stopped without reason.

Plan and implement changes Describe plan/routines for implement changes Make a roll out plan for the change and a rollback plan if

the change goes wrong Do an impact analysis of the changes Document your changes. Afterwards you should be able

to answer the question what have been changed Make a plan for how to test if everything is OK after you

have implemented the change in the live environmentUninterruptible Power Supply (UPS)

You should have a UPS that covers the most critical ICT equipment

When you install new equipment, make sure that the UPS has enough power to perform a controlled shutdown for all the equipment

Table 1 - Activities for the ICT department

18


3.1.4 Planning and development

The activities in this unit are related to planning for the future development of the ICT department, and not to the day-to-day operations of the ICT department. Within the ITIL framework these processes are called Service Delivery.

Smaller ICT departments will not necessarily have this kind of unit. In that case the ICT manager will undertake many of the tasks, especially those related to planning.

The development of new systems might be done internally or purchased from an external provider. In latter case this unit will take care of the ICT related part of the procurement process. It will also give input to the annual procurement plan for the organisation as a whole (see chapter 5). If system development is done internally it is important to ensure participation form the future users of the system in the development phase. The system development should be organised as a project (see chapter 6).

3.2 The ITIL processes

As mentioned above, the ITIL processes are divided into two groups: Service Support and Service Delivery. The Service Support processes support the day-to-day activities in the organisation, while the Service Delivery processes are more focussed on planning.

3.2.1 The Service Support processes

The Service Desk function and the Service Support processes are focussed on supporting the day-to day operation of the organisation.

The Service Desk is the initial point of contact between the ICT department and the users. Its major tasks are recording, resolving and monitoring problems. In addition it receives so called Service Requests if the user needs to get new equipment or software installed, to change password, borrow a video projector etc.

Incident Management

An Incident is any event which is not part of the standard operation of a service and which causes, or may cause, an interruption to, or a reduction in the quality of that service. ITIL distinguishes between incidents and problems. All incidents are not problems. The objective of Incident Management is to restore normal service operation as quickly as possible with minimum disruption to the organisation. When this is done, the incident can be analysed and the cause can be identified and remedied. This is done by another process; Problem management (see below).

It is important to keep effective record of incidents and use this as basis for measuring and improving the system management processes.

19


Problem Management

A Problem is the unknown underlying cause of one or more Incidents. It will become a Known Error when the root cause is known and a temporary workaround or a permanent solution has been identified.

The objective of Problem Management is to resolve the underlying root cause of incidents and prevent them from reoccurring. Recorded incidents are analysed to find workarounds or permanent solutions. Then the business decision is taken whether or not to make a permanent fix to prevent new incidents form happening. To initiate the process for making the fix, the is through a Request For Change (RFC) which is a formal part of the Change Management process (see figure 8).

Proactive Problem Management aims at preventing incidents from reoccurring by identifying weaknesses in the infrastructure and make proposals to eliminate them.

Change management

The objective of the process is to assess changes and make sure they can be implemented with a minimum adverse impact on the ICT services. It is important to ensure traceability of changes through effective consultation and coordination throughout the whole organisation. The Change Management process involves many other ITIL processes (see figure 8). All changes have to be recorded in the Configuration Management Database (CMDB).

Configuration Management

Configuration Management keeps an overview of all significant components within the infrastructure. Information about these components (called Configuration Items, CIs) are stored in the Configuration Management Database CMDB). The process is responsible for standardization and status monitoring, collecting recording and managing details about the components and providing information about them to all other processes.

The Configuration Management Database keeps record of all Configuration Items in use, their versions and status and the relationships between them. The Definitive Software Library contains the master version (original) of all software in use in the organisation.

Configuration Management is responsible for checking whether changes in the ICT infrastructure have been recorded correctly. This includes keeping track of the relationship between Configuration Items, and monitoring the status of the ICT components to ensure that the versions of Configuration Items in use are correct. If Configuration Management is implemented effectively it can provide information about the following:

20


Product policy like:

Which ICT components are we currently using, how many of each model (version), and how long have we had them?

Which ICT components can be phased out and which require upgrading?

Which maintenance contract should be reviewed?

Troubleshooting information and impact assessment like:

Which ICT components will we need for a disaster recovery procedure?

Which network is equipment connected to?

Which ICT components are affected by a change?

Figure 8 – Roles in Change Management

The figure describes the different roles that are involved in a Change Management process. The process starts with an RFC, Request For Change, which is a form that has to be filled in with details of a request to change any Configuration Item within the infrastructure. Release management is described below.

ChangeManagement

(Plan)

ConfigurationManagement

(Register)

IncidentManagement

(Check)

ReleaseManagement

(Do)

ProblemManagement

(Act)

Correctivemeasures

RFC’s

RFC’s

Analyze/Evaluate

Build/Buy

Install

InnovationImprovementChange

21


Release Management

A release is a set of Configuration Items that are tested and introduced into the live environment together. The main objective of Release Management is to ensure the successful rollout of releases. Release Management ensures that only tested and correct versions of authorized software and hardware are provided.

Figure 9 - Release Management activities

3.2.2 The Service Delivery processes

ICT Service Delivery focuses on long term planning and improvement of the ICT service provision in the organisation.

Service Level Management

Service Level Management ensures that the ICT services in the organisation required by the users are continuously maintained and improved. This is achieved by agreeing, monitoring and reporting on the performance of the ICT organisation and creating an effective business relationship between the ICT organisation and its users. Effective Service Level Management improves the performance of the users business and results in greater user satisfaction.

Service Level Management includes designing, agreeing, and maintaining the following:

SLA – Service Level Agreement. The SLA describes the services provided by the ICT department in non-technical terms. It guarantees a certain service level and contains ways of measuring the service level.

OLA – Operation Level Agreement. The OLA is an agreement with a department inside the organisation, which provides certain parts of a service.

Controlled Test Environment LiveEnvironment

DevelopmentEnvironment

RELEASE MANAGEMENT

ReleasePolicy

DistributionAnd

installation

Communicationpreparing

and training

ReleasePlanning

Develop orpurchasesoftware

Build /configurerelease

Fit-for-purposetesting

Releaseacceptance

Roll-outplanning

Configuration Management Database (CMDB)And

Definitive Software Library (DSL)

22


UC – Underpinning Contracts. An Underpinning Contract is a contract with an external service provider defining the provision of certain elements of a service, e.g. Internet connection

Collecting the services offered by the ICT department in a Service Catalogue can be a good means of communication with the users. The following tips can be helpful when writing a Service Catalogue:

Use your user’s language. Avoid technical jargon, and use terminology corresponding to relevant business.

Try to look at things from the users point of view and use that approach to identify relevant information.

Ensure that the document is available to the largest number of potential stakeholders, for example by publishing it on an Intranets site or on CD-ROM.

The service catalogue can be used as means for the user to order certain services from the ICT department. If transfer billing is in use within the organisation, the service catalogue will contain prices for the services.

Financial Management for ICT Services

The objective of Financial Management is to provide cost-effective management of the ICT resources required for providing ICT services to the organisation. The process aims at breaking down the ICT service costs and relating them to the various ICT services provided. In this way, it supports management decisions related to ICT investment and encourages cost aware use of ICT facilities.

Capacity Management

Capacity Management aims to consistently provide the required ICT resources at the right time (when they are needed), and at the right cost, aligned with the current and future requirements of the organisations. Thus, Capacity Management needs to understand both the expected organisations developments affecting users, as well as anticipating technical developments.

Availability Management

The objective of Availability Management is to provide the right level of ICT services and in this way enable the organisation to reach its objectives. This means that the demands of the users have to be aligned with the level of sevices that ICT organisation is able to offer. If there is a gap between supply and demand then Availability Management will have to try and provide a solution.

23


Furthermore, Availability Management is responsible for measuring the availability level offered, and, if demanded, improve it continuously.

There are some useful measures that are good indicators for system availability:

Mean Time Between Failure (MTBF)

Mean Time Between System Incidents (MTBSI)

Mean Time to Repair (MTR)

The following figure shows the relationship between them:

Figure 10 - Relationship between indicators for system availability

ICT Service Continuity Management

The objective of ICT Service Continuity Management is to ensure that the main parts of the ICT infrastructure and the most important ICT systems can be restored within short time after a disaster. This requires planning in advance what to do if a disaster happens and e.g. having access to reserve systems that you can switch to if necessary.

3.3 How could you start to implement ITIL?

A common way to start working with ITIL is by purchasing help desk system based on ITIL processes. Then it is natural to start implementing the Incident Management process because this is the most basic function in this kind of systems.

! !I I

MTTR (Mean Time To Repair)

= Downtime

Reaction time Recovery time

Repair

Diagnosis Resolution

IncidentIncident

Time to detect Time to repair MTBF (Mean Time Between Failure)

MTBSI (Mean Time Between System Incidents)

24


Having purchased a system that supports ITIL does not mean that ITIL implementation comes without effort. The system has to be customised according to the routines that work best for your organisation.

The principles, routines and examples of best practise in ITIL are worthwhile to implement, even without software tools to support them. Full-blown ITIL is meant for large ICT departments with at least 20 people working with ICT management. In smaller ICT departments it might be sensible to start with implementing some of the processes and some of the principles:

E.g. the principle of dividing Incident Management from Problem Management might be a good idea to implement even in a small ICT department. Then the user support (Incident Manager) focuses on making the user able to continue working, while the Problem Manager concentrates on finding the underlying cause of the problem.

A Configuration Management Database is nothing else than an overview of the equipment that you have, with supplier, versions, which year they were installed etc. A simple Configuration Management Database can be made using a spreadsheet, a simple database tool or even table in a word processing tool.

The Definitive Software Library is also quite easy to implement. Your originals can be stored either on CDs in a locked cupboard (or a safe) or on a special disk. To keep an overview of names and version numbers is very important no matter which media you chose for storing. Then you can put an end to all discussions on which version is the right one. This is most important with systems developed specially for your organisation.

The Change Management process contains many important elements that could be worthwhile to implement on their own. The most important is to plan a change, if it is complicated, preferably as a project, do an impact analysis and assess the risks, test everything that can be tested in advance, make a back-out plan. The following real life example shows why all this is important:

In agency X the Exchange server should have been changed more than a year ago, but due to lack of funding this had been postponed over a long period. Just when they were preparing to move the data from the old Exchange server to the new, the old server crashed. They had to go on with the new server, define the users from scratch and get it up and running, but without any data on it. When they were to get the data from the backup, it turned out that some of the backup data were corrupt. They had to hire some very expensive specialists to sort it out. Finally it turned out that the back up data from the last week were not possible to reconstruct at all. The organisation had been without e-mail for almost two weeks and data from the last week before the crash as well as all mails sent to the organisation during the two weeks the exchange-server was down were lost forever.

One of the biggest problems for the users was that they did not have any way of informing the people they collaborated with in other

25


organisations that they were not able to communicate on mail, than calling them. This took a lot of time.

It was considered to put information about problems with e-mail on the web site, but the organisation was afraid that the newspapers would get hold of the information and make an article about it. This would have meant bad PR.

Another big problem was related to meetings that were only scheduled in the electronics system. The users did not know when they had meetings and with whom and no one knew who had booked the meeting rooms and which time.

What should they have done differently?

1. Taken a fresh backup before they started working or at least checked the backup

2. Established an alternative solution for receiving (and sending) mail in case something went wrong.

3. Given the users an advice that they maybe should save the mail addresses to their most important contacts outside the mal system and that they should perhaps get themselves e.g. a hot mail address, just in case

4. Make print outs of important data, in this case e.g. the booking of the meeting rooms

Lessons learned:

1. When you plan to do a change, make an impact analysis

2. Make a simple risk analysis:

Make a plan about what to do if things go wrong.

Find out what you should do in advance to reduce the consequences if things go wrong

Put this into you plan and make sure that you have done it before you start implementing the change.

Have identified at which stages it is possible to rollback.

3. Always evaluate afterwards, finding out what you could do better next time.

Availability Management is important for eGovernment solutions. Often 24/7 availability is demanded. If you manage the servers yourself, this means that you will have to have staff supervising the system all the time. If you outsource system management you will need to focus on the right level of availability. The measures MTBF, MTR, MTBSI, mentioned above, are

26


useful to put in the contract with a service supplier. It is however important to be a conscious about what you are paying for as the following example illustrates:

The Agency Y handles applications for loans and allowances to students. The students can apply filling in forms on Internet. The system uses the Central Citizen Register to find the students official address and uses it to send the approval letter. Earlier the student had to stand in line for hours at the school or university where they are studying to get this letter. Some years ago this highly successful application was developed further so that Norwegian students studying abroad could start using it. The manual routines that the system replaced were even more cumbersome for them, so the application became popular from day one. However the solution did have some children’s diseases:

The agency got mails from students telling that the system was not available. It checked with the service supplier, but they reported that they fulfilled all contract obligations; actually only one of the two servers that the system was running on was in use. However the complains continued. Then the ICT people in the Agency started to check from time to time, and the system was not available, even if the reports from the service supplier said it was. They found the reason when they checked the contract. The contract reported MTBF, MTR, MTBSI etc for the servers, not for the availability of the application in Internet. It was a bottleneck in the Internet four-layer switch, which caused the problem, not the server.

The agency had an option in the contract for supervision of the system. The service supplier was asked to supervise the system, but the problems reports continued. Once again the problem was in the contract. The supervision was only during the working hours. The students that were using the system were mostly in Australia and in the United States. They used it during their day, which is night in Norway. To catch the problems with availability the supervision had to be extended to cover the night as well. This was very expensive, partly because it was not in the original contract. The negotiating position was not very good at this moment when the agency needed it almost at any costs.

What should they have done differently?

1. Analysed the needs for availability when they started developing the system.

2. Put their availability requirements in the requirements specification and used it as an evaluation criterion when they chose the service provider.

3. Had a better knowledge of the contract contents before they started ordering optional services

Lesson learned:

27


It is necessary to analyse the whole infrastructure used by a specific solution before determining where the problems might occur. To have two servers up and running with a lot of capacity is no use if the bottleneck is the Internet four layer switch.

Useful/interesting links:http://www.dream-catchers-inc.com/White%20Papers/glossary_of_terms-SS.htm

http://www.itil.co.uk/

http://www.itil-itsm-world.com/

http://www.itilcommunity.com/

http://itil.technorealism.org/

http://www.itil-toolkit.com/

http://itsm.fwtk.org/

http://www.15000.net/

http://www.itlibrary.org/

http://www.securityfocus.com/infocus/1815

28

http://www.securityfocus.com/infocus/1815

http://www.itlibrary.org/

http://www.15000.net/

http://itsm.fwtk.org/

http://www.itil-toolkit.com/

http://itil.technorealism.org/

http://www.itilcommunity.com/

http://www.itil-itsm-world.com/

http://www.itil.co.uk/

http://www.dream-catchers-inc.com/White%20Papers/glossary_of_terms-SS.htm


4 ICT ProcurementPublic procurement means using public funds to acquire equipment, goods or services from a commercial provider. The public procurement process is regulated by The Law on Public Procurement published in Official Gazette of Republic of Macedonia, No 19/2004, with modifications and amendments published in No 109/2005. The law is supported by a set of related secondary legislation defining the phases of the procurement process in more detail.

Public procurement should ensure the following requirements:

Free competition Public announcementThe procurement procedure

Equal treatment Tender procedure: forbidden to negotiate with the biddersNegotiated procedure: same information to all bidders

Predictability The procurement procedure chosenThe design of the tender documentation

Transparency Reason for choosing a bidDocumentation of procurement process

Verifiability Documentation of the procurement process

Objective and non-discriminating criterion

The design of the tender documentation

The public procurement is regulated through a contract between a state administrative body and a provider of goods/works/services, which in turn is regulated by the Law on Obligations.

4.1 ICT procurement characteristics

There are some elements in the ICT Procurement that make it different than other types of procurements (for example: ordering pens or (toilet) paper). Therefore ICT procurement should involve people with the following knowledge:

Technical knowledge to be able to describe the technical requirements Knowledge about main characteristics of ICT equipment, systems, and

services e.g. software licensing systems, different kinds of support available, different kinds of training, documentation, additional services like data conversion or integration etc.

29


Knowledge about ICT processes and methods (e.g. system development methods, methods for testing etc).

To avoid receiving a product you cannot use, it is of great importance that an ICT professional checks all the technical elements in the requirements specification before publishing.

In addition, it is preferably to include a lawyer who has experiences with ICT tenders and has ICT knowledge to ensure the legal aspect of the procurement procedure.

4.2 Procurement planning

According to the Law on Public Procurement, every ministry and other state administrative bodies have to make an annual procurement plan for its overall needs for procurement in the current year per type of products (goods), services and works. The plan should also set both the dynamics for realization of the procurement and the public procurement procedure to be used.

The purpose of making annual procurement plans is:

To remedy the problem with procurement undertaken without having budgeted financial means

To spread the purchases more evenly over the year

4.2.1 Organisation of Public Procurement

The annual procurement plan must be adopted by the Public Procurement Committee, which is an appointed body within the Ministry or state administrative body that undertakes the public procurements. Depends on the nature of the procurement, the members of the Committee could be also experts covering the specific areas of the planned purchase. The main task of the Committee is to evaluate the offers of the previously announced tenders. On the basis of the previously defined criteria for selection, the Committee evaluates the offers in order to choose the most favourable supplier. In some ministries, or for a special item of procurement, the procurement procedure is performed by the Public Procurement Bureau, or by the Office for common and general services.

After being approved by the authorized person within the organisation, the annual procurement plan is submitted to the Public Procurement Bureau, which is a state administration body within the Ministry of Finance. The Bureau checks whether the submitted public procurement plan is in accordance with the provisions and the procedures of the law. Among other things, the Bureau gives advice and/or assists the procuring entities, and monitors and analyzes the implementation of the laws and other public procurement regulations.

Before you undertake public procurement, you have to previously plan and provide funds for it in your budget, or from other sources.

30


4.2.2 Link to the Strategic planning

The procurement plan should be linked to the strategic planning of the organisation and the essential parts of the investments covered by the procurement plan will be described either in the ICT strategy (or the ICT related part of the strategic plan) or in the Action plan. See figure bellow.

Figure 11 – Link between strategic plans and procurement plans

In addition to the strategic investments, the procurement plan will also need to contain items like data requisites etc. that are not mentioned in the ICT strategy or Action plan. All procurements performed have to be a part of the annual procurement plan.

4.3 Plan the Procurement as a Project

Larger procurements should be organised as projects. You should draw up a project plan where all the tasks and stakeholders are identified, as well as the probability and impact of the risk occurring. You should also make a cost-benefit-analysis for the item of procurement. It is important to ensure that end-users and stakeholders are involved in the planning. You will also need to involve people with skills in project management, see chapter 5.

4.3.1 Assess the Market

The process of procurement should include analysis of the supply market. The analysis should include:

How the market can meet the needs that you have

The probability of interest for supplying the item that you need to purchase

Factors that may have impact on the level of the interest from the market, e.g. if you rely on standards that are not commonly known, if you have very specific technical requirements etc

The probable price of the goods, serviced and works that you plan to purchase

Therefore, it is of great importance that you keep up with trends, what exists of equipment, systems and services. Conferences and seminars are recommended for keeping up with trends. You may also invite different suppliers to give you a demonstration of equipment or programmes before you start the procurement

Individual Procurement

Annual Procurement PlanAction PlanStrategic Plan

ICT Strategy



31


process. Of course, to ensure that the market mechanisms are working properly, it is not permitted to ask specifically for a given supplier or a given brand that only one supplier can deliver in the tender documentation.

4.3.2 Develop a Procurement Strategy

A procurement process is a complex process, therefore it is recommended to produce a procurement strategy befitting the value and complexity of the procurement.

The procurement strategy sets out the strategy to be followed for the procurement and cover all the elements in the process:

Defining the need of the item of procurement

Estimating contract value

Securing financial means

Choosing the right procurement procedure

Advertising the bid – where and when

Producing information to be delivered to all interested suppliers

How to qualify the candidates for the second stage in restricted invitation

Producing documentation for the purchasers (instruction, technical specification, contract)

Defining information which will be requested from the bidders in their bids

How to choose the best value for money supplier

Source: Guidance for public procurement (self-learning handbook), Public Procurement Bureau, April 2006

It is of great importance to plan in good time in advance so that you can use enough time for every element, and to engage the right people needed for the preparations. For a checklist on performing procurement, see appendix 1.

4.3.3 Assess the risks in the procurement process

Risk is the possibility, not the certainty, of suffering a loss. The loss could be anything from diminished quality of the project outcome to increased cost, missed deadlines, or project failure. All projects contain risks that may affect their costs, quality and time taken to complete them.

Risk analysis includes:

Identification of the risks

Assessment of the likelihood of the risks occurring and their potential impacts

Identification of suitable responses to the risks

Selection of appropriate actions

32


Risk management includes:

Treating the risks

Monitoring the actions to ensure the risk management activities are having the desired effect

See appendix 2 for a checklist on Management of risks.

4.3.3.1 Identification of risks

It is very important to identify the risks that may occur throughout the process, so that risk could be retained by or transferred to the party who can manage the risk most effectively.

Examples of types of risk that may need to be considered are:

Financial risks (ex. funding cannot be secured for the full period of the contract)

Resource Risks (ex. loss of key procurement/project management staff; insufficient resources and skills in project teams)

Market risks (ex. low response from the market)

Technical risks

Legal and political risks (ex. the leadership decides that your need would not be prioritised; political change in the authority leading to misalignment with authority objectives)

Risk of poor service delivery (ex. the supplier fails to perform as required)

Risk of difficult or costly relationship management

The existence of risks itself does not indicate that the procurement project should not proceed. Risk management is about deciding whether the risks can be managed efficiently and effectively.

4.3.3.2 Assessment of risks

In this stage you should assess the probability of risk occurring and their potential impact, by evaluating the likelihood of a particular outcome actually happening; and evaluate the effect or result of a particular outcome actually happening.

The example below shows how to categorize and monitor the probability and impact of a risk:

33


Risk Low response from the market

Probability/Impact High probability for occurring / high impact on the result

Consequence Cannot carry out the procurement process

Action Required Take contact with suppliers

Responsible Project Manger

Table 2 – How to categorize and monitor the probability and impact of risk

Risk management plan is not a static document, it needs to be reviewed and updated on a regular basis (See appendix 3 for a template). You should document the risk assessment, the management strategies and the processes implemented to manage the risks.

4.3.3.3 Treating and monitoring risks

After evaluating the probability and effect of the outcome, you need to respond to the risk. You can avoid it (do something less risky), reduce it (minimize both the likelihood and the impact), transfer it (to a third party); accept it (if ability to eliminate the risk is limited, or no potential benefit gained by eliminating); control and terminate (termination of activity in extreme cases).

Employing tools such as bonds and guarantees and conditions of contract can control identified risk.

4.4 Requirements Specification

Before announcing a tender, you need to have a specification of requirements. This is a description of requirements and standards to which the product or service should conform. The supplier’s performance will be measured against it. The requirements’ specification is a mandatory part of the tender documentation (see section on Tender documentation), an appendix to the contract, and should be used as basis for the acceptance testing.

The specification must:

Clearly describe what the supplier is expected to provide

Focus on the function of the product or service required

Act as a tool for contract monitoring

Depending on the object of procurement, whether is a matter of goods, services, works or consultant services, the content of the technical specification differs (for more details, see article 32, Law on Public Procurement).

The technical specification must be in compliance with the technical regulations and standards in the Republic of Macedonia, the European Union and with the international standards.

The object of the procurement must not be specified to an exactly determined brand, model or type, production origin etc. If you cannot describe the object of

34


procurement leaving out those elements, you can indicate the trademark, patent, type or the producer itself, but you should also write “ or equivalent”.

The foundation of a good specification is laid in the planning and researching. It is of a great importance that ICT professionals are responsible for the specification. The Procurement Committee alone cannot decide what kind of equipment or services are needed.

Identify and assess the risks that can occur in this part of the procurement process.

4.4.1 Evaluation Criteria

The evaluation criteria should be developed in parallel to the specification. This is necessary for getting the right information from the suppliers that can be mapped easily onto the evaluation model during the stage of evaluation of the bids. Remember that the requirements must be measurable, either wise you will have problems with selection of a provider.

The evaluation criteria depend on what kind of goods, services or works you want to purchase. The Methodology on Expressing Criteria into Points set some criteria such as bid price, delivery deadline etc. (see section Evaluation of bids), but to avoid problems with the evaluation (it could be that the providers have the same price for the items/services and delivery deadline), you should also think of criteria, such as project management, procedure of testing and acceptance, similar nature contracts etc.

You should carry out risk analysis for every bid you have received. For guidance on risk identification and assessment, please see annex 3.

4.5 Choose procurement procedure

The procurement process should be conducted in accordance with the three main principles: transparency, fair competition and non-discrimination. The procurement procedure you chose depends on the type of the procurement object, the market and the available time.

Public procurement can be performed by using one of these procedures:

Open procedure

Restricted procedure

Negotiated procedure

Design contest

Restricted invitation for consultant services

Procedures with direct contact between procurer and supplier could be used for procurements under EUR 3000. At least three suppliers should be asked to submit their bids out of which the most favourable should be chosen. Procurement after this simplified procedure can be carried out only once during the year for a certain type of goods, services or works.

35


See also appendix 4 for more detailed information on each of the procedures, as well as on framework agreement.

4.6 Tender documentation

The tender documentation should be prepared in a manner that enables the supplier to submit proper bid, in accordance with your needs, harmonised with the prescribed standards and rules for the respective types of procurement.

The main content of the tender documentation for the open invitation and for the second phase of the restricted invitation is:

Invitation for submission of bids

Instructions to the bidders for preparation of bids (evaluation criteria and rating of the criteria (evaluation sheets), requested competences, specification of sub-contractors, opening and evaluation of the bids, contract award)

Bid form and other forms

Contract model

Type, technical specifications, quality, quantity and description of the item of procurement (goods, work or services), manner of conducting control and providing quality security, delivery deadline, place of performance or delivery of the item of procurement

Matter of conduct for the Procurement Committee during the evaluation period

Announcement of the winner

Technical documentation and plans

Format for the manner of filling in the invoice

Needed financial guarantee

Depending on the object of procurement, the tender documentation can also contain other elements that in your opinion are necessary for realisation of the procurement. For example: Documentation of original of the goods (catalogues etc.)

The tender documentation in the first phase of the restricted invitation for bids contains:

Invitation for submission of application

Instructions (guidelines) to the bidders for preparation of the application

Application format

Form for determining the qualifications and instructions for the manner of proving qualifications of the bidders

4.6.1 Evaluation sheet

In order to evaluate the bids received, it is necessary to develop an evaluation sheet, a matrix that will show the bidders on which criteria they will be

36


evaluated, and the rating of the criteria. According to the Methodology on expressing criteria into points the rating points should be from 1 to 100, where the highest number indicates the most important criterion. The following table is an example of how you can rate the criteria in points for determining the most favourable bid. In this case the competence and experience was the most determining criterion for choosing a provider:

Award criteria Weight More detailed criteria

Price 16 Price pr. hour Travel expenses

Enterprise conditions 6 Conditions Reservations Relationship to sub-suppliers General requirements

Competence and experience

54 The suppliers competences and experience The supplier’s methodology The supplier’s certificates Competences and experiences in application

and service architecture Competences and experiences in technical

infrastructure Knowledge and experiences in operation

and monitoring Experience in working with public

administration Relevant references

The competences and experiences of the consultants

Feasibility and availability

24 The capacity of the supplier The availability of the consultants

Table 3 - How to weight technical support

4.7 Invitation for submission of bids or applications

When the tender documentation is prepared, you need to announce the tender in the “Official Gazette of Republic of Macedonia” and on the website of the Public Procurement Bureau. Announce an international tender if the value of the procurement of goods and services exceed EUR 400,000 in Denar equivalent, and for works EUR 1,000,000 in Denar equivalent.

A request for the tender documentation must be submitted to the supplier within three days from the day the request was received. The ministries can prescribe charging a fee for the tender documentation that can only be as high as the expenses for its preparation. All additional questions regarding the tender documentation must be submitted six days before the deadline for submitting the offers, and the responds must be submitted immediately to all suppliers that have obtained tender documentation.

In a case where a need for changing and/or supplementing the tender documentation arises, the changes must be submitted to all suppliers that have

37


obtained the tender documentation. Changes or supplements cannot be performed after the deadline for submitting the offers.

4.8 Public Opening

The public opening is performed in presence of the suppliers or their representatives. The Procurement Committee examines whether the documents for the financial, economical and technical capacity of the supplier are submitted. During the reading of the offers, the Committee reads the name of the supplier, the price of the offer and its currency, eventual given discounts and offered warranties. At this stage, the supplier that has submitted incomplete and invalid documentation is excluded.

4.9 Evaluation of bids

The evaluation of bids must be done in accordance with the criteria listed in the tender documentation. Depending on the type of procurement, the evaluation criteria for selection of the most favourable bid may be:

The lowest prise only, or

The economically most favourable bid in terms of price, delivery deadline, manner of payment, operating costs, efficiency, quality, esthetical and functional characteristics, technical qualities, warranty and post-warranty period, post-sale maintenance services and provision of technical assistance.

The method of assessment of the criteria for evaluation of the offers can be conducted by using points or by using money values, in compliance with the methodology prescribed by the Ministry of Finance (Methodology on expressing criteria into points). In the call, the criteria should be listed in the order of their importance, or rated.

When selecting the most favourable bid, the criteria lowest price or economically most favourable bid shall be applied depending on the subject of procurement. Depending on the subject of procurement, in order to express the criterion the lowest price in points, basis for expression is the lowest offered price and it shall get maximum number of points. The points for other offered prices are calculated in percentage in relation to the lowest offered price.

The applied formula is:

Lowest offered price x Maximum number of points

Number of points = ----------------------------------------------------------------------

Bid price

If the decision is to apply the criterion economically most favourable bid in the selection of most favourable bid, then you assess the bids with regard to:

38


bid price, delivery deadline, payment method, operational costs, efficiency, quality, esthetical and functional features, the technical qualities, warranty and post-warranty period, post-sale maintenance services and provision of technical assistance.

It is important that you as ICT professional are involved in the evaluation process, because you are the actual buyers and you will be dealing with the supplier and know best what kind of product/service you need. Your competences are needed to evaluate terms such as the technical qualities, warranty and post-warranty period, post-sale maintenance services and provision of technical assistance.

4.9.1 Conflict of interest

The provisions in the Law on Public Procurement regarding Conflict of interest are specific and quite comprehensive (Article 21). The procurement commission that is in charge of undertaking the procurement must not have members with too close relations to potential suppliers. In a small country like Macedonia with a relatively limited number of ICT professionals and few vendors, this can be a challenge. Therefore, this must be taken into consideration at an early stage in the procurement process in order to design the process in a way to avoid problems at a later stage.

4.10 Contract Negotiation

You should agree on a contract which clearly sets out the rights and obligations of the supplier and you as a customer. For a more complex requirement, it may be necessary to develop specific terms and conditions and accompanying schedules.

It is recommended to include penalty clauses in the contract that spell out what has to be paid if the contract is breached by delivering late or delivering something else than what you have asked for. Use this penalties in a case of a breach of contract.

If the object of procurement is ICT services, it is advisable to include a Service Level Agreeement (SLA) to the contract. This document defines the basis understanding between the two parties for measuring the quality of the service delivered. It is most common for provision of ICT services, particularly Maintenance and Outsourcing services. Undertaking a SLA can be a complex task, but there are templates available and hints to make it more manageable (see links at the end of this chapter).

Below you will find links to examples of Norwegian standard contracts, used by the Norwegian government. They do of course reflect the Norwegian legislation, but can maybe be of interest as examples.

Purchasing of ICT systems: http://www.statskonsult.no/ssa/avtaler/ssa-k-en.doc

Development of ICT systems: http://www.statskonsult.no/ssa/avtaler/ssa-u-en.doc

Maintenance of ICT systems: http://www.statskonsult.no/ssa/avtaler/ssa-v-en.rtf

39

http://www.statskonsult.no/ssa/avtaler/ssa-v-en.rtf

http://www.statskonsult.no/ssa/avtaler/ssa-u-en.doc

http://www.statskonsult.no/ssa/avtaler/ssa-k-en.doc


4.10.1 Contract negotiation for software systems

The contract should regulate how the project should be implemented. Usually the system development projects are divided in three phases. Each phase should be implemented and determined before going to next phase. The three main phases are:

Specification phase (designing and approval of the detail specification)

Development phase (development and installation of the software)

Delivery phase (acceptance, operation and delivery)

Specification phase

In this phase, the provider, in close collaboration with the costumer, details how the software system is going to be designed, including both functions and technical solutions.

Development phase

After you have approved the specification, the provider starts with the development of the software system. The provider should also provide you with documentation that gives a more detailed and complete specification of the software. If you need training, the provider should also develop course material and train the staff before the installation, so that the persons who will work with the software system have the competences to run tests and approve the system.

Delivery phase

This phase is divided in two; first you run a systematic test of the software system comparing the system with the initiated specification. It is very much likely that you will find errors which must be handled, and test the system until you achieve an accepted level. After the testing period, if no serious errors or problems occur, the costumer accepts the delivery. After its acceptance, you can run a normal use of the system. It is necessary to run thorough tests before you use the system in everyday-operation.

After testing and accepting the delivery, the agreement should specify a warranty period in which the supplier is obliged to correct errors without charge.

4.11 Contract Management

The contract should not be put in a drawer and be forgotten. It should be used in your communication with the supplier when problems arise. It is important to monitor that the delivery is in conformance with the contract. Assess the quality of the service being delivered, and monitor supplier performance against agreed service levels and the conditions within the contract. This requires you to have agreed quality metrics in the contract that allow the quality of a service or a product to be measured. In the case of a breach or breaches of a contract, enforce the penalties you have agreed upon in the contract. You should also consider wheather there is a reason for canselling the contract.

40


4.11.1 Participation in the procurement project

Even though the provider has the main responsibility for implementing the project, your participation is of great importance to achieve a successful result. Your participation should be specified in form of personnal resourses allocated for implementing the project as agreed. This will help to devide the responsibilities between the provider and you. In case of delays and not appropriate solution, your participation will be a matter of discussion; therefore you should specify your department’s role in the project.

Useful/interesting links:http://javni-nabavki.finance.gov.mk/ppwww/mk/homepage.html

http://www.service-level-agreement.net/sla-template.htm

http://www.ogc.gov.uk/index.asp?id=1004160

http://www.scotland.gov.uk/Topics/Government/Procurement/PublicProcurement

http://simap.eu.int/A/2330efb7-0aab-b34c-04c0377ccce3f48d_en.html

http://www.basis.act.gov.au/basis/manactp.nsf/Procurement+Guidelines/B387B49D7B20A5F94A256C7F001BA364

http://www.infotech.com/MR/Business%20Center/Procurement/Procurement%20Risk%20Management.aspx

http://sparc.airtime.co.uk/users/wysywig/risk_1.htm

41

http://sparc.airtime.co.uk/users/wysywig/risk_1.htm





http://simap.eu.int/A/2330efb7-0aab-b34c-04c0377ccce3f48d_en.html

http://www.scotland.gov.uk/Topics/Government/Procurement/PublicProcurement

http://www.ogc.gov.uk/index.asp?id=1004160

http://www.service-level-agreement.net/sla-template.htm

http://javni-nabavki.finance.gov.mk/ppwww/mk/homepage.html


5 Project ManagementTasks that are to be performed within a restricted time and resource frame and deliver specific results should be organised as projects. Project organisation can be used to solve many different kinds of tasks, e.g.:

Design and implementation of new organisations

Plan and implement changes to the ICT infrastructure

Develop new software systems

It is a good idea to decide on a standardised approach to project organisation. This can be achieved by using on a common project methodology.

Many types of frameworks and methodologies exist for organising and managing projects. Most of the examples and descriptions in this handbook are based on PRINCE2 project management framework. PRINCE2 stands for PRojects In Controlled Environments. It is developed in UK, and extensively used by governments and in private sector, both in UK and internationally. It is intended for a wide range of projects, although the fact that it was first developed by the Central Computer and Telecommunications Agency, now a part of the Office of Government Commerce, as a UK standard for ICT project management makes it more suitable for ICT projects than e.g. for making strategies, evaluations or surveys. For these kinds of projects, we have also included a more general approach to project management (see section 6.4 and the appendix 5 for a checklist).

5.1 Characteristics of a projectA project should have an outcome (called product in the PRINCE2 terminology). The outcome is in some way produced by the project members within a limited time frame and with limited resources. The project is therefore characterised by the following:

Time - Every project should have a definite start and a definite end. It comes to the end when the goal is achieved. It can however be laid down before it is finished because of unexpected changes (e.g. lack of funding) or because the project does not show sufficient progress.

Results – The outcome of a project is unique.

People – The people in a project are often experts, either from the line organisation or from outside the company. They often represent different parts of the organisation; different skills etc depending on what kind of project it is. Projects are especially well suited for problem solving across organisations.

42


5.2 The Project OrganisationThe project organisation consists of different groups. Each group has an identified role and mission. It is important that the project organisation has enough authority to ensure that it gets the promised resources otherwise it cannot produce the agreed outcome within budget, quality and time.

Usually the project organisation is established during the project planning process. The organisation should be documented specifying roles and responsibilities.

Figure 12 - Project organisation

5.2.1 The Project Board

The project board represents the interest of the organisation (business), user and, if applicable, the supplier on senior level. It gives the project authority in the organisation and is responsible for the project mandate. How many people the board should consist of depend on the project, but they must be on sufficient high level to be capable of taking the necessary decisions and committing the resources required. Project outcome often affects many different parts of the organisation. Then it is important that the Project Board comprises representatives from different departments to ensure commitment both in the project phase and when it comes to implementing the results of the project.

During the project progress the board gives guidelines to the project manager. The project manager shall report regularly to the board on budget and results, these should be done in documents.

The board is responsible for closing down the project if necessary.

When the project is in the finishing phase, the board is responsible for checking that the outcome of the project is satisfactory. The board is responsible for confirming that the line organisation is prepared to take the responsibility for

Project Board

Project Manager

Project Group

Project Advisory Committee

Team 1

Team n

43


the project results. The board is also responsible for approving finishing reports and experience reports.

5.2.2 The Project Manager

The project manager is responsible for

Managing the project on a day-to-day basis, on behalf of the Project Board

Contact with the Project Board

Making the project plan

Documenting the project decisions and results

Defining responsibilities and coordinating activities within the project group

Quality and risk management

In large projects, consisting of many people, it might be efficient to divide the project group into teams, each team headed by a team manager that reports to the project manager. This kind of organisation is especially useful if different skills are needed in the project. The balance between project leader and team leader must be outspoken and clear.

5.2.3 Project group

The project group produces the outcome of the project. Therefore the project group must consist of people with the right skills to execute the project plan. What kind of skills that are needed varies from project to project?

5.2.4 Project Advisory Committee

An Advisory Committee is usually comprised of stakeholders from various parts of the organisation, often on both managerial and civil servant level. Other participants might be representatives from trade unions and other interest organisations (e.g. NGOs). The Project Advisory Committee provides input on many aspects of project activities and reviews and gives comments on the project outcome. The Project Advisory Committee is not a part of the PRINCE2 model.

5.2.5 Relationship between project and the line organisation

The Project Organisation is not a part of the line organisation, but the line organisation is the receiver of the outcome of the project. Therefore close contact with the line organisation throughout the whole project period is a critical success factor essential for the project. The Project Board is the formal link between the Project Organisation and the line organisation. In addition individuals from the line organisation participate in the project group. Some members of the Project Advisory Committee might also come from the line organisation.

44


A communication plan is a good tool for keeping the line organisation, stakeholders and others that might be affected or are by other reasons interested in the outcome of the projects informed.

5.3 The PRINCE2 Project Management Processes PRINCE2 has eight management processes, each providing a particular emphasis throughout the project life cycle. The processes are not sequential; some can or even have to be done in parallel with others.

5.3.1 Directing

This process runs from start-up through to closure and is aimed at the managerial level above the project manager, namely the project board.

5.3.2 Starting-up

This is a pre-project process, designed to ensure that the project is viable and worthwhile. Necessarily authority must exist for undertaking the project and sufficient information about the projects objectives must be available. The result of this phase should be a document describing the vision about the outcome of the project and a plan covering the initial phase.

5.3.3 Initiating

The main objective of the initiating phase is to lay down a foundation for the project that ensures that the project can be successfully scoped and managed. To adequately plan the project and estimate the costs is an important part of this phase. So is risk assessment.

5.3.4 Controlling Stages

The project model is iterative and this process covers the day-to-day management activities within each iteration or stage. The process activities includes coordinating who is doing what, monitoring and reporting progress, taking necessary corrective actions and escalating problems.

5.3.5 Managing Product Delivery

This process separates the management of the project from the creation or provision of products from the project team. The main responsibility is to ensure that the completed products meet required quality criteria and that the required work is done.

5.3.6 Managing Stage Boundaries

This process covers the Project Managers’ responsibilities at the end of each stage. The mail responsibilities consist of reporting on the delivery of products, reassess the risk situation, update the project management and plan the next stage.

45


5.3.7 Closing

This process ensures a clear end to the project by reporting on fulfilment of project objectives defined in the project initiation document. Other important outputs of this process are assessment of how the project was managed and reporting of lessons learned and recommendation of required follow-on-actions.

5.3.8 Planning

Planning in PRINCE2 focus very much on the quality of the product. The framework for planning is:

Write a Final Product Description

Write a Breakdown Structure of the products required

Write a Product Descriptions, including requirements for each product

Draw a Flow Diagram to show logical orders and interdependencies

Identify required activities to create the product

Estimate duration and effort for each activity

Assess the risk

Calculate the cost

Identify management control points needed – milestones

Document the plan, its assumptions and supporting text.

5.4 Project Management

The PRINCE2 methodology is much focused on ICT system development projects and some of the PRINCE2 processes are not so relevant for other kinds of projects. In projects e.g. for implementing ICT strategies, changes in the infrastructure or procurement the project plan plays a very important part. It is the most important tool for managing the activities in the project. The planning should focus on:

Definition of activities

Time planning

Quality planning

Organisational issues

Human resource planning

Financial planning

Analysis of uncertainties; identification, calculation of probability, remedial actions, costs

Procurement

The output of the planning process should the project plan. The plan should contain:

The starting date and the finishing date of the project

46


All necessary activities required to reach the goals and produce the expected outcome of the project

Definition of roles

Definition of who is responsible for what

Milestones

Figure 13 shows how activities and milestones can be planned.

Activities to achieve the outcome of the project

Start-End Responsible

/Roles

Time Schedule

Date

- A1 – Survey 01.08.2006-01.09.2006

Team leader Jack

- A2 – Design 20.08.2006-15.09.2006

Team leader Nick

- A3 – Implementation 10.09.2006-01.11.2006

Team leader Sara

Milestones M1

M2 M3 M4

Control stages Project manager: Mike

C1 C2 C3 C4

Documentation Project manager: Mike

D1 D2 D3 D4

Figure 13 – Planning activities and milestones

Each of the activities can be divided into smaller activities. It is recommended to use the same framework when scaling down.

To define milestones is important. They can consist of control stages, defined point of possible return and documentation. For an example, see the table bellow.

Milestones Control stages Documentation Risk management

M1: Selection determined

C1: Control quality of the survey approach

D1: Report to Project Board; Control quality in activity A1 Return to start if not satisfied

Not enough participators

M2: Survey carried out

C2: Results of survey

D2: End report activity A1 Result of survey

Report not accepted

M3: Design developed

C3: Financial estimate

D3: End report activity A2 Description of product

Budget control – close project if more than 50% exceeding

M4: Product

C4: Control quality of

D4 - End report activity A4 Implementation report and

Product not accepted

47


developed product description

Table 5 - Detailed Milestone plan

The project plan can have main focus on time, quality or budget; depending on what is most important for the project.

A time focus implicate that end of the project has to be a special day defined in advanced. Time schedule is the most important tool.

A budget focus implicate that the project will succeed only if the cost are within the budget. Constantly financial updating is necessary.

A quality focus implicate that the object of the project, the outcome, is the most important. In this case milestone and quality control is necessary ingredients.

5.4.1 Project implementation

The aim of the project implementation is to produce the project outcome.

To measure and report on the activities is the main tool to ensure the outcome of the project. The challenge is to coordinate and balance the interest between

quality

finance

human resource

time

risks

organisational interests

The coordinating and balancing is usually taken care of by the project manager. In large projects it might be a level of team leaders reporting to the project manager. Team leaders have defined areas of responsibility. Reporting and prioritising should go from project manager to project board, and should be a written document.

5.4.2 Project Management

Project Management is a continuous activity throughout the whole project. Several issues need special management focus. If the project is large, this can be too much to handle for a single project manager. Therefore some large projects have a dedicated control committee.

Depend on the object of project it might be necessary to pay special attention to time schedule, quality or finance.

Divergence must be escalated, if it is large, to the project board. The definition of a large/ small divergence and where to report have to be defined in advance, e.g. in the project plan.

48


5.4.2.1 Progress

The progress plan is an important part of the project plan. The progress plan lists activities and how much time is needed to fulfil them. Dependencies between activities should be marked. The sequence of activities that are dependent of others is called a critical path. It is important to keep an eye on these activities, because delays can have large impact. In worst case it may lead to domino effects.

5.4.2.2 Quality

It may be a good idea to make a special quality plan or a quality handbook defining project procedures and standards. Quality and quantity of the project outcome must be monitored and control points should be included in the major milestones.

5.4.2.3 Financial management

The project budget is an important part of the project plan. In smaller projects the Project Manager handles the financials. In larger projects this might be done by a special financial responsible.

5.4.2.4 Procurement management

Procurement can be a part of a project, or if it is complex, a project by itself. Procurements in projects can comprise different kinds of services like consultancy services or system development, computers, premises etc. It is important that the project check that the deliverables are in accordance with their specifications.

5.5 Risk Management

Risk management is controlled, planned risk avoidance (not continuous “fire fighting”). The task of risk management is to manage the project’s exposure to risk by taking action to keep that exposure to an acceptable level and a cost-effective way. All projects contain risks that may affect their costs, quality and time taken to complete them. Therefore, it is necessary to identify, assess, plan to mitigate, and control the risks.

A risk comprehends three components:

Event that risk materialises (if)

Dependency (and)

Impact (then)

Example:

49


If a staff member leaves the project (risk materialises) and she has a unique knowledge of the client’s business processes, then it will take longer to complete the analysis phase.

Management of risk includes analysis of the risks and risk management. The figure bellow illustrates the processes and the need of constant monitoring and evaluating of the risks throughout the project. It involves all members of the project organisation.

Management of risk

Risk analysis Risk management

Figure 14 - Management of risk

Risk analysis involves the identification of potential risks to any aspect of the project. It allows the team to bring risks to the surface so they can deal with them before they hurt the project. Risk evaluation assesses the probability of the risk occurring and the impact on the project should the risk occur. Having identified the risks, possible actions to deal with the risks need to be considered and appropriate actions selected.

Risk management involves planning and implementing the required resources to carry out the selected actions to deal with the risks. It is necessary to monitor and report the actions to ensure the risk management activities are having the desired effect. See appendix 2 for a Checklist for Management of Risks.

5.5.1 Risk Assessment Document

Risk assessment document is a fundamental piece of the risk assessment process. It fills dual roles; it is both a sword (a decision enabler) and a shield (it defends the project). The contents of the risk assessment document should

Identifythe risks

Evaluatethe risks

Identify suitable responses to the risks

Select appropriateaction

Treat the risks

Monitor and report

50


clearly explain what the project risks are, what is the probability of occurring, how high/low impact the risk will have, what is being done to prevent them, and who is in charge for prevent and control. See appendix 3 for a template.

5.5.2 Risk Management Plan

Planning involves developing actions to address individual risks, prioritizing risk actions, and creating a risk management plan. The plan formulates the actions to address how to prevent and minimize the risk and what to do if it occurs.

Risks can be:

Avoided

Reduced

Transferred

Accepted

Controlled

Risk avoidance tries to eliminate the risk by doing something less risky. Risk reduction tries to minimize the likelihood that a risk will occur, or to minimize the impact. Risk transference tries to shift the risk to a third party. Risk acceptance tolerates the risk, perhaps because nothing can be done at a reasonable cost to mitigate it, or the likelihood and impact of the risk occurring are at an acceptable level. Risk control is actions planned and organised to come into force as and when the risk occurs.

The example below shows how to categorize and monitor the probability and impact of a risk, and what to do if the risk occurs:

Risk Change of Government

Probability/Consequence High probability for occurring / high impact on the result

Consequence Political change in the authority leading to misalignment with authority objectives

Action Required Refocus the project in order to suit the programme of the new Government

Responsible Project Manger

Table 6 – How to categorize and monitor the probability and impact of a risk

5.6 Finishing the projectA good managed project should produce the agreed outcome or result within the agreed time and agreed resources. Some projects are closed down

51


prematurely because of financial or political reasons or because it has not produced the expected outcome.

5.6.1 Transfer of results and knowledge to the line organisation

The outcome of the project is to be delivered to the line organisation. It is important to inform them during the project phase and prepare them the for the project outcome. It is a good idea to let managers from the line organisation participate in the project board. At the end of the project the knowledge obtained throughout the project should be transferred to the line organisation.

5.6.2 Evaluation

All projects should be analysed and success and failures should be documented. The evaluation should cover the project organisation, all the project phases and the project outcome. If applicable cost benefit analysis should be made. The prime objective for doing analysis and evaluations is to systematise the experiences to learn to do it better next time.

5.7 Documentation

A project can be seen as a lifecycle, with a start and an end. During lifetime it is recommended to document decisions, plans divergence etc. Since the project manager is the one responsible for success of the project, the project manager should be a wear of the importance of documentation. The following table gives an overview of what is necessary to document on each stage in the lifecycle.

Staring up a project The idea should be described As far as possible the outcome of the project should

be described Interested groups should be defined A superior description of organisation should be

described Initiation stage A further description of organisation should be

described:a. who says what is needed

b. who provides the budget

c. who provides recourses

d. who authorises changes

e. who manage day-to-day work

f. who decides the level of quality

Planning Stage Project plan should describe:a. Date of start and end

b. Main activities

c. More specified activity plan

d. Roles and responsibilities

52


i. Milestones: point of no return, control stages documentation

ii. Risk analyses

iii. Implementation plan

Executing stage During the executing of the project plan, the project manager should ensure:a. Time scheduleb. Qualityc. Budget

Divergence report must be present to project board by project manager

Closing stage A final report of the projects function and different parts is recommended. This contributes to right treatment in line organisation after the project is finished.

An experience report of the project should also be written for later projects.

Useful/interesting link:

http://www.prince2.com/onlinedemo.html

53

http://www.prince2.com/onlinedemo.html


6 eGovernment

6.1 What is eGovernment?

By eGovernment is usually meant the use of Information and Communication Technologies (ICTs) to improve access to public services and make the interaction between government and citizen (G2B), government and business enterprises (G2B) and inter-agency relationship more user friendly, convenient transparent and inexpensive. The purpose of implementing eGovernment solutions are reducing costs – especially to business – of dealing with government; improve administrative efficiency within the state administration; and improving the transparency of government.

There are different degrees of sophistication of online public services (level of online availability of the basic public services) going from ‘basic’ information provision over one-way (downloadable forms) and two-way interaction (electronic forms) to ‘full’ electronic case handling. This is often represented as steps on a service staircase as shown in figure 15 below:

Figure 15: eGovernment services staircase

6.2 EU and eGovernment

In April 2006, the European Commission adopted the i2010 eGovernment Action Plan, which addresses five priority areas for 2010: no citizen left behind; raising efficiency; implementing e-procurement; save access to services EU wide; and strengthening participation and democratic decision-making.

Real “Electronic Government”. Web services and network functions that are result of collaboration between different organisations within the state administration. Interaction, collaboration across state administration and horizontal integration

Simple interaction. Information customized according to information filled in by the user.

Web services containing static information about e.g. the state administration body and their services “Online brochure”

Web services offering the user to fill in and fetch information which is customized according to personal criteria. The service is linked to internal systems within the state administration body. Individual communication and vertical integration

Step 1

Step 2

Step 3

Step 4The services level of user orientation

Complexity, potential benefits and return of investments

54


For examples of good practice, see the e-Government good practice database (supported by the Modinis Programme of the European Commission): http://www.egov-goodpractice.org/gpd.php?&filter=off

With the emergence of eGovernment, ICT grows more and more important in each member state in the EU. The ambition of the EU is to extend eGovernment to a pan-European level. Focus has moved from facilitating collaboration between the public administrations to facilitating service delivery from the public administrations to the citizens and businesses all over the EU. A new EU program covering this area was established 1.1.2005. It is called the IDABC–program, where IDABC stands for Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens. The purpose of the program is to use “the opportunities offered by information and communication technologies to encourage and support the delivery of cross-border public sector services to citizens and enterprises in Europe, to improve efficiency and collaboration between European public administrations and to contribute to making Europe an attractive place to live, work and invest.”

Figure 16 - Pan European eGovernment services

Source: http://europa.eu.int/information_society/activities/egovernment_research/focus/index_en.htm

To achieve its objectives, IDABC issues recommendations, develops solutions and provides services that enable national and European administrations to

55

http://europa.eu.int/information_society/activities/egovernment_research/focus/index_en.htm

http://europa.eu.int/information_society/activities/egovernment_research/focus/index_en.htm

http://www.egov-goodpractice.org/gpd.php?&filter=off


communicate electronically while offering modern public services to businesses and citizens in Europe.

The programme also provides financing to projects addressing European policy requirements, thus improving cooperation between administrations across Europe. National public sector policy-makers are represented in the IDABC programme's management committee and in many expert groups. This makes the programme a unique forum for the coordination of national e-government policies.

By using state-of-the-art information and communication technologies, developing common solutions and services and by finally, providing a platform for the exchange of good practice between public administrations, IDABC contributes to the eEurope objective of modernising the European public sector. IDABC is a Community programme managed by the European Commission's Enterprise an Industry Directorate General.

The EU also plans to enhance the support of the civil servants collaboration by developing an intranet based on a secure network (next generation of the existing TESTA-network, the s(ecure)-TESTA) where it is easy to exchange restricted information. TESTA stands for Trans-European Services for Telematics between the Administrations.

6.3 Requirements and preconditions for eGovernment

To succeed with eGovernment it is necessary to establish an infrastructure that is optimized to support the providing, receiving and exchanging information between citizen and government, businesses and government and between governmental institutions within the country and across borders. The infrastructure has technical, legal and organisational aspects. Some of the requirements and conditions needed to develop eGovernment are:

Changes in existing laws and implementation of new laws

Technical infrastructure

Reliable ICT systems with sufficient capacity

Standardisation of data formats, structures and semantics to enable sharing and exchange of data between public institutions.

System integration across institutions

Integration and cooperation between public registries

Coordination and collaboration between public institutions

Acceptance of eGovernment solutions in the entire society

6.3.1 Legal aspects

Implementation of eGovernment requires that the legislation recognizes electronic documents and electronic communication as a legally binding. In

56


some circumstances this can be implemented quite easily by extending the definition of written communication to include electronic media. Usually the legislation on archiving has to be changed to accept electronic documents. These documents also have to be kept in a secure way for the future, both on mid term (in the different institutions) and long term (in the public archive). How this should be done also has to be detailed in the law or in secondary legislation.

There is usually legislation covering how to treat classified information on traditional media. This legislation has to be adopted and adjusted to cover electronic media. Information security is very important to take into consideration when implementing eGovernment solutions. It has to be thought of from the very beginning of the design phase. Unfortunately this is often not the case and e.g. theft of identity is a growing problem. The next chapter covers what is important to think about to ensure information security when designing eGovernment solutions and appendix 6 goes into this topic in further detail.

Digital information is much more accessible than information written in documents. It is easy to search through large amounts of documents and combine information about people in ways that might lead to severe damage to the people concerned. Therefore it is important to implement legislation on personal data protection before making databases with personal information available. The legislation in this area in the European Union is extensive.

6.3.2 Electronic signature

To legally bind a document it usually has to be signed. Therefore it is needed to implement an electronic equivalent to the written signature. It is important to analyse why the signature is actually needed. The parallel to a written signature is obviously an electronic signature. According to the U.S. Electronic Signatures in Global and National Commerce Act of 2000 an electronic signature means an electronic sound, symbol, or process, attached to or logically associated with a contract or other record and executed or adopted by a person with the intent to sign the record. It refers to any of several mechanisms for identifying the orginator of an electronic message. In countries with central citizens registry which contains the official address of each citizen, a PIN-code (PIN stands for Personal Identification Number) sent to this adress is used as electronic signature in many of the eGovernment solutions.

Digital signature is usually regarded as a “subset” of an electronic signature. By digital signature it is usually meant a cryptographically based signature assurance scheme. Digital signature is often used in the context of public key infrastructure (PKI) in which the public key used in the signature scheme is tied to a user by a digital identity certificate issued by a certificate authority called Trusted Third Party (TTP), usually run by a third party commercial firm. In some countries the TTP is a state owned company e.g. the old State Data Central. This might be a good idea in smaller countries where it is difficult to create a marked big enough to ensure competition between the private TTPs.

57


Both Denmark and Norway have had problems related to the TTPs since the list of suppliers contains too few private companies offering these services.

6.3.2.1 Creating an electronic signature

In order to make sure that a document sent electronically has not been tampered with during the transfer, it is necessary to use electronic signatures. This will also authenticate the sender to the recipient. Figure 15 shows how to create an electronic signature for a document and what elements are necessary. The logic of creating electronic signatures can be built into computer systems, i.e. a filing system.

TTP

Hash(Document

)Signedhashvalue

private

)( hashvalue

Document

The private key is generated, signedand distributed by the TTP.

TTPTTP

Hash(Document

)Hash(Document

)DocumentDocument

)SignedhashvalueSignedhashvalue

private

)( hashvalueprivateprivate

)( hashvalue

DocumentDocument

The private key is generated, signedand distributed by the TTP.

Figure 17 - Creating an electronic signature

As you can see from the figure the document is first reduced to a hash value using a hash algorithm on the document. Then the sender uses his or her private key to sign the document. The private key is generated, signed and distributed by the Trusted Third Party (TTP). The result of this operation is a signed hash value that is sent to the recipient together with the original document.

6.3.2.2 Validating an electronic signature

As the recipient receives a document together with a signed hash value, he or she can validate the content of the document and authenticate the sender using the logic described in Figure 18. First the recipient retrieves the sender’s public key from the TTP. It uses the key on the signed hash value and ends up with the hash value. Then the recipient uses the same hash algorithm as the sender (the two parts has to agree upon which hash algorithm to use) on the received document. Finally the recipient compares the two hash values, and if they are identical the integrity of the document is intact.

When the recipient retrieves the sender’s public key from the TTP he or she must also check if the senders key is valid. The keys can expire on date or be revoked if perhaps someone has stolen or corrupted the sender’s private key. If the key is not revoked and the hash values generated by the recipient compares, the identity of the sender is also verified.

58


Document

Signedhashvalue

Hash(Document

)

hashvalue

compare

hashvalue

public)(

Signedhashvalue

TTP

The public key is kept and guaranteed by the TTP.

DocumentDocument

SignedhashvalueSignedhashvalue

Hash(Document

)Hash(Document

)DocumentDocument

)

hashvalue

compare

hashvalue

public)(

Signedhashvalue

publicpublic)(

Signedhashvalue(SignedhashvalueSignedhashvalue

TTPTTP

The public key is kept and guaranteed by the TTP.

Figure 18 - Validating an electronic signature

6.3.3 Technical infrastructure

eGovernment solutions should be available to all citizens. In order to achieve this the infrastructure has to be developed. Internet is the enabler in the technical infrastructure, but the underlying technology determines how sophisticated solutions you can offer. Bandwith is important as well as capacity of other network components, servers and the PCs used to access the services. To make eGovernment services available to the citizens and businesses (especially the SMBs), the government usually has to invest in building infrastructure, even if their main policy is to leave it to the market. Private investors do however want to get some return on their investments. To reach critical mass for the services can take time.

It is however possible to start offering eGovernment solutions even if the capacity has not been fully built out. If the capacity of the infrastructure is limited, all solutions offered should also be available in a simple text based version that is accessible through slow modem based connections. In Macedonia, Internet penetration is approximately 4%. It will take some years to make eGovernment available to the majority of the citizens in their homes, even with contributions from private initiatives and donors. Free Internet access at schools, public libraries and other public offices might increase penetration. Even if the user has to pay to access the services, they might be able to compete with traditional services, especially if the user will have to stand in line for a long time to get to the counter and get the service. Especially services meant for business enterprises can be made available as payable services if cost benefit in total is favourable.

6.3.4 Reliable ICT systems

When traditional back office ICT systems and registries are made available to the public directly or indirectly as part of eGovernment solutions, the

59


requirements regarding availability becomes higher. If the system is unavailable this becomes very visible. Often the solutions are not made to meet such requirements. They are old and fragile and although this is done all over the world building sophisticated eGovernment solutions with such kernels is rather insecure. Another challenge is meeting the requirements of 24/7 availability. Internal ICT departments in the state administration usually are not based on shift work and to increase the staff to handle working round the clock would represent a heavy burden on the budget. For critical eGovernment solutions outsourcing is usually the answer, but this also costs money. The systems are, however getting more and more reliable, and technical solutions for distance surveillance and system management are getting better and better.

6.3.5 Acceptance of eGovernment solutions in the entire society

System reliability and availability are important issues for the government to get acceptance for eGovernment solutions. Some surveys have been done to try and identify what are the critical success factor for acceptance and the results show that data security, ease of access and perceived confidentiality significally influence individuals’ adoption of eGovernment services. Ease of access is a fundamental aspect and depends much on ability to use ICT effectlively as well as availability of Internet connnections. This is a an aspect of the so called digital divide. The digital divide is the gap between those with regular, effective access to digital technologies and those without. In other words, those who are able to use technology to their own benefit and those who are not. The digital divide is not a clear single gap that divides a society into two groups. Researchers report that disadvantages can take such forms as lower-performance computers, lower-quality or high-priced connections (i.e. narrowband or dialup connections), difficulty in obtaining of the Internet and technological advances in developed economies. The discussion is moving from the technologies themselves to skills and literacy. Training is important, but possibilities to practice regularly after the training has taken place might also be a limiting factor.

6.4 Examples of eGovernment solutions

It usually takes a long time from the first attempts to get eGovernment solutions up and running and then for them to be accepted and evolving into the ordinary ways of interacting with government. To illustrate this we first go into detail in a case from the Norwegian Tax Administration, which has a long history. Then we describe some Macedonian (and Norwegian?) examples of eGovernment solutions.

The Norwegian Tax Administration has been a pioneer in public administration regarding use of ICT to improve the service to the public. One of its main functions is to ensure that individuals report their personal income tax. In Norway income tax and wealth tax are direct taxes. Income tax is paid directly as a percentage of income, whereas wealth tax is a tax on things you own, such as a house, bank deposits

60


etc. In addition, a premium is paid to the social security system to finance public hospitals, medical treatment and various social benefits. The citizens complete their tax return once a year, either electronically (via Internet, SMS, or telephone) or by mail. They simply access the system by logging on to a Web portal of the Tax Directorate, or send an SMS with a code that they accept the already given numbers in the tax return.

The big move from paper based submission of tax returns has made it possible for the tax authorities to be more efficient through new ways of working. This submission is possible due to connection with the National Registry Office, as well as with third-party systems, mostly banks but also public and private institutions reporting to the tax authorities how much you pay for day care of children and other expenses that you can deduct before the tax is calculated. The underlying infrastructure for this solution is quite complicated. In the last few years it has been extended to cover taxes on business enterprises as well. This solution is a part of a portal Altinn (means all inn, which shows that the ambitions is grow in to cover all reporting to the government.)

The development of Altinn is collaboration between the Norwegian Tax Authorities, the Statistics Norway and what is now the Brønnøysund Register Centre. This collaboration started in 2002, but the project to develop the actual solution started in 1996.

The main aim has been to reduce the time and resources Norwegian companies spend on public reporting. It has been calculated that they all together spend over 7300 full time equivalents on statuary reporting just to Central Government Agencies. During the first 6 months of 2004 more than 1.7 forms have been submitted through Altinn and nearly 200 000 enterprises handed in their tax reports though Altinn. This was a 50% growth from the year before. Now approximately 20 state institutions participate in Altinn and the number is growing.

6.4.1 Macedonian eGovernment services

In September 2005, the Assembly of the Republic of Macedonia, adopted the National Strategy for Development of Information Society, which was designed by the Committee for Information Technology. The strategy describes the basic development directions, such as Infrastructure, e-Business, e-Government, e-Education, e-Healthcare, e-Citizens, Legislation and Sustainable Development Priorities of the Information Society. The objective is to enable efficient implementation and use of ICT by all entities in Republic of Macedonia, through the completion of the 109 planned project defined in the Action Plan.

In the Republic of Macedonia there are several eGovernment services. Below you will find a short presentation of four of them:

eGovernment service for citizens http://www.uslugi.gov.mk

61

http://www.uslugi.gov.mk/


This is a standardised central information portal for all citizens of the Republic of Macedonia. It provides citizens with access and the ability to search in a structured way for information about the services provided by the public administration. At the same time, this service will promote online interaction among the citizens and the government.

eProcurement https://www.e-nabavki.gov.mk/

Its aim is to provide a secure, efficient and transparent system for the allocation of public procurement contracts. The eProcurement system will cover a limited number of public administrations (City of Skopje, Service for General and Common Affairs of the Government of RM, Municipality of Karpos, Municipality of Veles) and specific supplies (IT equipment, reconstruction and asphalting of streets, insurance services and food supplies for primary schools in Veles). In the longer term, the project will extend the system to the whole of the country and the complete range of public procurement goods.

Apply Online System for State Employment http://prijava.ads.gov.mk/

The Civil Servants Agency is responsible for the recruitment of civil servants within the State Administration. The Agency is now conducting the entire recruitment process electronically, providing significant efficiency gains for the Agency and financial savings for applicants.

Educational Web Portal http://www.schools.edu.mk/

The portal enables public access to all information regarding the secondary and primary schools and a wide range of services for the pupils and the teachers. The portal contains tools destined to help teachers and pupils in their development and the improvement of the instructional process.


U.S. Electronic Signatures in Global and National Commerce Act

http://industries.bnet.com/whitepaper.aspx?&cid=266&docid=162384

http://europa.eu.int/idabc/

eEurope

Enterprise and Industry Directorate General.

http://www.go.tas.gov.au/web_publishing/web_publishing_usability_guidelines.htm

http://europa.eu.int/information_society/activities/egovernment_research/gpf/index_en.htm

http://europa.eu.int/information_society/eeurope/i2010/docs/benchmarking/online_availability_2006.pdf

62



http://europa.eu.int/information_society/activities/egovernment_research/gpf/index_en.htm

http://www.go.tas.gov.au/web_publishing/web_publishing_usability_guidelines.htm

http://ec.europa.eu/dgs/enterprise/index_en.htm

http://ec.europa.eu/information_society/eeurope/2005/index_en.htm

http://europa.eu.int/idabc/

http://industries.bnet.com/whitepaper.aspx?&cid=266&docid=162384

http://en.wikipedia.org/wiki/Electronic_Signatures_in_Global_and_National_Commerce_Act

http://en.wikipedia.org/wiki/U.S.

http://www.schools.edu.mk/

http://prijava.ads.gov.mk/

https://www.e-nabavki.gov.mk/


http://webdomino1.oecd.org/COMNET/PUM/egovproweb.nsf/viewHtml/index/$FILE/The%20e-Government%20Imperative%20-%20FINAL.pdf

63




7 Information SecurityInformation security is important in eGovernment solutions. Systems should be built in such a manner so that known vulnerabilities are avoided. When making changes in a computer system, it is important to identify what threats the changes may inflict to the system. It is also important to always revise and update systems to encounter threats since the threats are constantly changing.

This chapter is about thinking security from the early development phase all through the entire life cycle of a computer system and thus building a solid infrastructure.

7.1 Definition of security

Information security rests on the concept of preserving authentication, confidentiality, integrity, and availability. The overall goal is to maintain these aspects.

Authentication is the process of uniquely identifying the clients of the applications and services. There are three main factors that can be used to authenticate users. The user can be authenticated on the bases of something the user knows (for instance a password), something the user has (like nonce words or a smartcard), or something that the user is (for example a fingerprint).

Confidentiality, also referred to as privacy, is the process of making sure that data remains private and confidential, and that it cannot be viewed by unauthorized users or eavesdroppers. Access control mechanisms and encryption is frequently used to enforce confidentiality.

Integrity is the guarantee that data is protected from unauthorized modification. Like confidentiality, integrity is a key concern for data passed over networks. Encrypted messages and use of digital signatures will typically take care of the integrity of documents. Hashing techniques and message authentication codes (MAC) typically provides integrity for data in transit.

Availability refers to the ability to use the information or resource desired. That is, that the system remains available to legitimate users. The aspect of availability that is relevant to security is that someone may deliberately arrange to deny access to data or to a service by making it unavailable. You can also experience that systems are going down, and critical information is not available when you need it.

Another aspect of security that should be emphasized is authorization. This is the process that governs the resources and operations that authenticated clients are permitted to access.

When introducing security issues, there are core terms that need to be defined:

Asset is a resource of value such as the data in a database, or on the file system, or a system resource.

64


Threat is a potential occurrence, malicious or otherwise, that may harm an asset.

Vulnerability is a weakness that makes a threat possible.

Attack is an action taken to harm an asset.

Countermeasures is a safeguard that addresses a threat and mitigates a risk.

Security is about protecting assets, and is more of a path than a destination.

When analyzing infrastructure one may identify potential threats and understand that each threat represents a degree of risk. Security is thus about risk management and implementing effective countermeasures.

When working with development we should strive to maintain the four fundamental principles of security.

The concepts of vulnerabilities, threats and countermeasures are handled in appendix 6.

7.2 Security guidelines

In order to develop a secure computer system you should think security from the beginning of the development phase and throughout the entire development process. The guidelines introduced in this chapter may be useful when working with security, both when developing, making changes and revising systems. The guidelines points out important aspects that you should be aware of in different contexts, and are high-level security principles.

7.2.1 Validate input

When input is referred to, both user- and system input is implied. Although two systems are interconnected and mutually authenticated to each other, there is no guarantee that input coming from one of them hasn’t been corrupted during transmission.

Input to and from a system is the route for malicious payloads that may compromise the system. The best strategy for dealing with input and output is to allow only input explicitly defined and drop all other data. Input should therefore be ensured to be both appropriate and expected. Functions that handles the validation must decide if a given input matches expected format. For instance, if input from a user is expected to be an email address, the input should be checked to see if it contains a string, an @, an address, a dot and a top-level domain name. If input is not properly validated, an attacker can enter input that will overflow buffers in a computer system. What happens is, that there is put more data into a buffer then the buffer can handle. This can result in that the attacker makes the entire system crash, or that he or she creates a back door leading to system access.

65


7.2.2 Fail securely

Any sufficiently complex system has failure modes. Failure is unavoidable and should be planned for. The plan should make sure that security problems related to failure are avoided.

Any security mechanism should be designed in such a way that when it fails it fails closed. That is, it should fail to a state that rejects all subsequent security requests rather than allow them. An example would be a user authentication system. If it is not able to process a request to authenticate a user, and the process crashes, the user should not get access to the system.

When a system fails, it may be a problem that it reveals critical system information. For instance, error messages from the system might reveal information on how tables and rows are organized in a database. The messages may contain information on weaknesses that can be exploited by an attacker. Detailed error messages should therefore never be sent to the client, but rather to a system administrator, or to a log.

7.2.3 Keep it simple

Complexity increases the risk of problems concerning security. A complex design is never easy to understand, and is therefore more likely to include subtle problems. Complex code tends to be harder to maintain as well. To stay out of this kind of trouble, design and implementation should be as straightforward as possible in a software development process.

It might be tempting to develop an elaborate and complex security control, but this should be avoided, as users will just end up finding a way around these measures. Even though it might be a good idea, theoretically, to assign all users a number of passwords, and then ask for a random one of them upon authentication, it will probably result in the user writing down all the passwords, and thereby make the effort useless. Often the most effective security is the simplest security.

It is possible to make a system less complex by leading all critical security operations through a choke point. At this choke point, all traffic passing through will be checked by an interface. The choke point might for instance be a gateway that supervises and controls all traffic, giving control of the information flow.

7.2.4 Use and reuse trusted components

When developing computer systems, it should be considered to reuse components that are believed to be of good quality. A component is of good quality if it is thoroughly tested by people you trust, and no documents pointing out critical weaknesses have been published.

The more successful a component has proven itself to be over time, the better reason to reuse it. Many people developing computer systems have gone through the same kind of problems, and may have invested large amounts of time researching and developing robust solutions to them. In many cases, components have been improved through an iterative process.

66


Using and reusing trusted components make sense both from a resource stance and from a security point of view. When someone else has proven they got it right it is beneficial to take advantage of it. For example, it is sensible to reuse cryptographic libraries. Well-used libraries are much more likely to be robust than something put together in-house, because people are more likely to have noticed implementation problems.

7.2.5 Defence in depth

The idea behind defence in depth is to manage risk with diverse defensive strategies. It is important to make sure that various layers of security in a system works together in harmony to supplement each others functionality, but also to overlap, so that if one should fail, another layer will prevent a total compromise of the system.

It is unrealistic to rely on one component to perform its function perfectly at all times. Predicting unexpected events may be hard, but it is certainly necessary. You should take the necessary precautions so that if any unexpected event takes place, there is a plan of how to take care of it. For instance, information can be stored in a database protected with an authentication mechanism where only authenticated users are given access. But if an attacker manages to bypass the security mechanisms, the information stored in the database will be disclosed. Encryption of sensitive data before storage will preserve the principal of defence in depth.

7.2.6 Secure the weakest link

Security might be looked upon as a chain. And just as a chain is no stronger than the weakest link, a software system is only as secure as its weakest component. Attackers will attack the weakest part of the system because they are the parts most likely to be easily broken.

It is probably not possible to make a system perfectly safe of security breaches.

One can secure transits between the user’s browser and the web server, but there might be lack of security elsewhere in the system. It is not enough to secure a system at one point. For instance, it would not help if a computer system has a well functioning authentication mechanism, if the system has many easily available backdoors, leading right into the systems core. Therefore it is important to secure all aspects of the system.

7.2.7 Practice the principle of least privilege

This principle states that only the minimum access necessary to perform an operation should be granted, and that access should be granted only for the minimum amount of time necessary.

Systems should be designed in such a way that they run with the least amount of system privilege they need in order to do their job. This is the “need to know” approach. If a user account does not need root privileges to operate, do not assign them in the anticipation of that they may need them. The reason why a system should operate in this fashion is to avoid potential misuse and reduce

67


the damage that can occur should a malicious user exploit your code. If your code only runs with basic user privileges, it is difficult for malicious users to do much damage with it.

7.2.8 Practice compartmentalization

The basic idea behind compartmentalization is to minimize the amount of damage that can be done to a system by breaking up the system into as few units as possible, while isolating code that has security privileges.

Similarly, compartmentalizing users, processes and data helps contain problems if they do occur. Compartmentalization is an important concept widely adopted in the information security realm. In a computer system where for instance some information is public, while other is classified, the data can be compartmentalized according to the level of security they need. For instance, the public information can be stored on a server that can be accessed from the Internet, while the classified information may be stored on a server within a secure network zone.

7.2.9 Awareness

People who use computer systems need to know how to use the system, and how to be conscious about security issues. To communicate security policies and procedures to users of computer systems, and getting their commitment to adopt these methods, is an important way of lowering the risk of loss or damage to a computer system.

Users should be aware of data security and protection principles, and what actions that might be a danger to the system security and the data confidentiality. Making legitimate users aware of the risks they may constitute to a system they are working with, may reduce, and even prevent, illegitimate actions and breaches in security. As users of computer system needs privileged access to do their job, an example of user awareness might be that a user should never write down a password, or leave his or her workstation unattended.


http://www.owasp.org http://www.webappsec.org

68

http://www.webappsec.org/

http://www.owasp.org/


Appendix:1. Performing Procurement (checklist)

2. Management of Risks (checklist)

3. Risk Assessment Document (template)

4. Procurement procedures

5. Project Management (checklist)

6. Information Security

69


APPENDIX 1

Checklist for performing procurement

Plan public procurement Ensure that you have sufficient funds Check that it is in accordance with the Ministry’s

strategic plan, ICT strategy and action plan Prepare a procurement plan Submit the plan for approval to the Public Procurement

BureauAssess the market Attend conferences/seminars/fairs

Invite providers to demonstrate their solutions Visit providers to demonstrate their solutions Estimate the contract value in advance

Plan procurement as a project Establish project group, project manager Ensure that the people working on the project have

enough time for it Ensure commitment about the project at management

level Develop a timeframe table for the project

Decide on Procurement Strategy

See section 4.3.2 for details

Assess the risks Identify the risks Analyse the consequences of the risks Treat and monitor the risks

Specify the requirements Carry out planning and researching Develop evaluation criteria

Choose a procurement procedure

Find out what kind of procurement procedure is most suitable for the item of procurement

Carry out risk assessmentPrepare tender documentation Depending on the kind of item of procurement, you need

to fill out the standard tender documentation forms Decide on evaluation criteria Make evaluation sheets Make a contract model template Decide on matter of conduct for the Procurement

Commission during the evaluation period Decide on the announcement of the winner

Invite for submission of bids/applications

Publish an announcement in the “Official Gazette of the RM” and on the website of the Public Procurement Bureau

Announce an international tender if the value of the procurement of goods and services exceed EUR 400,000 in Denar equivalent; for works EUR 1,000,000 in Denar equivalent

Submit tender documentation to suppliers Answer additional questions and send them to all

suppliers If needed, submit changes and/or supplements to the

tender documentation to all suppliersPublic Opening Examine the documents for the financial, economical

and technical capacity of the supplier Read the offers Exclude the offers with incomplete and invalid

documentation

70


Evaluation of bids Check the completeness and validity of the documentation for financial, economic and technical capability of the bidders

Evaluate the bids in accordance with the criteria and the rating listed in the tender documentation

Prepare a written report Select a winner, or cancel the invitation Announce the winner Inform the other bidders

Contract Negotiation Develop specific terms and condition and accompanying schedules if it is necessary

Include penalty clauses Use a Service Level Agreement, if applicable

Contract Management If problems arise, use the contract as basis for the communication with the supplier

Monitor that the delivery is in compliance with the contract

In the case of a breach of the contract, enforce the penalties you have agreed upon in the contract

71


APPENDIX 2

Checklist for Management of RisksRegarding to:

Identify the risk sources Mission and goals Decision drivers or organizational management Customers or end users Budget, cost, schedule, and personnel Project characteristics Development process and environment New technology

Analyse the risk impacts Cost overruns and schedule slips Inadequate functionality Cancelled projects Sudden personnel changes or demoralized staff Customer dissatisfaction Damage to company image Poor product performance Legal problems

Purpose

Risk Management Anticipate problems (vs. fixing them when they occur) Address root causes (vs. addressing the symptoms of the cause) Prevent and minimize risk through mitigation (vs. reacting to

consequences) Prepare for consequences to minimize impact (vs. reacting to a crisis) Use a known and structured process (vs. using an ad hoc process)

Use of Risk Assessment Document

Prioritize effort Drive decisions Highlight dependences Determine schedule Educate management

Questions to answer

Make a Risk Assessment Document

What are the project risks? What is the probability for them to occur? What are the consequences? How will you respond to the risks? Who is in charge to monitor and handle the risks?

Make a Risk Management Plan

Research: Do you know enough about the risk? Acceptance: Can you live with its consequences? Avoidance: Can you avoid the risk? Mitigation: Can you reduce the probability? Contingency: Can you reduce the impact?

What to do?

Treat the risks Reduce the risk Transfer the risk Avoid the risk

Statskonsult, November 2006


Track the risks Treat risk tracking as an ongoing exercise throughout the project life cycle

Track the risks for any changes in condition or consequencesCreate a Top 10 List Identify the highest priority risks in a list format and limit the

number of major risks to 10 or fewer Review the list regularly Keep the list updated to show changes in priority

Monitor the risks Adapt the changes in risk priority React to variations from the plan Respond to triggering events Assess the risk management process



APPENDIX 3

Risk Assessment Document

P: Probability for the risk to occur: L (low), M (medium), H (high)

C: Consequences of the impact: L (low), M (medium), H (high)

No Risk/Problem P C Consequences Mitigation/Action Responsible

Sign Date Status

1

2

3

4

5

6



APPENDIX 4

Procurement Procedures

1.1 Open Procedure

The open procedure is a one-stage procurement. All suppliers may tender. The procurer evaluates all the bids and chooses the one, which is considered to be best value for money. The invitation for bids must be published in the “Official Gazette of Republic of Macedonia” and the website of the Procurement Bureau no less than 52 days from the day of sending for publishing. If, the procurer has published the plan for annual procurement at least 2 months ahead on the website of the Bureau of Public procurement or in case of urgency it is possible to use the shortened procedure that lasts 36 days.

1.2 Restricted Procedure

This procedure is also known as a two-phase procedure or pre-qualification of suppliers, and consists of two phases. First all interested suppliers are invited through an open invitation to send a request for participation. The deadline for sending the required information is 37 days from the day of publishing the invitation. The request for participation must contain enough information for the procurer to determine the economical, financial and technical capacity of the supplier. Based on this information, the procurer decides which of the candidates meet the criteria for participation in the second phase, and sends invitation to at least 3 providers along with the tender documentation so that they can submit an offer with proposed prise for the object of procurement. The deadline for accepting the bid shall be 40 days from the day of publishing the call. In case of an emergency the deadline can be set to 30 days. The procurer selects the best candidate on the basis of the criteria established in the written invitation and the rating points they got.

1.3 Negotiated procedure

It is a limited possibility to use a procedure that allows direct contact between procurer and supplier for procurements of greater value. This procedure is called negotiated procedure and is done without previously announcing public invitation. To use the negotiated procedure the procurer has to apply to the Bureau of Public Procurement for prior consent. The request for prior consent must explain the needs for such a procedure and contain information about the procurement. The Bureau should respond to the request within 8 days from the day of the receipt of the request. If the Bureau refuses to give prior consent the procurement is obliged to carry out procurement with public notification.

The main concept of the negotiated procedure is that it is not a standard procedure, but an exception. It should be used in case of emergency caused by unpredictable factor. It is however difficult to maintain principles of free competition and equal treatment, and even more difficult to document that this



has been taken place. That is the reason why open and restricted procedures are preferred.

1.4 Design contest

This procedure is used in the field of physical and urban planning, architecture, civil engineering and data processing. The candidates prepare a project or plan, and an independent jury will award one of them.

1.5 Restricted invitation for consultant services

This procedure refers to intellectual services (studies, projects, research and examination, experiments, study analysis (industrial), copyrights), which lead to selection of a capable candidate in certain area. The procurer follows the same procedures for restricted invitation (see above). The providers submit their bid projects, studies, works, patients, licenses etc., with which they prove their competence and ability to carry out the consultant service subject of procurement.

The procurer, which is established as a jury, reviews the bids for consultant services. One third of the jury members shall be selected from outside the area of the required services. These members have an advisory function. The jury can interview each bidder, and the candidate may additionally specify and complete or modify its proposal. The jury shall prepare minutes and elaborated opinion and submit them to the Procurer.

2.0 Framework agreement

Authorities in EU/EEC countries has used framework agreements for performing public procurement for a long time, although the use of them has not been unproblematic because of the vague definition of the term. This procedure is not usual in Republic of Macedonia yet, but it will be in future.

A framework agreement is a general term for agreements with providers, which set out terms and conditions under which specific purchases (call-offs) can be made throughout the term of the agreement.

The framework agreement will be treated in the same way as any other contract, where the agreement places an obligation, in writing, to purchase goods, services and works. However, the term is normally used to cover agreements, which are not covered by the definition of a contract to which EU rules apply, meaning in the agreement there is no written obligation for the procurer to buy


What is a Framework Agreement?

The new EU Procurement Directive defines framework agreement as an agreement with

suppliers, the purpose of which is to establish the terms governing contracts to be awarded during a given period, in particular with regard to price and

quantity.


anything. The benefit of this kind of agreement is that, because you are not tied to buy anything, you are free to use the frameworks when they provide value for money, but to go elsewhere if they do not.

Framework agreement can be concluded with a single provider or with several providers (must be at least three providers), for the same goods, works and services. The agreement will establish the terms, which will apply under the framework, including delivery timescales daily or hourly rates. The Directive do not specifically limit the length of the call-offs, but it should be appropriate to the purchases in question and should reflect value for money considerations. The length of the framework agreement itself is maximum four years.

In using framework agreements, the procurer follows open, restricted or negotiated procedure until awarding call-offs (individual contracts). It is important to divide selection criteria, by which the procurer selects the providers by technical capacity and ability, financial and economical standing. These criteria have been used before the framework itself, and cannot be repeated at the further competition stage.

Where a framework agreement is concluded with just one provider, call-offs should be awarded on the basis of the terms laid down in the agreement, refined or supplemented by other terms in the framework agreement, but not agreed in that time (such as particular delivery timescales, particular invoicing arrangements and payment profiles; additional security needs; incidental charges; particular associated services, e.g. installation, maintenance and training; particular mixes of quality systems and rates; particular mixes of rates and quality; where the terms include a price mechanism; individual special terms). There can be no substantive change to the specification or the terms and conditions agreed at the time that the framework is awarded.

Where frameworks for the same goods, works or services are awarded to several providers, there are two possible options for awarding call-offs under the framework: either to apply the terms of the framework agreement, or hold a mini-competition. In the first option the terms laid down in the framework agreement are sufficiently precise, whilst in the second option, the terms are not precise enough or complete for the particular call-off, and a mini competition should be held with the suppliers within the framework agreement. In mini competition, the basic terms cannot be renegotiated; neither the specification can be changed. The above-mentioned terms for supplementing or refining the individual call-offs are permitted in this option. The call-off is then awarded to the “most economically advantageous” offer.



APPENDIX 5

Checklist for Project Management

Project Planning (PRINCE2 framework for planning)

Write a Final Product Description Write a Breakdown Structure of the products

required Write Product Descriptions, including

requirements for each product Draw a Flow Diagram to show logical orders

and interdependencies Identify required activities to create the

product Estimate duration and effort for each activity Assess the risk Calculate the cost Identify management control points needed –

milestones Document the plan, its assumptions and

supporting textProject Planning (for implementing ICT strategies, changes in the infrastructure or procurement)

Define the activities Estimate the duration of the activities and the

project Define the milestones Define the roles Define who is responsible for what Make a progress plan Make a quality plan Make a procurement plan and strategy …Organisational issues Calculate the costs Analyse the risks

Project Organisation Establish a project board Establish a project group Consider establishing teams Consider establishing a project advisory

committeeRisk Management Identify the potential risks

Analyse the probability and consequences of the risks

Identify possible actions for response to the risks

Select appropriate actions Identify responsible persons Make a Risk Assessment Document Make a Risk Management Plan Treat the risks (avoid, reduce, transfer, accept,

or control) Monitor and report risks

Closing the Project Transfer results and knowledge to the line organisation



Analyse and document the success and failures

Make cost-benefit analysis, if applicableDocumentation Describe the idea and the outcome of the

project Define the interest groups Describe the project organisation Develop a project plan Develop a divergence report Make a final project report Make an experience report



APPENDIX 6

Attacks on security

Security is threatened when attackers tries to break into a system without permission. There are two ways of attacking a system, either by performing an active attack or a passive attack. An active attack attempts to alter system resources or affect their operations. A passive attack attempts to learn from, or make use of, information from the system, but does not affect the resources.

1.2 Active attacks

Active attacks involve some modification of the data stream or the creation of a false stream and can be subdivided into four categories, namely masquerade, replay, modification of messages, and denial of services.

Figure 8 - Masquerade.

A masquerade, shown in Figure 8, takes place when one entity in a communication process pretends to be a different entity. Masquerade attacks usually include other active attacks. For instance, authentication sequences can be captured and replayed after a valid authentication sequence has taken place, thus enabling an authorized entity with few privileges, to obtain extra privileges by impersonating an entity that has those privileges.



Figure 9 - Replay

Figure 9 shows a replay attack, which involves the passive capture of a data unit and its subsequent retransmission to produce an unauthorized effect.

Figure 10 - Modification of messages

Modification of messages simply means that some portion of a legitimate message is altered, or that messages are delayed or reordered, to produce an unauthorized effect. The attack is depicted in .



Figure 11 - Denial of services

Figure 11 shows how a Denial of Service (DoS) attack prevents or inhibits the normal use or management of communications facilities. This attack may have a specific target, for example, an entity may suppress all messages directed to a particular destination. Another form of service denial is the disruption of an entire network, either by disabling the network or by overloading it with messages so as to degrade performance.

1.2 Passive attacks

Passive attacks are eavesdropping on, or monitoring of, transmissions. The goal of the attacker is to obtain information that is being transmitted. There are two types of passive attacks, namely release of message content and traffic analysis.

Figure 12 - Release of message content



Figure 12 shows the passive attack release of message content. What happens is that an attacker gets his or her hands on confidential information. The information can for instance be shared through e-mail, telephone or transferred files. To avoid release of message content, messages can be encrypted.

Figure 13 - Traffic analysis

Figure 13 describes the traffic analysis attack. An attacker analyzes the stream of messages sent between the users. Then the attacker tries to extract a pattern from the sent messages, to potentially reveal its content.

Passive attacks are difficult to detect because they do not alter any data. It is feasible to protect data by using encryption. The best way of dealing with passive attacks is prevention rather than detection.

2. Vulnerabilities, threats and countermeasures

This chapter will introduce the most common vulnerabilities and threats that can be directed towards computer systems today. The overview of threats is constantly changing, and it is important to keep yourself posted on changes that might occur in the overview.

The vulnerabilities described in this chapter, will be dealt with one by one, and countermeasures will be suggested for each one of them. The same goes for the threats. We take a closer look upon vulnerabilities and threats in order to identify where security is threatened. We mainly focus on web applications, but some of the vulnerabilities and threats described, will also apply to software systems in general.

2.1 Vulnerabilities

Vulnerabilities are weaknesses that make a threat possible. There are several vulnerabilities that may arise when developing web applications. Vulnerabilities might be defined as a weakness in the software and/or hardware design that allows circumvention of the system security. It is important to



identify vulnerabilities that exist in order to work against them during the development of applications. Therefore, this section, will describe the most widespread vulnerabilities, along with countermeasures to counteract them.

2.1.1 Unvalidated input

This vulnerability comes into play when information from web requests is not validated before it is used by a web application. Attackers can exploit vulnerabilities of this kind to attack back end components through a web application. An application uses input from HTTP1 requests to determine how to respond. Attackers may tamper with any part of the HTTP request, namely the URL, query strings, headers, cookies, form fields and hidden fields to try to bypass the site’s security mechanisms.

All information sent from the server to the client side, and back again, must be validated on return to the server side. This is necessary because just about anything can happen on the client side. When data is sent from the server to the client, it crosses the invisible security barrier shown in Figure 14. The invisible security barrier is a conceptual barrier between server and client. Everything that has crossed this barrier from the client to the server may be unsafe. That is, although the data was correct when it left from the server, there is no guarantee that the information is unchanged on return. Everything that has crossed the invisible security barrier from client to server may be unsafe. Client side validation is a good idea for performance and usability, but it will not contribute to the security of a system at all.

1 HTTP defines how messages are formatted and transmitted, and what actions web servers and

browsers should take in response to various commands.



Figure 14 - The invisible security barrier

Countermeasures

The possible consequences of not validating input should not be taken lightly as back end components may be compromised. A huge number of attacks can be prevented if the developers simply validate input before using it. Unless a web application has a strong centralized mechanism for validating all input, vulnerabilities based on malicious input is likely to occur. It is important to remember that not only may input come from users, but also from for instance systems or from files.

To complicate the task of possible attackers, it is important that input parameters are converted to their simplest form before they are validated. This will help avoiding that a masked input slips through filters. Another important aspect is that all parameters should be checked against a strict format specifying exactly what is expected input. If an e-mail address is required, you should expect input of a certain format, that would look something like: [email protected]. The opposite technique, of filtering certain bad input, for instance quotes, is likely to be difficult to maintain and also unlikely to be a complete coverage of possible bad inputs.


mailto:[email protected]


2.1.2 Cross site scripting flaws

One of the most widespread techniques that exploit vulnerabilities of systems where data is not properly validated is Cross Site Scripting (XSS). XSS is a weakness in an application that give attackers the opportunity to plant incorrect information that to the user seems to come from a serious web site, as shown in

Figure 15 - Example of cross-site scripting

This vulnerability also makes it possible for an attacker to hijack communication sessions and thereby pass his or her self off as someone else, with the intent of executing malicious code. This code might make it possible for the attacker to eavesdrop, destroy and/or tamper with data on random client machines.

The effects of a XSS attack can vary from simple annoyance to complete account compromise. The most severe XSS attacks involve disclosure of a users session cookie2. Other damaging attacks include the disclosure of end user files, installation of Trojan horses4, redirecting a user to some other page or site, and modifying presentation of content.

2 Temporary cookie stored in a computers memory for remembering preferences during a web site

visit, which is destroyed when leaving the site, allowing an attacker to hijack the users session

and take control of the victims account.



Table 2 - HTML entity coding

Countermeasures

There exist countermeasures you can make use of to avoid XSS. The best way to prevent a web application from XSS is validating headers, cookies, query strings, form fields and hidden fields against a rigorous specification of what should be allowed. It is also a good idea to convert the characters in Table 2, in all generated output, to the appropriate HTML entity coding. The reason why these characters should be converted is because it may prevent inserted scripts to be transmitted to users in executable form, and it might thus provide some protection from JavaScript-based attacks.

2.1.3 SQL injections

The most common type of injection attack is the SQL injection. SQL injection is a technique by which attackers can execute SQL statements of their choice on the back end database by manipulating the input to the application.

An example SQL injection might be directed at login functionality, where the user needs to provide a username and a password. Suppose that the user enters the following:

Username: Marcus and Password: Safari.

This input will then be used to dynamically build a query that looks something like this:

SELECT * FROM Users

WHERE username = ’Marcus’ and password = ’Safari’.



This would return to the application a row from the database with the given values. The user is considered authenticated if the database returns one or more rows to the application. Now, suppose that an attacker enters the following input to the login procedure:

Username: ’ or 1=1–.

The resulting query will look like this:

SELECT * FROM Users WHERE

username = ” or 1=1– and password=”

The notation – makes the rest of the line a comment. This means that the query effectively looks like this:

SELECT * FROM

Users WHERE username=” or 1=1”.

This query will search the database for rows where either the username is blank or the condition 1=1 is met. Since the latter always evaluates to true, the query will return all rows of the “Users” table, and the user is authenticated.

The SQL injection is very dangerous, and almost all platforms are vulnerable to this attack. To be able to exploit this flaw, the attacker must find a parameter that the web application passes through to a database. The attacker can then trick the web application to forward malicious commands to the database, by embedding malicious SQL commands into the content of a parameter. Consequences of SQL injection are particularly damaging, as an attacker can obtain, corrupt, or destroy database contents.

Countermeasures

To avoid SQL injections certain countermeasures exist. First of all, never pass detailed error messages to the client. Error messages can provide an attacker with valuable system information. Another countermeasure is to validate input in such a way, that every possible meta character to a subsystem is identified. In this way possible attackers can’t make the necessary inputs to the application to compromise the system. It is also possible to use the technique of canonicalization3.

3 Canonicalization is a way of simplifying encoding. Some sites protect themselves by filtering out malicious input. The problem is that there are many ways of encoding input. Therefore, parameters must always be decoded to the simplest form before they are validated, or malicious input may be masked and can slip past filters.



2.1.4 Buffer overflows

Buffer overflow is a vulnerability that alters the flow of an application by overwriting parts of memory. It is a common software flaw that might result in an error condition.

This error condition occurs when data written to memory exceed the allocated size of the buffer. As the buffer is overflowed, adjacent memory addresses are overwritten, and might cause the software to fault or crash. By sending carefully crafted input to a web application an attacker might cause the web application to execute arbitrary code, and this means that the attacker is effectively taking over the machine.

Buffer overflow vulnerabilities have become quite common in the information security industry and have often plagued web servers. However, they have not been commonly seen or exploited at the web application layer itself. The primary reason is that an attacker needs to analyze the application source code or the software binaries. Since the attacker must exploit custom code on a remote system, they would have to perform the attack blindly, making success very difficult.

Countermeasures

The countermeasure used to avoid buffer overflow attacks is validation. You should always check that all input has reasonable length. It doesn’t matter if the input comes from a user, from files or from another system; all input should always be checked. In high level languages like Java, Perl, PHP, VBScript and so on, buffer overflows generally cannot occur. The languages have enforced size restrictions on arrays, which means that you cannot store something in the arrays unless it fits.

In medium-level languages like C and C++, nothing stops the program from storing bytes past the end of the array. This requires the developer’s attention to make the code safe from possible attacks.

2.1.5 Broken authentication and session management

Authentication and session management includes all aspects of handling user authentication and managing active sessions. Authentication is a critical aspect, but solid authentication mechanisms may be undermined by flawed credential management functions, including forgot password feature, password change, account update, and other related functions. Because “walk by” attacks, that is attacks where a privileged user leaves his or her workstation unattended and and attacker exploits this to get privileged access, are likely for many web applications, all account management functions should require re-authentication even if the user has a valid session identifier.

User authentication in a web application typically involves requiring the user to provide of information on something he or she knows, like a valid username



and password. Stronger methods of authentication, like biometrics6 (something the user is), are commercially available, but in most applications they are cost prohibited.

Web applications must establish sessions to keep track of the stream of requests from each user. HTTP does not provide this capability, so web application must create the requests themselves. Account credentials and session tokens needs to be properly protected, otherwise authentication and session management can be broken. Attackers may compromise passwords, keys, session cookies, or other tokens to defeat authentication restrictions and assume other user’ identities.

Unless all authentication credentials and session identifiers are protected with

Secure Socket Layer (SSL) at all times and protected against disclosure from other flaws, such as cross-site scripting, an attacker can hijack a user’s session and assume their identity.

Countermeasures

Be sure to design a robust and secure authentication and session management scheme that is consistently enforced. In addition be careful so that user credentials are properly handled. Some key areas are to control the password storage; they should be stored in either hashed or encrypted form for protection. Hashed form is preferred as it is not reversible. Credentials in transit should be protected, for instance by employing SSL. Concerning the HTTP protocol, authentication and session data should never be submitted as part of a GET4, POST5 should always be used instead.

2.1.6 Broken access control

Access control is how a web application grants access to content and functions to some users, and not others. These checks are performed after authentication, and govern what authorized users are allowed to do. Access control sounds easy enough, but is hard to implement correctly.

It is easy to underestimate the difficulty of implementing reliable access control mechanisms. Usually the access control rules are inserted different places in the code, and you cannot create an image of how it all is put together, and this makes it almost impossible to understand.

Many of these access control schemes are not difficult to reveal and exploit. Once a flaw is revealed, the consequences of a flawed access control scheme can be devastating. Attackers can then exploit the system to access other users accounts, view sensitive files, or use unauthorized functions.

4 GET is a request used by the HTTP protocol, and should be used when a client asks for information.

5 POST is a request used by the HTTP protocol, that should be used when a client performs

actions where something is permanently changed on the server.



One specific type of access control problem is that administrative interfaces allow site administrators to manage a site over the Internet. Due to the administrator powers to change user rights, data and content on the site, these interfaces are frequently prime targets for attack by both outsiders and insiders.

Countermeasures

Preventing access control from being broken can be done by thoroughly planning the access control scheme before implementing it. When designing the access control scheme, always keep in mind the principle of least privilege. It is also useful to review logs to spot any attempts, or maybe even success’, to break the access control scheme.

2.1.7 Improper error handling

A common problem is when detailed internal error messages such as stack trees, database dumps, and error codes are displayed to the user. These messages reveal implementation details that always should be kept secret from outsiders. The messages can give the user important clues of potential flaws in the site and such messages are also disturbing to normal users. The attacker can, through improper error handling, gain detailed system information, deny services cause security mechanisms to fail, or crash the server.

Frequent errors from the web application may be out of memory, null pointer exceptions, system call failure, database unavailable, network timeouts and many more.

Countermeasures

A policy for how to handle errors should be documented, including the types of errors to be handled, and for each of these what information should be reported to the user, and what information should be logged. The goal should be to provide a meaningful error message to the user, diagnostic information to the sites maintainers, and no useful information to the attacker. Simple error messages should be produced and logged so that their cause, whether an error in the site or a hacking attempt, can be reviewed. Error handling should not focus solely on input provided by the user, but should also include any errors that can be generated by internal components such as system calls, database queries, or any other internal function.

2.1.8 Insecure storage

Most web applications need to store sensitive information, either in a database or on a file system somewhere. The information might be passwords, credit card numbers, account records, or proprietary information. Frequently,



encryption techniques are used to protect this information. Although encryption techniques has become easier to implement and use, developers still make mistakes while integrating this techniques into web applications. They overestimate the protection gained by using encryption, and forget to secure other aspects of the site.

Countermeasures

When you are in need of using encryption, use a public library that has been exposed to public scrutiny and make sure that there are no open vulnerabilities. Do not develop a new encryption algorithm. You should try to minimize the use of encryption, and only keep information that is absolutely necessary. For instance, rather than encrypting and storing credit card information, simply ask the user to re-enter the numbers.

2.1.9 Insecure configuration management

Web server and application server configurations play a key role in the security of a web application. The servers are responsible for serving content, and invoking applications that generate content. Some application servers also provide other services like data storage, directory services, mail and messaging.

An attacker can detect problems with the configuration with readily available security scanning tools. Once detected, these problems can easily be exploited and result in total compromise of a web site. Successful attacks can also result in the compromise of back end systems including databases and corporate networks.

Countermeasures

It is critical to have a strong server configuration standard to secure a web application. Keeping the server configuration secure requires that the ones responsible will be on the alert. You should pay attention to published security vulnerabilities, and make sure the system is updated. The latest security patches should be applied, and you should make sure that configurations, for instance of SSL, are correct.

2.2 Threats

A threat is a potential occurrence that may harm an asset. These occurrences may be malicious. That is, it might be a deliberate attempt to harm an asset. If such an action occurs it is called an attack. There are several different types of attacks. The attacks that will be treated here are categorized into seven groups; spoofing, tampering data, tap communication, repudiation, information disclosure, Denial of Services (DoS), and elevation of privileges. These will all be described in following subsections.



2.2.1 Spoofing

Spoofing is an attempt to access a system by using a false identity. There are several ways to do this, for example using stolen user credentials or a false IP address. To get a hold of someone’s user credentials, the attacker may make use of a social engineering6 technique called phishing.

Phishing is an expanding problem today, and the kind of phishing that will be presented here, is getting more and more sophisticated as attackers are starting to directly address individuals as opposed to addressing the mass marked. The attackers will send e-mails containing personal information that is already stolen, the idea being that for instance bank customers will be more likely to give up valuable information, like the pin-code to their bankcard, when presented correct personal information. The receiver of the e-mail is sent to a page that looks very similar to the real bank page, by pressing a link in the e-mail. The page is in fact placed on a bot net7, though. At the malicious page, the victim is asked to provide personal information. When this is completed, the user is typically sent to his real Internet bank page and may continue surfing with no worries.

The consequence of a phishing attack varies in accordance with the goal of the attack. Often, economical gain is the motivation behind a phishing attack, but in-house company information might also be a target.

Another spoofing technique is IP spoofing. IP spoofing is when an attacker forges the IP address in packets going from the attacking box, so that the packets appear to come from an address that should be authenticated when received by the recipient.

In most situations, IP spoofing by itself is not good enough for the attacker to make a successful attack. For instance, the attacker needs to make sure that the fake packets are actually routed to the target, and even if packets makes it to the target, responses are routed to the forged IP address. In order for the forgery to be useful, the attacker needs to receive the responses. The only real way to accomplish this is for the attacker to become interposed somewhere on the route between the spoofed machine and the target.

6 In the realm of computers, the act of obtaining or attempting to obtain otherwise secure data by conning an individual into revealing secure information. Social engineering might be successful because its victims innately want to trust other people and are naturally helpful. The victims of social engineering are tricked into releasing information that they do not realize will be used to attack a computer network.

7 11A bot (robot) is a machine that has been compromised and is controlled externally. A botprogram, that has somehow entered the machine opens a port to receive instructions on. Instructionsmight be to download new versions of bot software, to send out viruses or spam, or to participatein denial of service attacks against specified sites. At all times, ten thousands of machines over theentire world are active in bot nets without the legitimate owners being aware of it.



IP spoofing is, as you can see, difficult to execute. There are tools that largely automate individual IP spoofing attacks, but the attacker must possess some technical insight to perform the attacks using the tools available.

Countermeasures

There are different countermeasures that may prevent spoofing attacks from happening. When it comes to phishing, the only way to encounter this problem is to make the users aware of the fact that attackers exploit users naivety to get their hands on sensitive information. To make users more critical to information received in e-mails is useful.

As to IP spoofing, you may use countermeasures like strong authentication and encryption to avoid attacks. Simple rules are not to store secrets in plain text, not pass credentials in plain text over the wire, and protect authentication cookies with SSL.

2.2.2 Tampering data

Tampering is unauthorized modification of data. It usually takes place when the data is flowing over a network between computers. When data is tampered with, it is compromised.

Tampering data is known as an active attack. There are several widespread tampering techniques. These techniques either involve some modification of the data stream or the creation of a false stream. The attacks are the masquerade attack, replay attack, modification-of-messages attack and Denial of Service (DoS) attack.

A masquerade attack takes place when one entity pretends to be a different entity. A replay attack occurs when a message, or part of a message, is repeated to produce an unauthorized effect. Modification of messages occurs when the content of a data transmission is altered without detection and results in an unauthorized effect. An example might be when a message “Allow John Mils to read confidential files” is changed to “Allow Agatha Anderson to read confidential files”. Denial of service occurs when an entity fails to perform its proper function. Examples are generation of extra traffic or messages intended to disrupt the operation of the network. Denial of service will be treated separately.

Countermeasures

Active attacks are quite difficult to protect from, as it would involve physically protecting all of the communication facilities and transmission paths at all times. Instead the goal is to detect them and to recover from any disruption or delays caused by them. Because detection has a deterrent effect, it may also contribute to prevention. To prevent attackers from tampering with data, you



can use countermeasures like data hashing, data signing, digital signatures, strong authorization, or make use of a connection-oriented integrity service8.

2.2.3 Tap communication

Tapping of communication is unauthorized eavesdropping, or traffic analysis, of messages flowing over a network. When data is tapped, it looses integrity. There are several techniques an attacker can make us of for tapping communication flowing over a network. These techniques are known as passive attacks, more exactly release of message content or traffic analysis.

Release of message content is when an attacker get his or her hands on information flowing over the network. Traffic analysis is when an attacker analyzes the stream of messages sent between users. The attacker tries to extract a pattern from the sent messages.

Countermeasures

Passive attacks are very difficult to detect because they do not involve any alteration of data. However, it is feasible to prevent the success of these attacks, usually by means of encryption. Thus, the emphasis when dealing with passive attacks is on prevention rather than detection.

2.2.4 Repudiation

Repudiation is the user, legitimate or not, denying that he or she performed specific actions or transactions. To prevent repudiation, you should require non-repudiation, which prevents either sender or receiver from denying a transmitted message.

Nonrepudiation is a method of proving either that a user performed an action (such as enrolling in a stock plan or applying for a car loan), or that the user sent or received some information at a particular time. This prevents the individual from fraudulently reneging on a transaction. By comparison, if you purchase an item, you might have to sign for the item upon receipt. If you decide to renege on the deal, the vendor can simply show you the signed receipt.

Countermeasures

There are three techniques that are useful when implementing nonrepudiation. Digital signatures can function as a unique identifier of an individual, much like a written signature, and therefore prevent repudiation. Confirmation services avoid repudiation because the message transfer agent creates digital receipts to 8A connection-oriented integrity service assures that messages are received as sent, with no

duplication, insertion modification, reordering or replays. The destruction of data is also covered under this service. Thus, the connection-oriented integrity service addresses both message stream modification and denial of services.



indicate that messages were sent and/or received. Time stamps contain the date and time a document was composed and proves that a document existed at a certain time, and therefore avoids repudiation.

2.2.5 Information disclosure

Information disclosure is unwanted exposure of private data. A user may, for instance, view the content of a table or file he or she isn’t supposed to open, or monitor data passed in plain text over a network.

A simple method to disclose information is to rely on the error supporting system. In some cases, an attacker may provoke an error by inserting invalid SQL, and be rewarded with a wealth of information. The information can be names of tables and columns from the database used by the application. The attacker can make use of this information to compromise information stored in the database.

Another way an attacker may proceed to attack a system, is to look for “old” files. These files might contain revealing information about the system that can give the attacker unwanted access to private data. An example of this is if the script file is called main.asp. Then the attacker can try out “old” file names like for instance main.bak, main.old or main.asp~ and other previous-version-type extensions.

Countermeasures

Countermeasures that will help prevent information of being disclosed, is to use strong authorization, strong encryption, secure communication links with protocols that provide message confidentiality. Also, avoid storing secrets, like passwords, in plain text, and don’t let “old” files be accessible through the Internet.

2.2.6 Denial of service

During a Denial of Service (DoS) attack, an attacker attempts to stop legitimate users from accessing a service, or information. By attacking the users machine, or a web site the user is trying to access, the attacker might be able to prevent the user from his or her legitimate access.

The most regular form of DoS attack is to flood the network with useless traffic.When a user enters an URL into his or her web browser, a request is sent to the inquired web site to view the page. A web site host machine can only handle a certain amount of requests simultaneously, and if an attacker successfully overloads the host machine with requests, the host can’t handle the users requests anymore, and thus it breaks down.

Another attack is when an attacker locks out a legitimate user by sending invalid credentials until the system locks the account. This is possible in



systems where a user is only provided a limited number of attempts to enter a valid username/password combination. If an attacker provides a valid username in combination with an invalid password a number of times, the account might be locked, and thus the legitimate user is denied access on his or her return. The attacker could also request a new password for a user, forcing the legitimate user to access his or her email account to regain access.

An attacker could also flood the system by registering many new users through a registry form. If the attacker runs a script that generates random input to a registration form, and this input is accepted and stored in the database, the attacker might be able to occupy system resources. The registry form, and in worst case the entire system, will then be unavailable to legitimate users.

Corresponding, an attacker can flood your e-mail account with spam-mail. There is always a limit on how many e-mail a user can keep in their mailbox. If an attacker sends many, or huge, e-mails to a users mailbox, it will prevent the user from receiving legitimate e-mails.

A Distributed Denial of Service (DDoS) is when an attacker uses a legitimate users computer to attack another computer. By exploiting security gaps or vulnerabilities, an attacker can take control of legitimate users machine. The attacker will then be able to use the legitimate users computer to send great amounts of data to a web site, or to spam particular e-mail addresses. This is called a distributed attack since the attacker uses several computers to execute the attack. As a DDoS attack involves multiple machines cooperating on an attack at a specified target, a bot net will be a excellent tool conducting it. If the bot net is built from machines located at many different locations this is an advantage for the attacker.

Countermeasures

Unfortunately there are no effective countermeasures that will prevent DoS- or DdoS attacks from happening. But there are ways that will reduce the probability of an attacker managing to take control over your computer and use it to attack other computers. Some of these countermeasures are enlisted below.

Use bandwidth-throttling techniques and validate and filter input.

Install and maintain antivirus software and a firewall. The firewall should be configured to only allow limited amounts of traffic to and from the computer.

Keep your e-mail addresses safe. Don’t post them on the Internet in its correct form.

Do not open suspicious e-mails either, and use a spam-filter to filter out spammail.

If a user forgets his or her password, and requests a new one, the system should require the user to enter some personal information.

Use time delays instead of locking users out of their accounts when their password is entered wrong multiple times.



Use load-balancing techniques to make a potential attack more difficult to perform. Still it is possible to perform DoS attacks, and especially if sessions are tied to a particular server. This is why you should make an applications session data as small as possible, which makes it somewhat difficult to start a new session.

2.2.7 Elevation of privileges

Elevation of privileges occurs when an attacker assumes the identity of a more privileged user to gain privileged access to an application. For instance, an attacker might elevate his or her privilege level to compromise and take control of a highly privileged and trusted process or account.

In security terms, privilege means “permission to do something, but only if there is some verification of identity. If a user has the credential, access is granted. If the user doesn’t have the credential, access is denied.

Elevation of privilege is not a class of attack as much as it is the process of any attack. Virtually, all attacks are attempts on performing actions the attacker is not privileged to do. He or she wants to somehow leverage limited privilege, and turn it into more elevated privilege.

Most commonly, attackers guess or otherwise obtain the security tokens of a user who has higher privileges than the attacker. Thus, you’ll often hear the term “elevation of privileges” sloppily used to mean gaining someone else’s user ID. This is just one way to elevate privileges.

The attacker can gain elevated privileges by exploiting physical premises, which can be done as in the following scenario: A user with privileges walks away from his or her on-logged computer for a brief moment. An attacker approaches this computer, uses it, and therefore gains elevated privileges through this machine.

Another way the attacker can elevate his or her privileges is by making use of a social engineering technique and by this makes use of a well-meaning person to perform the attack.

The attacker can also run code on the victim’s machine borrowing the privileges of one of his system-level applications. The attacker finds a process that is running with greater privileges than he or she has, and tries to mess it up. As it crashes, the attacker does something that makes it give its privileges to him or her. Attackers typically use a buffer overflow9 to accomplish this.

Countermeasures

To prevent the problem of elevated privileges you should secure physical premises and make users aware of software engineering (awareness). Other

9 A buffer overflow attack interrupts the program as it executes, and makes it run additional

code supplied by the attacker. A successful buffer overflow can take an attacker from zero privileges to total control.



countermeasures are to follow the principle of least privilege, and use least privileged service accounts to run processes and access resources. You should also review logs for abnormal activity, keep up-to-date on patches, have strong passwords, manage settings aggressively and deploy server security software.

3.0 Misuse cases

A misuse case is the inverse of a use case. It describes a function that the system should not allow. While use cases represents positive actions in a system misuse cases represents the negative. Misuse cases describe functions in a system that results in losses for an organization or some specific stakeholder, and they identify potential risks and misuse.

3.1 Misuse case diagrams

Figure 16 - A misuse case diagram

Figure 16 depicts a misuse case. In this example a crook gets his hands on an actors password. That is, the diagram shows the positive use case and the negative misuse case.



- A new actor is introduced in the misuse cases, namely the mis-actor. The misactor is the inverse of an actor, that is, an actor that one does not want the system to support, an actor who initiates misuse cases.

- A new action is also introduced, the mis-action. The mis-action describes the negative plot the mis-actor is doing to the system.

The relations in misuse cases are:

uses: This is used when describing a link between an actor and an action. Default notation.

include: This is used when repeating oneself in two or more separate use cases. One does this to avoid repetition.

generalization: This is used when describing a variation on normal behaviour. One does this to describe the incident casually.

extends: This is used when describing a variation on normal behaviour. One does this when a more controlled form is wanted, declaring extension points in the base use case.

detects: This is used when one makes a link between an action that may detect

misuse in the system and a mis-action.

prevents: This is used when one makes a link between an action that may prevent misuse in the system and the mis-action it is preventing.

3.2 Example of misuse case

In order to illustrate how one can model potential attacks on the system, we will model potential attacks to a web application that is available on the World Wide Web and all the threats that it is exposed to.



As you can see, there are lots of threats that an application is exposed to on the Internet. Using misuse cases you can break down the system into pieces and model threats for each and every action that is to be performed to the system. Doing this as a part of the development process will help you create a secure system.



4. SummaryIn this appendix you have been introduced to what different types of attacks a computer system might be exposed to. In addition the appendix describes different vulnerabilities and threats you should look out for. Both vulnerabilities and threats are presented with possible countermeasures that will either help avoiding the problem, or decrease the possibilities of a successful attack. It is important to be aware that there are many different vulnerabilities and threats to consider when developing a computer system. The misuse cases will help you identify them.

Even if the system that is developed is a small one, the threat overview it is exposed to might be just as massive. Another important aspect is the possible consequences of an attack. Therefore during development of a computerized system you should try to rate which attacks are the most relevant. The intent of doing this is to be capable of protecting the assets of the system in the best possible way by employing appropriate countermeasures to avoid the highest-ranking threats. You can use the principles of risk analysis introduced in chapter 4 and 5 in order to identify the most relevant threats.
