Handbook for ICT professionals - Fundamental skills for ...Document Transcript
Fundamental skills for
ICT Handbook for ICT Professionals in the Ministries and other State Administrative
Bodies in the Republic of Macedonia
1 ICT Strategy and Planning.............................................................................6
1.2 Linking ICT Strategy with the overall Strategy of the organisation..........7
Handbook for ICT
Professionals in the
Ministries and other
Bodies in the
Republic of Macedonia
fundamental skills for
1.3 Action plan.................................................................................................8
1.4 Relationship between strategy, action plan and budget.............................9
2 ICT budgeting ...............................................................................................10
2.1 Budgeting principles.................................................................................10
2.2 The items that should be on the budget....................................................10
2.2.1 Administrative costs..........................................................................10
2.2.3 Hardware ..........................................................................................11
2.2.4 Communication equipment...............................................................11
2.2.5 Software licences...............................................................................11
2.2.6 ICT services.......................................................................................12
2.2.7 Data communication costs.................................................................12
ICT Handbook for ICT Professionals in the Ministries and other State Administrative
Bodies in the Republic of Macedonia
2.3 Budget and procurement..........................................................................13
2.4 Budget and contract obligations...............................................................13
3 ICT Service Management.............................................................................14
3.1 Organization of the ICT Unit...................................................................14
3.1.1 User support......................................................................................15
3.1.2 Infrastructure maintenance ...............................................................16
3.1.3 Daily controlling activities of the infrastructure...............................18
3.1.4 Planning and development................................................................19
3.2 The ITIL processes...................................................................................19
3.2.1 The Service Support processes..........................................................19
3.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..............................................................29
4.2 Procurement planning...............................................................................30
4.2.1 Organisation of Public Procurement ................................................30
4.2.2 Link to the Strategic planning...........................................................30
4.3 Plan the Procurement as a Project............................................................31
4.3.1 Assess the Market..............................................................................31
4.3.2 Develop a Procurement Strategy.......................................................31
4.3.3 Assess the risks in the procurement process ....................................32
220.127.116.11 Identification of risks..................................................................33
18.104.22.168 Assessment of risks....................................................................33
22.214.171.124 Treating and monitoring risks....................................................34
4.4 Requirements Specification......................................................................34
4.4.1 Evaluation Criteria............................................................................35
4.5 Choose procurement procedure................................................................35
4.6 Tender documentation..............................................................................35
4.6.1 Evaluation sheet................................................................................36
4.7 Invitation for submission of bids or applications.....................................37
4.8 Public Opening.........................................................................................37
4.9 Evaluation of bids.....................................................................................38
4.9.1 Conflict of interest.............................................................................38
4.10 Contract Negotiation..............................................................................39
4.10.1 Contract negotiation for software systems......................................39
4.11 Contract Management............................................................................40
4.11.1 Participation in the procurement project.........................................40
5 Project Management.....................................................................................42
5.1 Characteristics of a project.......................................................................42
5.2 The Project Organisation..........................................................................42
5.2.1 The Project Board .............................................................................43
5.2.2 The Project Manager ........................................................................43
5.2.3 Project group.....................................................................................44
5.2.4 Project Advisory Committee ............................................................44
5.2.5 Relationship between project and the line organisation....................44
5.3 The PRINCE2 Project Management Processes .......................................44
5.3.1 Directing ...........................................................................................45
ICT Handbook for ICT Professionals in the Ministries and other State Administrative
Bodies in the Republic of Macedonia
5.3.2 Starting-up ........................................................................................45
5.3.4 Controlling Stages.............................................................................45
5.3.5 Managing Product Delivery..............................................................45
5.3.6 Managing Stage Boundaries..............................................................45
5.3.7 Closing ..............................................................................................45
5.4 Project Management ...............................................................................46
5.4.1 Project implementation .....................................................................48
5.4.2 Project Management..........................................................................48
126.96.36.199 Progress .....................................................................................48
188.8.131.52 Quality .......................................................................................48
184.108.40.206 Financial management................................................................49
220.127.116.11 Procurement management..........................................................49
5.5 Risk Management.....................................................................................49
5.5.1 Risk Assessment Document..............................................................50
5.5.2 Risk Management Plan......................................................................50
5.6 Finishing the project.................................................................................51
5.6.1 Transfer of results and knowledge to the line organisation...............51
6.1 What is eGovernment?.............................................................................53
6.2 EU and eGovernment...............................................................................53
6.3 Requirements and preconditions for eGovernment..................................55
6.3.1 Legal aspects.....................................................................................55
6.3.2 Electronic signature...........................................................................56
18.104.22.168 Creating an electronic signature.................................................56
22.214.171.124 Validating an electronic signature..............................................57
6.3.3 Technical infrastructure.....................................................................58
6.3.4 Reliable ICT systems.........................................................................58
6.3.5 Acceptance of eGovernment solutions in the entire society.............59
6.4 Examples of eGovernment solutions........................................................59
6.4.1 Macedonian eGovernment services...................................................60
7 Information Security.....................................................................................62
7.1 Definition of security................................................................................62
7.2 Security guidelines ..................................................................................63
7.2.1 Validate input....................................................................................63
7.2.2 Fail securely......................................................................................63
7.2.3 Keep it simple....................................................................................64
7.2.4 Use and reuse trusted components....................................................64
7.2.5 Defence in depth................................................................................65
7.2.6 Secure the weakest link.....................................................................65
7.2.7 Practice the principle of least privilege.............................................65
7.2.8 Practice compartmentalization..........................................................65
ICT Handbook for ICT Professionals in the Ministries and other State Administrative
Bodies in the Republic of Macedonia
1. Performing Procurement (checklist)
2. Management of Risks (checklist)
3. Risk Assessment Document (template)
4. Procurement procedures
5. Project Management (checklist)
6. Information Security
The 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
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.
1 ICT Strategy and Planning
An 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
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
• 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
• 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.
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.
1.2 Linking ICT Strategy with the overall Strategy of
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
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
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.
Strategic Plan ICT Goals
- Goal 1 - ICT goal 1
Analysis of ICT
- Goal 2 contribution - ICT goal 2
- Goal 3 - ICT goal 3
- … - …
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.
Status report Vision
Survey of present GAP analysis Where do you want
situation in the ICT to be in 3 years?
- action 1
- action 2
- action 3
Figure 2 - The ingredients for making an ICT-strategy
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.
accordi Action plan
- action 1 - 1. Plan for action, supporting goal x
- action 2 - 2. Plan for action, supporting goal x,y
Rough estimate of
costs and - 3. Plan for action, supporting goal z
- action 3
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.
Action plan Project plan for
- 1. Plan for action, supporting goal x Project plan for
- 2. Plan for action, supporting goal x,y
co Project plan for
Project plan for
- 3. Plan for action, supporting goal z ……..
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.
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
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.
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
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
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
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.
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
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.
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
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
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.
3 ICT Service Management
The 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.
Head of ICT Department
Infrastructure Planning and
User Support maintenance development
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
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.
Ad hoc User
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
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, 1st line support is
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
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
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
relationship mapping Availability
Resources to be managed
Recoverability Systems Services Asset and
and continuity Network Content configuration
Applications Processes management
Security and risk Capacity
Figure 7 - Basic management elements
• 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
• 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.
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
Monitor network Monitor your dynamic network environment and quickly
pinpoint the source of availability and performance
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 controlled
Backup and restore Describe the backup routine (define what kind of
backup, where to store the backup in-house and/or in
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
Go through the log regularly
Spam 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 environment
Uninterruptible Power Supply You should have a UPS that covers the most critical ICT
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
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
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
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
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.
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
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 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:
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?
Corrective RFC’s Change Build/
measures RFC’s Management Buy
Problem Configuration Release
Management Management Management
(Act) (Register) (Do)
Analyze/ Incident Install
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
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.
Development Controlled Test Environment Live
Develop or Build / Fit-for- Communication Distribution
Release Release Release Roll-out
purchase configure purpose preparing And
Policy Planning acceptance planning
software release testing and training installation
Configuration Management Database (CMDB)
Definitive Software Library (DSL)
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
• 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
• 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-
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 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.
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.
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:
MTTR (Mean Time To Repair)
Reaction time Recovery time
Time to detect Time to repair MTBF (Mean Time Between Failure)
MTBSI (Mean Time Between System Incidents)
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
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
• 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
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
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
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
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
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
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
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.
4 ICT Procurement
Public 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 announcement
The procurement procedure
Equal treatment Tender procedure: forbidden to negotiate with the
Negotiated procedure: same information to all bidders
Predictability The procurement procedure chosen
The design of the tender documentation
Transparency Reason for choosing a bid
Documentation of procurement process
Verifiability Documentation of the procurement process
Objective and non- 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
• 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.
• 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
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
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.
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.
Annual Individual Procurement
Strategic Plan ICT Strategy Procurement Plan
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
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
• 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
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
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
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
• Producing documentation for the purchasers (instruction, technical
• Defining information which will be requested from the bidders in their
• 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
• Identification of suitable responses to the risks
• Selection of appropriate actions
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.
126.96.36.199 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
• 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
• 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.
188.8.131.52 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
The example below shows how to categorize and monitor the probability and
impact of a risk:
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.
184.108.40.206 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
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
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
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.
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,
• 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
• 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
The tender documentation in the first phase of the restricted invitation for
• 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
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
Award criteria Weight More detailed criteria
Enterprise conditions 6 Conditions
Relationship to sub-suppliers
Competence and 54 The suppliers competences and experience
experience The supplier’s methodology
The supplier’s certificates
Competences and experiences in application
and service architecture
Competences and experiences in technical
Knowledge and experiences in operation and
Experience in working with public
The competences and experiences of the
Feasibility and 24 The capacity of the supplier
availability 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
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 = ----------------------------------------------------------------------
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:
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
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
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
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
Specification phase (designing and approval of the detail specification)
Development phase (development and installation of the software)
Delivery phase (acceptance, operation and delivery)
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
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.
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
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.
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.
5 Project Management
Tasks 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 project
A 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.
5.2 The Project Organisation
The 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
Project Advisory Committee
Team 1 Team n
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
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
• Contact with the Project Board
• Making the project plan
• Documenting the project decisions and results
• Defining responsibilities and coordinating activities within the project
• 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
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
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.
This process runs from start-up through to closure and is aimed at the
managerial level above the project manager, namely the project board.
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.
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
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.
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
The output of the planning process should the project plan. The plan should
• The starting date and the finishing date of the project
• 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
Figure 13 shows how activities and milestones can be planned.
Activities to Start-End Responsible Time Schedule
outcome of the
- A1 – Survey 01.08.2006-0 Team leader
- A2 – Design 20.08.2006-1 Team leader
- A3 – Implementation 10.09.2006-0 Team leader
Milestones M M2 M3 M4
Control stages Project C1 C2 C3 C4
Documentation Project 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
Milestones Control stages Documentation Risk management
M1: C1: Control D1: Report to Project Board; Not enough
Selection quality of the Control quality in activity participators
determined survey approach A1 Return to start if not
M2: Survey C2: Results of D2: End report activity A1 Report not accepted
carried out survey Result of survey
M3: Design C3: Financial D3: End report activity A2 Budget control – close
developed estimate Description of product project if more than
M4: C4: Control D4 - End report activity A4 Product not accepted
Product quality of Implementation report and
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
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
• human resource
• 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
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.
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.
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
220.127.116.11 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.
18.104.22.168 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
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)
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
Management of risk
Risk analysis Risk management
Evaluate Monitor and
the risks report
Identify suitable Treat the
responses to the risks
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
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
Risks can be:
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
Action Required Refocus the project in order to suit the programme of the new
Responsible Project Manger
Table 6 – How to categorize and monitor the probability and impact of a risk
5.6 Finishing the project
A good managed project should produce the agreed outcome or result within
the agreed time and agreed resources. Some projects are closed down
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.
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.
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
Interested groups should be defined
A superior description of organisation should be
Initiation stage A further description of organisation should be
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
i. Milestones: point of no return, control
ii. Risk analyses
iii. Implementation plan
Executing stage During the executing of the project plan, the project
manager should ensure:
a. Time schedule
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
An experience report of the project should also be
written for later projects.
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:
The services Step 4
level of user
Real “Electronic Government”.
Web services and network
Step 2 functions that are result of
Web services offering the
collaboration between different
user to fill in and fetch
Step 1 organisations within the state
information which is
Simple interaction. administration. Interaction,
customized according to
Information customized collaboration across state
Web services containing personal criteria. The
according to information administration and
static information service is linked to
filled in by the user. horizontal integration
about e.g. the state internal systems within
administration body and the state administration
their services “Online body. Individual
brochure” communication and
Complexity, potential benefits and return of investments
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.
For examples of good practice, see the e-Government good practice database
(supported by the Modinis Programme of the European Commission):
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
To achieve its objectives, IDABC issues recommendations, develops solutions
and provides services that enable national and European administrations to
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
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
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
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.
Both Denmark and Norway have had problems related to the TTPs since the list
of suppliers contains too few private companies offering these services.
22.214.171.124 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
The private key is
generated, signed and
distributed by the TTP.
Hash( ) ( hashvalue ) hashvalue
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.
126.96.36.199 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.
The public key is kept and
guaranteed by the TTP.
Signed Signed hashvalue
hashvalue ( hashvalue )
Hash( ) hashvalue
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
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
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
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
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
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
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
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.
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
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
U.S. Electronic Signatures in Global and National Commerce Act
Enterprise and Industry Directorate General.
7 Information Security
Information 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
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
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.
• Threat is a potential occurrence, malicious or otherwise, that may harm
• 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
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
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
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.
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
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.
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
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.
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.
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
Assess 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
Develop a timeframe table for the project
Decide on Procurement 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 Find out what kind of procurement procedure is most
procedure suitable for the item of procurement
Carry out risk assessment
Prepare 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 Publish an announcement in the “Official Gazette of the
bids/applications RM” and on the website of the Public Procurement
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
Submit tender documentation to suppliers
Answer additional questions and send them to all
If needed, submit changes and/or supplements to the
tender documentation to all suppliers
Public Opening Examine the documents for the financial, economical
and technical capacity of the supplier
Read the offers
Exclude the offers with incomplete and invalid
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
In the case of a breach of the contract, enforce the
penalties you have agreed upon in the contract
Checklist for Management of Risks
Identify the risk sources Mission and goals
Decision drivers or organizational management
Customers or end users
Budget, cost, schedule, and personnel
Development process and environment
Analyse the risk impacts Cost overruns and schedule slips
Sudden personnel changes or demoralized staff
Damage to company image
Poor product performance
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
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 Prioritize effort
Document Drive decisions
Questions to answer
Make a Risk Assessment What are the project risks?
Document 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 Research: Do you know enough about the risk?
Plan 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
Track the risks Treat risk tracking as an ongoing exercise throughout the
project life cycle
Statskonsult, November 2006
Track the risks for any changes in condition or consequences
Create 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
Statskonsult, November 2006
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
Statskonsult, November 2006
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
Statskonsult, November 2006
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
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, What is a Framework Agreement?
although the use of them has not been
unproblematic because of the vague
The new EU Procurement Directive defines
definition of the term. This procedure is framework agreement as an agreement with
not usual in Republic of Macedonia yet, suppliers, the purpose of which is to establish the
terms governing contracts to be awarded during a
but it will be in future. given period, in particular with regard to price and
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
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
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.
Statskonsult, November 2006
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.
Statskonsult, November 2006
Checklist for Project Management
Project Planning (PRINCE2 Write a Final Product Description
framework for planning) Write a Breakdown Structure of the products
Write Product Descriptions, including
requirements for each product
Draw a Flow Diagram to show logical orders
Identify required activities to create the
Estimate duration and effort for each activity
Assess the risk
Calculate the cost
Identify management control points needed –
Document the plan, its assumptions and
Project Planning (for Define the activities
implementing ICT Estimate the duration of the activities and the
strategies, changes in the project
infrastructure or Define the milestones
procurement) Define the roles
Define who is responsible for what
Make a progress plan
Make a quality plan
Make a procurement plan and strategy
Calculate the costs
Analyse the risks
Project Organisation Establish a project board
Establish a project group
Consider establishing teams
Consider establishing a project advisory
Risk Management Identify the potential risks
Analyse the probability and consequences of
Identify possible actions for response to the
Select appropriate actions
Identify responsible persons
Make a Risk Assessment Document
Make a Risk Management Plan
Treat the risks (avoid, reduce, transfer, accept,
Monitor and report risks
Closing the Project Transfer results and knowledge to the line
Analyse and document the success and
Make cost-benefit analysis, if applicable
Statskonsult, November 2006
Documentation Describe the idea and the outcome of the
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
Statskonsult, November 2006
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.
Statskonsult, November 2006
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.
Statskonsult, November 2006
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.
Statskonsult, November 2006
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.
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.
HTTP defines how messages are formatted and transmitted, and what actions web servers and
browsers should take in response to various commands.
Statskonsult, November 2006
Figure 14 - The invisible security barrier
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:
firstname.lastname@example.org. 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.
Statskonsult, November 2006
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
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.
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.
Statskonsult, November 2006
Table 2 - HTML entity coding
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
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
Username: Marcus and Password: Safari.
This input will then be used to dynamically build a query that looks something
SELECT * FROM Users
WHERE username = ’Marcus’ and password = ’Safari’.
Statskonsult, November 2006
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.
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
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
Statskonsult, November 2006
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
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
Statskonsult, November 2006
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.
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 GET 4,
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.
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.
4 GET is a request used by the HTTP protocol, and should be used when a client asks for information.
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.
Statskonsult, November 2006
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
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.
Statskonsult, November 2006
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
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.
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.
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.
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.
Statskonsult, November 2006
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 net 7, 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.
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.
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,
11A bot (robot) is a machine that has been compromised and is controlled externally. A bot
program, that has somehow entered the machine opens a port to receive instructions on. Instructions
might be to download new versions of bot software, to send out viruses or spam, or to participate
in denial of service attacks against specified sites. At all times, ten thousands of machines over the
entire world are active in bot nets without the legitimate owners being aware of it.
Statskonsult, November 2006
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
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
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
A 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
Statskonsult, November 2006
analyzes the stream of messages sent between users. The attacker tries to
extract a pattern from the sent messages.
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.
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
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
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
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
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
Statskonsult, November 2006
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
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
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
Statskonsult, November 2006
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.
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
• Do not open suspicious e-mails either, and use a spam-filter to filter out
• 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
Statskonsult, November 2006
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.
To prevent the problem of elevated privileges you should secure physical
premises and make users aware of software engineering (awareness). Other
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
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.
Statskonsult, November 2006
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.
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.
Statskonsult, November 2006
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
Statskonsult, November 2006
In 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
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.
Statskonsult, November 2006